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.
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 la
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