Guillaume Saint Etienne 's Blog

voici l'article que j'aurai aimé écrire avant l'auteur
http://www.theserverside.net/articles/showarticle.tss?id=IntersectionsObjectsandServices

je le cite ici car c'est un pan important de la reflexion globale que l'on peut mener dans l'urbanisation des SI, du point de vue du développeur et des architectes.

Je trouve très interessant de parler des Composants comme évolution intermédiaire entre les objets et les services. En effet, c'est une abstraction qui se situe bien entre ces deux mondes.
Elle vient à l'esprit naturellement pour ceux qui ont pu, de par leur expérience, suivre l'évolution au fur et à mesure que nos éditeurs favoris sortaient leurs frameworks (winDNA puis .Net chez Microsoft).
Pour les autres, cela est moins évident à comprendre.
Il me semble malgré tout interessant de disséquer ce qui s'est passé entre la POO et la SO(A), les composants sont justement le chaînon manquant.

POur enfoncer le clou: il est important de comprendre que les services NE SONT PAS des objets orientés Web. Mais plutot une API.
Et qui dit API dit Contrat.

Je reviendrait sur l'ergonomie des API en echo à un autre excellent article prochainement.

Ces contrats sont des enjeux, et c'est toute une spécialisation qui se profile derrière.

La programmation orientée Contrat pointe son nez, et avec elle on peut penser à une notion plus subtile que l'urbanisation, qui serait: la Socialisation des Services.
L'art de savoir si un service rend bien le service annoncé, s'il est facilement utilisable (ergonomie de son API), s'il répond vite et bien, etc...
Les contrats pourraient être jugés, évalués, recevoir des certifications de qualité, voir même re-négociés entre programmes comme on peut le faire dans notre environnement humain.
Et comme tout contrat est soumis à interprétation, voir apparaitre des conseillers "technico-juridiques" chargés de rédiger les contrats. Et des conflits, forcement.

L'important, comme le souligne Rockford Lhotka, est de ne pas confondre Orientation Service et Web Services. Et de ne pas programmer des API de Web Services comme on design-erait des objets.

SO est une abstraction. WS est une implémentation.