Encore une personne qui ne fait pas la différence entre spécification et standard. Les spécifications SCA et SDO (je dis bien spécifications) viennent tout juste d'être soumises à l'OASIS en vue d'être un jour standardisées. Au mieux, ces spécifications deviendront des standards en 2008, au pire en 2012 (WS-Transaction ou WS-BPEL ont nécessité cinq ans de travail de standardisation), voire jamais (WS-CAF).
Ensuite, cet "expert SOA" précise :
"Microsoft was all for “open” on the Web interoperability level ... Microsoft will pursue its proprietary approach of baking pseudo-SOA into its operating system stack as long as it can".On appréciera l'imparfait ... A mon avis, à l'heure actuelle, ce sont précisément Sun Microsystems et Microsoft qui en font le plus pour tester l'interopérabilité entre leurs piles WS-* WCF (.NET 3.0) et Metro. D'ailleurs, BEA et Oracle, semble-t-il rendus prudents par rapport au degré d'avancement de SCA, travaillent actuellement à l'intégration de Tango (partie de Metro) dans leurs produits.
Vu le reste de l'article, on comprend que pour ce "spécialiste", une architecture SOA implémentée par les technologies de services Web est une "pseudo-SOA". On comprend donc mieux que l'absence de Microsoft dans le consortium OSOA (j'ai toujours bien aimé le "Open" qui sous-entend que ce qui a été publié auparavant, et presqu'entièrement standardisé depuis, n'était pas "Open" : les spécifications WS-* NDLR) soit jugée comme un crime de lèse-SOA.
Par ailleurs, où sont les démonstrations d'interopérabilité des implémentations SCA/SDO ? Où sont les recommandations d'interopérabilité similaires à celles émises via les profils du WS-I ?
Désolé, cher monsieur Gardner, avant que ces spécifications (et non pas standards) bénéficient d'implémentations matures, interopérables et utilisables en entreprise, beaucoup de temps passera, le temps qu'il aura fallu aux spécifications de services Web pour devenir des standards et bénéficier d'implémentations stables et performantes.
Technorati tags : soa osoa oasis sca sdo ws-* tango metro interoperability
Del.icio.us tags : soa osoa oasis sca sdo ws-* tango metro interoperability
2 commentaires:
Bonjour, je suis étudiant en Master informatique et j'aurais une question concernant SCA à laquelle vous pourriez peut-être répondre :
lors d'un processus d'orchestration BEPEL, y a-t-il 1 seul composant qui génère lui même les composants pour chaque nouvelle demande de services, ou N composants correspondant aux demandes de services ?
Comment peut-on suivre le fil d'execution de dans le composant SCA ? par exemple, en entrée on fait des requêtes par l'intermédiaire d'un WS, on obtient un résultat en sortie, mais comment sont organisées les taches à l'intérieur de SCA?
En vous remerciant dans l'attente d'une réponse.
Je ne suis pas sûr de bien comprendre la question.
Ce document de la spécification SCA décrit comment peuvent interagir des composants SCA et des services WS-BPEL. Un service (ou processus) WS-BPEL peut être transformé en composant SCA (génération par introspection du modèle WS-BPEL, par exemple). Un composant SCA pourrait aussi être transformé en service WS-BPEL, moyennant l'introduction d'extensions spécifiques SCA dans le standard WS-BPEL (et à condition que le composant SCA utilise exclusivement des interfaces WSDL car un service WS-BPEL n'invoque que des services partenaires qui exposent des interfaces WSDL).
En ce qui concerne le fonctionnement du service WS-BPEL lui-même, il est très simple : lors de la première invocation du service (sur réception d'un message par une tâche "receive" par exemple), le moteur d'exécution crée une instance du service (ou processus). Si le script du processus (ou modèle) se déroule jusqu'à son terme, le moteur d'exécution détruit l'instance du service. Sinon, si le déroulement du script s'interrompt pour attendre une autre invocation du service, le moteur d'exécution enregistre l'état de l'instance en mémoire persistante, puis décharge l'instance de la mémoire ("déshydratation" du processus). Lorsque la seconde invocation est déclenchée, le moteur d'exécution retrouve l'instance (par corrélation sur un identifiant particulier) et la recharge en mémoire ("réhydratation" du processus) afin qu'elle poursuive son exécution. Si cette fois, le script du processus se déroule jusqu'à son terme, le moteur d'exécution détruit l'instance du service, sinon l'instance est à nouveau déshydratée.
Si le script du processus a besoin, pour fonctionner, d'invoquer un ou plusieurs services partenaires (qui exposent obligatoirement des interfaces WSDL), c'est le moteur d'exécution WS-BPEL qui se charge d'invoquer le service référencé dans le lien partenaire. L'instance du service partenaire invoqué est créée par le moteur d'exécution de services dans lequel est déployé le service partenaire. Celui-ci peut être un composant SCA doté d'une interface WSDL par exemple, ou un sous-processus WS-BPEL (un processus WS-BPEL s'expose comme un service et présente obligatoirement une interface WSDL).
Dans ces mécanismes, il n'y a aucune génération de composants à l'exécution, mais uniquement des création d'instances, soit sous le contrôle du moteur d'exécution de processus WS-BPEL, soit sous le contrôle des moteurs d'exécution des services partenaires lors des appels de services. C'est cette gestion d'instances que l'on désigne sous le terme de "composition de services".
Si le modèle du processus WS-BPEL est transformé en composant SCA (design time), les tâches du processus font partie intégrante de l'implémentation du composant et les services partenaires sont déclarés soit comme des services, soit comme des références (voir page 6 du document). Ces services partenaires peuvent être eux-mêmes transformés en composants SCA (s'il ne le sont pas déjà). Dans ce cas, l'interaction entre le composant SCA qui implémente le processus WS-BPEL et les composants SCA qui implémentent les services partenaires suit le modèle standard SCA. La seule particularité tient au fait que tous ces composants doivent présenter une interface WSDL.
Enregistrer un commentaire