A en croire la majorité des éditeurs, il est temps de mettre en œuvre BPEL… D’ailleurs, les offres foisonnent et les besoins d’Orchestration des premiers web services s’expriment plus massivement par les entreprises.
Chacun comprend l’intérêt de disposer d’un moteur d’orchestration respectueux des standards web services (WSDL, SOAP…). Cependant, quels sont les contraintes et les points de vigilance en terme de maturité ? Comment juger le respect du standard par les éditeurs alors que BPEL s’adosse à d’autres standards non stabilisés comme la gestion de contexte (WS-Context) et la gestion de transaction (WS-TXM) ?
Pour aider à une meilleure compréhension des apports et contraintes actuelles de BPEL, ce papier dresse un tour d’horizon du sujet : mode d’invocation des web services, gestion des sous-Processus, calcul des routes, mode d’usage du moteur, interaction avec l’utilisateur, Qualité de services, Modélisation, UDDI.
Mode d’invocation des web services
Le mode d’invocation des web services en BPEL reste figé car il s’appuie sur une déclaration formelle en XML : on nomme les WSDL (portType ou endpoint) avec lesquels le processus interagit… C’est donc une décision prise au moment du développement qui n’est plus révisable lors du passage en exploitation.
Le processus BPEL ne sait pas introspecter automatiquement un annuaire de services, par exemple UDDI, pour dynamiquement choisir la bonne version d’un web service selon le contexte d’exécution du processus…
Pour remédier à cette rigidité, on implémente les web services orchestrés par BPEL sous la forme de simple façade dont le rôle est d’invoquer une factory qui renvoie, selon le contexte d’exécution, la bonne version de l’implémentation du web service (le endpoint).
|
|
Lire la suite...
|
