Pour changer, je vous propose une vidéo d’un petit projet pour illustrer la chorégraphie de services. Pour cela, j’utilise la suite Oracle SOA en version 12.1.
L’objectif est d’expliciter comment réaliser une intégration ou une coordination de services en découpant la complexité. Il est difficile à produire puis à maintenir un système complexe et riches en règles métiers. J’applique donc le principe « diviser pour régner ».
Dans mon exemple, je réalise une intégration dans une base de données afin de vérifier et démontrer plus facilement l’aspect transactionnel.
Le schéma global des services est assez simple :
- Un service de coordination reçoit la demande d’intégration
- 3 services sont appelés :
- L’intégration des champs field1 pour 2 notions (tableA et aTableB)
- L’intégration des champs field2 pour les mêmes notions
- L’ajout d’une dépendance particulière.
Voici cette démonstration :
[embedyt] http://www.youtube.com/watch?v=xh2POb-Kj6c[/embedyt]
Le code est disponible sur Bitbucket: https://bitbucket.org/middlewaresolutions/soa12-dbadapterdemo
J’y ai finalement ajouté une chorégraphie avec WebService. Il s’agit du projet composite PersistAandBWS. Il est similaire à PersistAandB de la vidéo. Vous le trouverez dans le code git.
Au final, ce cas répond à quelques questions couramment posées :
Comment propager une transaction ?
Réponse : Pour le DirectBinding: c’est automatique. Pour les WebServices référents: préciser WSAT12 + MANDATORY.
Est-il possible de travailler sur une même notion dans plusieurs services ?
Oui. Les opérations sont réalisées dans l’ordre dicté par le service de chorégraphie. L’enregistrement est enrichi progressivement.
Le merge du DBAdapter est-il suffisant et efficace ?
Oui. Il faut toutefois faire attention au mapping avec l’attribut « private-owned » des relations. Par défaut, il est à true, ie. les dépendances ne sont par mergées, il est donc préférable mais plus coûteux de le positionner à false pour recharger les instances liées.