Vers une future standardisation de SDO par l'OASIS

Suite à la décision de l'organisation OSOA (Open Service Oriented Architecture) de soumettre ses spécifications SCA et SDO à l'OASIS, un comité technique OASIS SDO TC a été créé en novembre 2007 pour standardiser SDO (Service Data Objects).

Dans une première phase, le comité poursuivra les travaux de l'OSOA autour du langage C++ en maintenant la cohérence avec la version Java standardisée par le JCP (Java Community Process) sous la JSR 235.

Dans un deuxième temps, le comité travaillera à la production de la version 3.0 de la spécification. Cette nouvelle version intégrera notamment l'interopérabilité avec la plate-forme .NET (ADO.NET) et le support des langages compatibles .NET. Enfin, d'autres langages pourraient être supportés parmi lesquels C, COBOL, PL/I, JavaScript, PHP, Python, Perl, Ruby et Groovy.

Pour les langages Java, C++ et .NET, un document de spécification V3.0 sera publié, accompagné d'une suite de tests de conformité des implémentations. Il en sera de même pour chacun des langages complémentaires qui pourront être retenus.

Une grande partie des membres du comité proviennent de l'organisation OSOA.

La charte du comité technique SDO est accessible ici.

Technorati tags : soa osoa oasis sdo
Del.icio.us tags : soa osoa oasis sdo

SCA et SDO ne sont pas des standards

Cet article de Dana Gardner m'a bien fait rire.

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

Prochaine soumission des spécifications SCA et SDO à l'OASIS

L'organisation OSOA (Open Service Oriented Architecture) vient d'annoncer simultanément la publication de la version 1.0 de la spécification SCA et son intention de soumettre les spécifications SCA et SDO à l'OASIS pour standardisation.

Technorati tags : soa osoa oasis sca sdo
Del.icio.us tags : soa osoa oasis sca sdo

WebSphere Registry and Repository et gouvernance SOA

IBM vient d'annoncer la prochaine disponibilité (entre autres) de son nouveau produit de gestion de la gouvernance d'architectures SOA : WebSphere Registry and Repository.

Celui-ci intègre donc les fonctionnalités maintenant classiques d'un annuaire de services UDDI (registry), mais également de nouvelles fonctionnalités de gestion des métadonnées référencées par l'annuaire (repository).

Malheureusement, comme pour les autres produits qui ont vocation à gérer les artefacts (descriptions de services WSDL, schémas de messages XSD, descriptions de processus BPEL, stratégies assertives WS-Policy) nécessaires à la gouvernance des architectures SOA, WebSphere Registry and Repository (WSRR) ne contribue pas à dissiper la confusion qui règne actuellement dans ce domaine.

Ce document fournit des informations relatives à l'architecture et aux APIs de WSRR. La documentation InfoCenter est encore plus précise. L'API Reference décrit des APIs propriétaires Java et une API de service Web qui n'implémente qu'une partie des APIs Java. De plus, cette dernière s'appuie sur une représentation des données en format SDO (Service Data Objects) encore loin d'être un standard reconnu par tous les acteurs du monde SOA. Pour l'heure, la spécification SDO n'est qu'une spécification Java (JSR 235) contrôlée par le JCP, même si des implémentations C++ ou PHP existent (voir aussi ici). Nous sommes encore loin d'un standard reconnu par le W3C ou l'OASIS comme tous les autres standards SOA. Par ailleurs, il semble que WSRR n'implémente pas le standard OASIS UDDI ...

Il est clair que nous attendons maintenant des éditeurs de solutions de gouvernance SOA que ceux-ci s'engagent à spécifier et à standardiser la manière dont fonctionne la partie repository associée aux annuaires de services. Nous ne pouvons nous satisfaire de solutions propriétaires et donc non interopérables qui lient les mains des clients (voir initiatives GIF et SOA Link).

Le succès du développement des architectures SOA n'interviendra qu'à deux conditions :

• Que toutes les briques techniques soient standardisées et interopérables ;
• Que tous les standards implémentés soient libres de droit.

Si les derniers événements montrent une progression sur ces questions relative à différentes problématiques (nouveaux profils d'interopérabilité du WS-I, unification de la gestion des pièces attachées sous MTOM/XOP, convergence des frameworks de supervision WS-Management et WSDM, publication de l'Open Promise Specification par Microsoft, ...), en ce qui concerne la gouvernance, nous assistons plutôt à une stagnation, voire hélas, à une régression vers des solutions propriétaires.

Technorati tags : soa governance ws-* ibm wsrr sdo uddi
Del.icio.us tags : soa governance ws-* ibm wsrr sdo uddi