(publié le 28/04/2006)

Architectures SOA et Eclipse

Comme nous l'avons décrit dans un article présentant la fondation Eclipse, les projets de la fondation Eclipse couvrent des besoins de plus en plus larges. La création d'outils aidant à la mise en place d'architectures orientées service est devenue un axe de développement prioritaire de la fondation Eclipse (cf article 'SOA tools top Eclipse priority list').
Nous présentons ici les outils SOA qui seront développés par la fondation Eclipse ainsi que ceux, basés sur Eclipse, proposés actuellement par IBM.

Outils SOA développés par la fondation Eclipse

Le projet STP - SOA Tools Platform

Début 2006 la fondation Eclipse a démarré un projet dédié à la création d'outils SOA.
Proposé par IONA, ce projet est nommé STP : SOA Tools Platform. Les principaux contributeurs sont IONA, Sybase, Scapa, Intalio, ObjectWeb, BEA et IBM.
Le but du projet STP est de fournir les outils nécessaires à la mise en œuvre d'architectures orientées services en se conformant aux travaux sur une nouvelle spécification : SCA (Service Component Architecture). Cette spécification lancée fin 2005 est le fruit d'une coopération entre BEA, IBM, IONA, Oracle, SAP et Sybase.

Présentation de SCA SCA propose un modèle de composants permettant de construire une architecture SOA. SCA identifie deux étapes majeures pour la construction d'une architecture SOA : - l'implémentation des composants qui proposent des services. - l'assemblage de ces composants en définissant les liens entre composants. Les outils proposés dans le cadre STP metteront en évidence ces deux étapes. La volonté majeure de la spécification SCA est de ne pas imposer de choix technologiques : SCA doit permettre de décrire un ensemble de services et leurs interactions indépendamment des technologies utilisées. Par exemple SCA n'impose pas de technologies d'implémentation particulières pour les composants. Comme illustration une liste de technologies d'implémentation est citée dans la spécification : langages de programmation : C++, COBOL, Java, BPEL, PHP. langages déclaratifs : SQL, XQuery, scripts XSLT. modèles de composants existants : EJB, CORBA, Spring beans. De la même façon il n'y a pas de format imposé pour la description des interfaces. WSDL et la notion d'interface Java sont tout de même privilégiés par la spécification . Les principales notions décrites dans la spécification SCA sont les suivantes : L'architecture SCA est basé sur la notion de composants. les composants sont organisés en modules.. chaque composant propose des fonctionnalités métier regroupées en services. les fonctionnalités proposées par un service sont décrites dans une interface. Les services sont des contrats. Les composants sont des implémentations de ces contrats. un composant peut invoquer les services de d'autres composants qui se trouvent soit dans le même module soit dans un autre module. Dans ce deuxième cas cet autre module doit exposer les services utilisable en dehors du module sous-forme de points d'entrée. le lien entre des composants de différents modules ne se fait pas directement : pour assurer un couplage faible, chaque module déclare une liste de références de services vers les services externes au module qu'il souhaite pouvoir invoquer. les références de services sont associées à des services externes qui peuvent être soit définis dans d'autres modules soit être fournis par des éléments externes au système SCA (WebServices existants, services accessibles par un connecteur JCA, procédures stockées...). disposant de points d'entrée et de références de services, les modules peuvent être assemblés pour créer des sous-systèmes SCA.   La spécification précise que les composants doivent être "coarse-grained" (littéralement "à gros grains"), ce qui signifie que SCA considère que chaque composant doit exposer relativement peu de services et que chaque service prend en paramètre des structures de données assez larges. La spécification précise bien que SCA n'est pas un modèle de type objets distribués (dont la granularité est généralement plus fine), et que, même si les services peuvent être implémentés en technologie objet, les paramètres des services sont des structures de données et non des objets. Pour la description des structures de données SCA recommande fortement l'utilisation de la spécification SDO (Service Data Objects) STP a pour but de fournir les outils permettant d'implémenter une application conforme à SCA. Parallèlement à la création du projet STP, le projet Apache Tuscany (http://incubator.apache.org/tuscany/index.html) a été initié pour fournir une implémentation d'exécution de SCA.

Le projet STP prévoit de fournir des outils destinés aux architectes et aux développeurs. Ces outils couvriront les différentes phases de la mise en place d'une architecture SOA : conception, configuration, assemblage, déploiement et supervision.

Actuellement (avril 2006), le projet STP est en phase de démarrage et il n'y a pas de version téléchargeable. Par contre l'organisation du projet est connue, les premiers travaux se feront dans le cadre de cinq sous-projets :

STP Core Framework (CF)

Ce sous-projet sert de base aux autres sous-projets STP. Il propose un framework permettant de manipuler les notions définies dans la spécification SCA. Ce framework devrait être rapidement disponible car IBM propose une contribution initiale qui couvre les objectifs de ce sous-projet.

STP SOA System (SOAS)

SOAS a pour but de couvrir la phase de développement en proposant des outils pour assembler, tester, déboguer et exporter des services.

STP Service Creation (SC)

SC se focalisera sur l'implémentation d'assistants pour la création et l'édition des interfaces des services.

STP BPEL 2 Java (B2J)

B2J proposera un générateur de code Java à partir de définitions de processus métier au format BPEL. Ce projet cible la phase déploiement, en plus de la conversion en classes Java d'un processus BPEL, le sous-projet B2J propose un moteur d'exécution sur lequel s'appuient les classes générées. B2J n'a pas pour objectif de proposer d'éditeur BPEL. Pour information, le code initial de ce projet provient de développements réalisés pour les besoins internes du projet TPTP (Test and Performance Tools Project).

STP BPMN

Le sous-projet BPMN proposera des outils de conception visuelle de processus conforme à BPMN (Business Process Management Notation).

La première version stable des différents composants devrait être disponible pour l'été 2006, les versions stables suivantes seront synchronisées avec les nouvelles versions d'Eclipse et des principaux projets ('Release train').

Roadmap d'Eclipse STP

En savoir plus :
- La page de STP
- La page consacrée à SCA sur le site d'IBM
- Un interview du responsable du projet SOA

L'outillage WebServices du projet WTP

La définition d'une architecture orientée services ne se résume pas à la création de WebServices. Pour autant il est fréquent de rencontrer les WebServices dans une architecture SOA. Le projet WTP (WebTools Project) propose l'outillage nécessaire au développement de WebServices. Les principales fonctionnalités de cet outillage sont :

• création de WebServices à partir de classes Java ou d'EJB (approche 'Bottom-up').
• génération de l'implémentation Java d'un WebServices à partir d'un fichier WSDL (approche 'Top-down').
• génération de classes clientes Java pour invoquer un WebServices
• déploiement et test des WebServices. Possibilité de visualiser le détail des échanges SOAP en utilisant le 'TCP/IP Monitor'.
• édition des fichiers WSDL (édition du code source ou édition visuelle).
• validation des fichiers WSDL.

Le projet STP réutilisera l'éditeur de fichiers WSDL fourni par WTP :

Le sous-projet BPEL Designer

L'orchestration des services est un besoin de base des architectures SOA. Initié par Oracle et co-développpé avec IBM, le sous-projet 'BPEL Designer' a pour objectif de fournir un éditeur visuel de processus générant des descriptions de processus au format BPEL. La version de BPEL ciblée est la version 2.0 (en cours de spécification).
La première version stable de BPEL Designer est planifiée pour début octobre 2006, mais il est possible de télécharger le projet dans son état actuel (le code initial a été contribué par IBM et provient du produit WebSphere Integration Developper).

En savoir plus :
- La page de 'BPEL Designer'.

Outils SOA proposés par IBM

L'offre SOA d'IBM est en pleine construction (cf 'IBM announces 31 SOA products'). Les principaux produits de cette offre SOA sont:

• pour le déploiement WebSphere Process Server.
  
• pour la conception et le développement WebSphere Business Modeler, Rational Application Developer et WebSphere Integration Developer.
• pour la supervision WebSphere Business Monitor

IBM propose le scénario suivant pour illustrer le positionnement des différents produits :

1- Pour commencer, la modélisation des processus métier se fait en utilisant WebSphere Business Modeler.
2- Les différents composants de l'application sont ensuite développés en utilisant Rational Application Developer.
3- L'interaction entre les composants est spécifiée en utilisant WebSphere Integration Developer.
4- L'application est exécutée par WebSphere Process Server.
5- WebSphere Business Monitor permet d'obtenir en temps réel des indicateurs liés aux déroulements des processus métier.

WebSphere Business Modeler

WebSphere Business Modeler n'est pas un outil de développement, c'est un atelier destiné aux analystes métier qui permet de modéliser, simuler et optimiser les processus métier.

En savoir plus :
- L'article: 'Model a business process with WebSphere Business Modeler' (Part 1)
- L'article: 'Model a business process with WebSphere Business Modeler' (Part 2)
- La page du produit WebSphere Business Modeler

WebSphere Integration Developer

WID est une version étendue de Rational Application Developer. En plus des fonctionnalités de développement d'applications J2EE et de WebServices proposées par RAD, WID propose l'outillage permettant d'assembler des services en utilisant les concepts définis dans la spécification SCA. Les processus créés peuvent être téstés sur le serveur WebSphere Process Server de test intégré à WID.
La spécification SCA n'impose pas de choix technologique particulier mais dans le cadre de WID Java est privilégié.

Le point central de l'outillage de WID est un éditeur visuel permettant de la création de modules SCA.

Chaque module est un assemblage de composants. L'éditeur de module permet la déclaration des composants, la définition de leurs interfaces et la définition des liens entre les composants. Deux grandes familles de composants sont proposés dans la palette de l'éditeur:

• les composants définis ou implémentés avec les autres outils de WID. Ces composants s'exécuteront dans le serveur WebSphere Process Server.
• les composants externes qui seront invoqués à distance par WebSphere Process Server via différents mécanismes (WebServices, JMS, JCA ou EJB session).
  
  

Concernant la première famille de composants les types proposés par WID sont :

• Java : composant associé à une classe Java.
• Human Task : composant qui nécessitera une intervention humaine. WebSphere Process Server propose des APIs qui permettent à une application de signaler la réalisation d'une tâche par l'utilisateur. Pour plus d'information voir L'article: 'Use IBM WID to assemble components - Set up human Tasks'.
• Process : composant associé à une description de processus BPEL. Ce type de composant est central car il permet de spécifier l'orchestration des appels aux autres composants. WID propose un éditeur de processus BPEL. Cet éditeur est celui qui a été contribué au sous-projet BPEL Designer (décrit plus haut dans cet article).
• Rule Group : composant constitué à partir de règles métier configurables en production. Un assistant permet de défnir ces règles sans avoir recours à du code Java.
• State Machine : composant permettant de faire de l'orchestration en se basant sur une machine a état. Un éditeur visuel particulier est fourni par WID.

Editeur de 'State Machine'

WID propose d'autres outils. La vue 'Business Integration' permet d'avoir une vision globale des notions associées à un modules.

A partir de cette vue, il est notamment possible :

• d'ouvrir l'éditeur d'assemblage de composants.
• de visualiser la liste des interfaces associées au module et d'ouvrir l'assistant de création d'interfaces.
• de visualiser les types de données associés au module et d'ouvrir l'assistant de définition de nouveaux types de données. Cet assistant masque complètement l'utilisation de SDO.

En savoir plus :
- L'article: 'A guided tour of WebSphere Integration Developer - Part1'.
- L'article: 'A guided tour of WebSphere Integration Developer - Part2'.

Conclusion

Les outils de développement d'architectures orientées services sont récents. Le projet STP est amené à jouer un rôle important en proposant un outillage complet en open-source. En attendant les premières versions stables de STP, les produits IBM, notamment WebSphere Integration Developer, permettent de mettre en oeuvre des architectures SOA basées sur la spécification SCA.