SOA as a Service

L’utilisation de ressources IaaS et PaaS posent de nombreux problèmes d’interconnexion entre les parties prenantes d’un Système d’Information. Dans cet article, je vous propose une vision simplifiée d’une démarche de transformation de votre SOA en un service externe « SOA as a Service ». Elle vous permettra de mettre en oeuvre une infrastructure AWS, Azure, etc. pour vos solutions actuelles SOA et BPM.

Outre la question financière, la principale motivation de cette évolution est de bénéficier de l’élasticité de ces offres XaaS. La SOA et le BPM, au cœur du Système d’information, doit aussi en bénéficier afin d’évoluer et de s’adapter aux contraintes de trafic et de charges exceptionnelles.

Comme exemple, j’utiliserai d’un cas d’école simple et représentatif avec ses 4 couches applicatives:

  1. Le navigateur des utilisateurs
  2. L’ application Front-End qui agrège les informations métier pour générer une vision contextualisée
  3. La partie SOA avec:
    1. le bus d’entreprise (ESB) qui virtualise et routent les services métier
    2. l’orchestrateur SOA qui gère la complexité des enchaînements entre les services du SI
    3. le moteur BPM qui porte les workflows métier
  4. Le Back-Office qui expose des services techniques, métier ou utilitaires sur des technologies variées.
Architecture du cas d'exemple
Architecture du cas d’exemple

Cette représentation reste valable pour N applications web dans la partie Front-End et N applications dans la partie Back-End. Les technologies sous-jacentes sont sans impact tant qu’elles communiquent avec des protocoles standards HTTP comme SOAP ou REST.

La démarche d’externalisation des solutions SOA s’articule autour de 2 contraintes fortes: la sécurité et la performance. Il est évident que les flux qui transitent en dehors des réseaux de l’entreprise doivent être sécurisés. Par exemple, la sécurité des flux provenant du Front-End et du Back-End doit être maximale… même au détriment de la performance. Cette dernière bien qu’importante, se doit d’être acceptable pour l’utilisateur.

Sécurisation des échanges

Pour garantir la sécurité des flux qui transitent entre les différents couches, il est nécessaire de scinder le réseau global en des réseaux plus fins. Nous retrouvons alors des principes traditionnels au sein de chaque réseau avec:

  1. Le passage obligatoire des flux par une DMZ
  2. Les flux extérieurs (entrants/sortants) sont sécurisés avec
    1. un protocole sécurisé
    2. un message crypté ou/et signé

Ceci donne, pour notre cas d’école, 4 réseaux différents:

  1. Le réseau de l’utilisateur
  2. Le réseau des applications Front-End
  3. Le réseau SOA
  4. Le réseau des applications Back-End
Décomposition en N réseaux
Décomposition en N réseaux

ESB Proxy

Une excellente pratique est de déléguer la gestion des flux sécurisés (ou non) à un ESB. Il nous faut donc ajouter un ESB dans chaque DMZ en tant que responsable de la sécurité des échanges. Autant que se peut, nous utiliserons des Proxies de services afin de ne pas complexifier le routage des flux du SI. L’utilisation d’un ESB en frontal du Front-end est ici discutable. Il existe des outils d’API Management plus intéressants. Cependant comme les concepts portés sont identiques, je garde cet élément pour ne pas complexifier mon exemple.

Au final, un ESB Proxy sert de façade à un autre ESB distant. Il expose les même services et lui délègue le routage via des échanges sécurisés.

ESB Proxy
ESB Proxy

Lorsque que l’on dresse le parcours d’un message, la succession d’éléments applicatifs s’allonge encore un peu:

  1. Le navigateur de l’utilisateur
  2. Le Front-End:
    1. ESB en façade
    2. les applications Front-End
    3. ESB en sortie (Proxy du SOA)
  3. Le SOA
    1. ESB en façade
    2. l’orchestrateur SOA
    3. le moteur BPM
    4. ESB en sortie (Proxy du Back-Office)
  4. Le Back-Office
    1. ESB en façade
    2. les applications Back-Office
    3. ESB en sortie (Proxy -partiel- du SOA)

Cette organisation prépare la relocalisation physique des éléments. L’utilisation des ESB garantit, à chaque niveau, la capacité à suivre les SLA des services tout en respectant le couplage lâche de l’architecture SOA.

ESB en proxy et reverse proxy à chaque réseau
ESB en proxy et reverse proxy à chaque réseau

Une autre perspective de l’architecture du Système d’Information est la suivante avec un ESB qui masque la complexité de l’externalisation des ressources:

L'ESB reste le manager des échanges du SI
L’ESB reste le manager des échanges du SI

L’ESB devient réparti et distribué entre des sites distants.

Gestion de la performance

Lors de ces évolutions majeures du Système d’Information (SI), la performance des flux ne doit être dégradée. Pour cela, il est indispensable de commencer par la mesure et le suivi des SLA. Pour être précis, il s’agit même d’une étape préalable au début de la transformation.

Ensuite, 2 opérations sont à réaliser:

  1. Minimiser l’utilisation du réseau par une compression systématique des messages
  2. Espacer les appels sur les données stables.

Pour ce 2nd point, des caches de données et de services doivent être mis en oeuvre dans les ESB Proxies. L’objectif de ce complément est de minimiser les échanges sortants inutiles (référentiels, données stables, etc) sans développement supplémentaire. Par ailleurs, cette réflexion de fond sur les échanges de données est de nature à mieux gouverner les données dans le SI.

Les caches de type DataGrid comme Oracle Coherence ou JBoss Infinispan sont les candidats idéaux: légers, distribués, persistants et performants.

Chaque réseau présente alors une organisation similaire:

Cache intégré à l'ESB Proxy
Cache intégré à l’ESB Proxy

L’utilisation du réseau est à mesurer finement afin d’obtenir des performances acceptables (latences et débits). Les fournisseurs tels que AWS proposent des solutions d’interconnexion forte (AWS Direct Connect) qui doivent être étudiées lors les analyses de faisabilités amonts. Quoiqu’il en soit, il est évident que la criticité des liens physiques entrants et sortants (Fibre, ADSL, etc) s’accroît encore dans ces architectures XaaS.

Conclusion

Cet article simple a pour objectif de démontrer l’intérêt de l’ESB dans une transformation du Système d’Information vers l’utilisation des services IaaS et PaaS. Sa capacité à masquer les contraintes en fait un allier stratégique dans la conduite des changements.

Plus finement, les 2 points sensibles et majeurs sont bien la sécurité et la performance. La sécurité doit être une préoccupation à tous les étages du SI comme expliqué ci-dessus. Quand à la performance, il s’agit de gagner plus que l’on ne perd. La délocalisation engendre un usage massif du réseau externe. Les pratiques citées permettent de minimiser cette ressource restreinte mais il est indéniable que le bilan sera positif si des gains CPU ou BDD (mis en jeu dans l’orchestrateur ou le BPM) sont attendus.

La gestion de la performance du réseau est un point à traiter avec attention dans le cas des architectures cloud hybrides. Les cas d’usages offerts comme l’utilisation de ressources externes sur dépassement de seuils et le basculement sur un site de secours permettent de contre-balancer et minimiser les quelques millisecondes perdues dans le transport réseau.

Au final, cette vision de l’architecture « SOA as a Service » a le mérite de permettre une transition souple et sans rupture du Système d’information vers une exploitation des plateformes IaaS et PaaS pour le socle SOA.