Yearly Archives: 2007

Tetris et le développement logiciel

tetris1.pngFaire évoluer un logiciel c’est comme jouer à Tetris.

Au début c’est facile. Les nouvelles pièces qui tombent représentent les fonctionnalités demandés par le client. Il n’y a pas encore trop de code, c’est propre, on peut facilement intégrer les nouveaux blocks.

tetris2.png

Mais au fil du temps la quantité de code à maintenir augmente, sa qualité se dégrade, il y a des trous dans vos lignes de Tetris.

Vous y arrivez encore, il vous reste un peu de marge de manoeuvre, vous faites tourner les pièces pour adapter la demande du client à votre existant.

En anticipant un peu vous auriez pu prévoir un emplacement pour accueillir la prochaine pièce à venir sans la faire tourner.

tetris3.png

Malheureseument vous n’avez pas refactoré votre code à temps. Votre client à un nouveau besoin. Bien qu’il soit simple, c’est la modification de trop, votre code explose: GAME OVER

La métaphore est de Régis Medina lors des rencontres agiles de mardi dernier.

Big Web Services pourquoi ça ne marche pas?

L’expérience de nombreuses personnes montre que les Big Web Services (SOAP+Ws-*) sont loin de tenir toutes leurs promesses. Voyons maintenant la principale raison théorique qui explique cette débacle:

La volonté de s’abstraire des contraintes du réseau

Relisez au moins deux fois cette citation trouvé chez Pete Lacey:

Integration point latency can be a serious performance problem. The problem becomes acute when the integration point uses some ?avor of remote object protocol. The “location transparency” philosophy for remote objects claims that a caller should be unaware of the difference between a local call and a remote call. This philosophy has been widely discredited for two major reasons. First, remote calls exhibit different failure modes than local calls. They are vulnerable to network failures, failure in the remote process, and version mismatch between the caller and server, to name a few. Second, location transparency leads developers to design remote object interfaces the same way they would design local objects, resulting in a chatty interface. Such designs use multiple method calls for a single interaction. Each method call incurs its own latency penalty. The cumulative effect is a very slow response time.

Michael Nygard

On ne peut pas faire abstraction du réseau, c’est une mauvaise idée que de vouloir faire croire au développeur qu’un appel local est lanetwork.png même chose qu’un appel réseau à cause des problèmes:

  • d’erreurs réseau.
  • de bande passante.
  • d’accès concurents et de versions qui en résultent.
  • de granularité des services.
  • … d’autres raisons sur Fallacies of Distributed Computing

WS-* Bashing

At this point I realize I’m flogging a dead horse. The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already “invested” in WS-* and want to defend that investment.

Dare Obasanjo Program Manager, Windows Live Platform group

Nowadays, all the distributed systems development I do is REST-oriented. I know from significant first-hand experience what both sides of the coin look like, and there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really.

Steve Vinoski senior member of the IEEE

WS-* is where CORBA was circa 1997: it will be used to implement some good systems, but there will also be some high profile failures. A number of the specs will likely never be adopted by the mainstream (see WS-CDL, WS-Eventing), though some will definitely improve some ridiculous vendor interoperability disputes (e.g. WS-TX, WS-RM). Plenty of pundits (now bloggers) sing of its imminent triumph (channelling Orfali, Harkey and Edwards), but overall, the framework will not help solve the problem that was used to sell its adoption in the first place: increased agility, reuse, and visibility in IT. I think many WS-* tools actively hinder an SOA architect from achieving these goals.

Stu Charlton Enterprise Architect for BEA

Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit.

James M. Snell write software for IBM

Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby and PHP. You won’t see them, because there’s no intrinsic value in WS-* unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates “value” that can be sold.

Mark Nottingham web expert at Yahoo

Quelqu’un aurait quelquechose de gentil à dire sur les WS-* pour l’équilibre?