Thème central de la première journée de la Web Services Convention, la SOA (Service Oriented Architecture) apparaît comme la suite logique des Services WebREST.
Extrait de VendrEDI, la lettre mensuelle gratuite de Claude Chiaramonti qui porte sur les données des échanges électroniques en EDI, XML et Web Services. Pour s'abonner : courrier.vendredi@club-internet.fr.
mercredi 23 juin 2004
Le modèle est connu : toute nouvelle technologie suscite d'abord un enthousiasme délirant, puis une déception profonde et finit quand même par un plateau d'implantations réelles, lentement progressives. Plus une tendance à rationaliser, donc complexifier, ce qui était simple dans l'idée de départ ! Cela a été le cas pour XML avec les schémas, cela le devient pour les Services Web (SW).
Les premiers développements de SW ont été développés en REST sans trop d'incidence sur les applications. Puis est venue l'intérêt de se référer à SOAP et WSDL (impactant les "applis") lorsqu'un nombre suffisant de partenaires pouvaient les pratiquer. Voir Eric van der Vlist pour le choix entre REST et SOAP.
Un appel par SW isolé à une application externe ne nécessite pas forcément de SOA (Services Oriented Architecture) : par exemple un voyagiste ou un transporteur transférant, à l'occasion, sur un pricing et une souscription d'assurance fournie par un assureur-partenaire.
Dans ce cas, les informations sur le transport à assurer seront envoyées par message sur le site de l'assureur pour qu'il n'y ait pas besoin de les ressaisir, et en retour l'application intégrera les références du paiement de l'assurance conclue. Sans SOA.
Mais si ce SW n'est plus isolé et que l'application coeur de métier doit en gérer systématiquement plusieurs, la question du passage à une architecture basée sur les services appelés se pose.
Étant entendu, que refonder son SI sur une approche SOA doit conduire à la business agility avec comme mots-clés « loose coupling », « coarse granularity » et « asynchrony » selon un Livre Blanc sur la SOA Implementation Framework.
Implanter une SOA sera d'autant plus efficace qu'elle permettra alors, non seulement de gérer l'appel à des services externes, mais aussi de rationaliser les relations entre applications internes rendues ainsi plus indépendantes et modulaires. La SOA devant alors être souple et ne fournir que les fonctionnalités utiles : la validation de chaque mes-sage, coûteuse, peut être évitée pour des services basiques sûrs, de même que le cryptage etc.
Si la plupart des grands offreurs se positionnent déjà, (cf VendrEDI n°75) ce n'est que dans quelques années que la SOA commencera à vraiment se répandre.
Mais de même que l'on affirmait il y a 20 ans "EDI or die", on entend dire aujourd'hui que la SOA sera la condition de maîtrise de son SI par les entreprises qui seront de plus en plus obligées, soit de faire appel à des services gérés par des sites partenaires, soit d'offrir les leurs.
Autres articles :
Copyright 2004, Claude Chiaramonti, EDItorialiste de VendrEDI.
|