Monsieur Jourdain et la SOA

Mr Jourdain fait de la prose ou des vers sans qu’il n’en sût rien. Bon, nous le savons depuis la 5e ! Et comme Molière avait le don d’écrire des universalités humaines et intemporelles, il est certain qu’aujourd’hui autour de nous et dans bien des domaines il y a des Mr Jourdain qui s’ignorent. Projetons donc ce monsieur Jourdain dans l’IT de 2009. Quelle pourrait être la chose qu’il fît depuis pas mal de temps sans qu’il n’en sût rien. Ne serait ce pas de la SOA par hasard ? Reprenons une définition communément rencontrée d’un service. Je cite rapidement et pour l’essentiel :

• Standardisation : Les services exposés respectent les mêmes règles de standardisation.
• Couplage lâche : Le contrat de service impose un couplage lâche vis-à-vis de ses clients
• Autonomie : Le service est autonome car il ne fait pas appel à aucun autre système tiers. Il n’en n’est pas dépendant. Ce qui par ailleurs le rend prédictible.
• Abstraction : Le contrat de service n’expose que les informations essentielles à son invocation.
• Composition : Le service peut participer à une composition d’appel de services.
• Sans état : Le service ne conserve aucun état (résultats d’exécution ou autres).

Le formalisme posé, maintenant, prenons notre regard de béotien et cherchons qu’est ce que l’on pourrait appeler effectivement service. Décréter qu’un système (application ou pas) devient un service, décréter que l’on va mettre en place une architecture SOA, c’est tout à fait louable mais croyez vous que cela se décrète ? Imposer peut être, pendant un temps. Si le système répond aux attentes il deviendra service dans les faits sinon, il sera contourné et patatras, il tombera aux oubliettes. Et des services en fait il y en a peu. Car l’épreuve du temps et la patine font naître ou disparaître les candidats aux services. Pardon ? Cela vous fait penser à une forme de darwinisme. L’analogie est pertinente en effet ! Prenons une architecture autour d’un ou des systèmes COBOL disons mis en place il y a déjà pas mal de temps (durée à l’appréciation du lecteur). Ces services COBOL, se sont pérennisés dans le temps, les moins utiles ont disparu, les autres se sont enrichis, ont été challengés par les utilisateurs (entendons les applications). Les plus « résistants » sont restés : sorte de sélection naturelle.

Bien que l’on puisse les spécifier les services naissent, meurent et surtout évoluent dans le temps pour aboutir pour ceux qui sont en effet utilisés à des services métier transverses, fiables, stables et simples. Pour quelle échelle de temps ? Des années. Pardon ? Oui des années la stabilité d’un service transverse s’obtient au bout de plusieurs mois voire années ? Mais comment peut-il être adopté s’il met autant de temps à se stabiliser ? C’est que dès le départ il aura répondu à un besoin (une attente) fort qui fait que beaucoup l’auront adopté, puis challengé, amélioré et au final stabilisé il aura du passer toutes ces épreuves pour être admis au rang des services. Ou bien il va naitre dans un coin du SI pour une application donnée seule, puis digne d’intérêt une deuxième va vouloir l’utiliser, puis une troisième etc., sans qu’au départ on ait pu l’imaginer. Finalement, être un service cela ne se décrète pas, cela se mérite.

Prenons un autre exemple que sont les portails. On disait (il y a 5 ans) que tout allait être service et que l’on pourrait agréger des dizaines de services dans notre portail. Au final, que consulte l’utilisateur lambda : le CAC40, la météo et l’horoscope. C’est peu. Certains rétorquerons, dans « le monde professionnel monsieur, les services sont autrement plus nombreux et complexes ». Essayons ! Qu’est ce qui est susceptible d’intéresser et de motiver une équipe pour développer son application en s’appuyant sur des services transverses. Simple d’usage, transverse, performant, fiable et stable, si l’un de ces critères n’est pas respecté, le risque de rejet des utilisateurs (applications) est élevé. Prouvez-le ! Bon. S’il n’est pas transverse, peu d’applications l’utiliseront, est ce alors un service ? Performance : si son temps de réponse dégrade mes propres performances, je vais très vite l’abandonner. Fiabilité : un SLA en décalage (non compatible) avec le mien : c’est qu’il n’est pas fiable à mes yeux. Continuons, instable, aïe celui-ci est délicat, car on ne peut le juger que dans la durée. De plus, au début le service risque d’évoluer et c’est normal. Mais il n’en reste pas moins que si les couts de maintenance et de tests côté utilisateurs sont trop importants (suite aux évolutions) cela me fera réfléchir à une alternative via un développement maison par exemple. Complexe à consommer/utiliser : une notice de plus 3 pages, une ambigüité des cas d’utilisation et/ou de la gestion d’erreurs me feront prendre un risque d’un usage biaisé voire erroné.

Alors dans les back office COBOL (plutôt ancien ;-) ) que constate t on ? Qu’il existe des services transverses exposés depuis pas mal de temps et qui « rendent bien service ».

Des exemples, tirés de la vraie vie :

• calculer de l’octroi de crédit pour un tiers (Finance),
• récupérer un numéro de téléphone disponible (Telecom),
• la CB XXX XXX est-elle en opposition (Monétique),
• ouvrir un compte (Multi métier),
• obtenir les ratings d’un tiers (Finance),
• déclarer un sinistre (Assurance),
• éditer un chèque de remboursement/indemnisation (Assurance),
• obtenir un devis/tarification d'un produit (Multi métier, ….),
• souscrire à un produit (Multi métier, …).
• …

Tous ces services, au sein des entreprises sont relativement peu nombreux et sont en fait les services frontaux métiers qui ont fait leur preuve et qu’un grand nombre d’applications comprennent et utilisent. Ils masquent la complexité des implémentations sous jacentes. Si l’on devait regarder plus précisément s’ils respectent le formalisme évoqué ci-dessus. On s’apercevrait que oui. Mais vous l’avez compris le débat n’est pas là. D’ailleurs, l’article de Anne Thomas Manes ( SOA is Dead; Long Live Services) constate d’une manière assez similaire qu’en parlant SOA chacun s’est perdu dans des débats technologiques sans fin en oubliant l’essentiel : l’architecture et les services.

Alors que dans les faits, juste à côté de lui, de la SOA, pardon du service, Mr Jourdain en faisait dans son SI depuis des lustres, sans qu’il n’en sût rien. Quoi que, il fallait juste lui dire. Peut être alors se serait il poser les bonnes questions quand il a voulu faire de la SOA.