Noel Rocher, Laurent Le Grandois, Francois Le Droff noel.rocher@jboss.comNoel RocherLaurent.LeGrandois@atosorigin.comLaurent Le GrandoisFrancois.ledroff@atosorigin.comFrancois Le Droff 30-oct-2006 fr XFire 1.2.2 MIT http://xfire.codehaus.org/ Framework de développement, déploiement et consommation de web services en environnement J2EE (partie Web) 1.6 j2ee-ws-stack

Les critères génériques de la méthode qsos version 1.6 Pérennité Maturité moins de 3 mois entre 3 mois et 3 ans plus de 3 ans 1 Projet démarré en 2004 (CVS Créé le 2004-03-14) Logiciel instable avec de nombreuses versions et patches générant des effets de bords. Version de production stabilisée mais un peu vieille. Quelques difficultés à stabiliser les versions de développement. Logiciel stable. Les nouvelles versions corrigent des bugs, mais apportent de façon prépondérante de nouvelles fonctionnalités. 0 Version 1.2.2 sortie le 03/10/2006. Les projets Xfire et Celtix ont décidé le 22/07/2006 de fusionner. Le nouveau projet s'appellera Apache CeltiXfire Le logiciel connaît de nombreux problèmes qui peuvent être rédhibitoires. Pas de problèmes majeurs, ni de crise. Bon historique de gestion de projet et de crise. 0 Fusion Xfire avec Celtix Forte probabilité de fork dans un futur proche. Le logiciel provient d'un fork mais a très peu de chances d'être forké dans un futur proche. Très faible probabilité de fork. Le logiciel ne provient pas d'un fork. 0 Possibilité de changer la license Adoption par la communauté et l'industrie Très peu d'utilisateurs identifiés Usage détectable sur Internet Nombreux utilisateurs et références 1 Peu connu Aucune Peu de références, pas d'usage critique Souvent implémenté sur des applications critiques 1 Peu de références ( inf 10) Pas de communauté ou de réelle activité (forum, liste de diffusion, ...) Communauté existante avec une activité notable. Communauté forte: grosse activité sur les forums, de nombreux contributeurs et défenseurs. 1 13 Commiters sur Xfire, mais communauté CodeHaus Aucun livre sur ce logiciel. Moins de 5 livres publiés sur ce logiciel. Plus de 5 livres publiés sur ce logiciel et dans différentes langues. 0 Aucune publication trouvée Organisation et direction des développements 1 ou 2 individus engagés, pas clairement identifiés. Entre 2 et 5 personnes indépendantes. Plus de 5 personnes. 1 Un développeur semble être le gardien du projet Dictature complète. Despotisme éclairé. Conseil d'architectes avec un leader identifié (ex: KDE) 1 Communauté Activité du et autour du projet Moins de 3 développeurs, pas clairement identifiés. Entre 4 et 7 développeurs, ou plus, non identifiés, avec un "turnover" important. Plus de 7 développeurs, équipe très simple. 1 Peu de développeurs référencés Réactivité faible sur le forum ou sur la liste de diffusion, ou rien au sujet des corrections de bugs dans les notes de versions. Activité détectable mais sans processus clairement exposé, temps de résolution long Forte réactivité, basée sur des rôles et des assignations de tâches 1 A ce jour, 200 bugs ouverts Pas ou peu de nouvelles fonctionnalités Évolution du produit conduite par une équipe dédiée ou par des utilisateurs, mais sans processus clairement exposé Les requêtes pour les nouvelles fonctionnalités sont clairement outillées, Feuille de route disponible 2 Désir clairement exprimé d'obtenir une intéropérabilité maximale Très faible activité que ce soit sur les versions de production ou beta/de développement Activité que ce soit sur les versions de production ou beta/de développement, avec des versions correctives mineures fréquentes. Activité importante avec des versions correctives fréquentes, et des versions majeures planifiées liées aux prévisions de la feuille de route 1 Pas de visibilité Niveau d'industrialisation du projet Développements réalisés à plus de 60% par des employés d'une seule société. 60% maximum 20% maximum 0 Offres de services Pas d'offre de formation identifiée Offre existante mais restreinte géographiquement ou à un seul langage ou fournie par un seul fournisseur Offre riche, plusieurs fournisseurs, plusieurs langages, divisée en modules et en niveaux 0 Pas de formations référencées Pas d'offre de support identifiée Offre existante mais restreinte géographiquement ou à un seul langage ou fournie par un seul fournisseur, ou sans garantie Offre riche, plusieurs fournisseurs, avec des garanties (sur les temps de résolution). 1 1 offre de support commercial : http://envoisolutions.com Pas d'offres de conseil identifiées Offre existante mais restreinte géographiquement ou à un seul langage ou fournie par un seul fournisseur Offre riche, plusieurs fournisseurs, plusieurs langages 1 1 seule offre référencée Pas de documentation utilisateur La documentation existe mais est en partie obsolète, ou restreinte à un seul langage, ou peu détaillée Documentation à jour, traduite, et éventuellement adaptée à différentes cibles de lecteurs (end user, sysadmin, manager, ...) 2 Nombreux guides disponibles sur le site Processus et méthode qualité Pas de processus Qualité identifié Processus Qualité existant, mais non formalisé ou non outillé Processus automatique de tests dans le cycle de vie du code et publication des résultats 2 Pas d'outils de gestion de bugs, ni d'outils de ticketing Outils standards fournis (une forge par exemple) mais peu utilisés Utilisation très active des outils 1 Pas de méthodologie référencée Niveau d'exploitabilité Difficulté d'utilisation, demande une connaissance approfondie des fonctionnalités du logiciel Ergonomie austère et très technique Ergonomie élaborée et IHM comprenant des fonctions d'aide 1 Pas de fonctionnalités de contrôle, ni d'administration Fonctionnalités présentes mais incomplètes ou à améliorer Fonctionnalités complètes et faciles de contrôle, et d'administration. Intégration possible avec des outils tiers (ex: SNMP, syslog, ...) 0 Adaptabilité technique Logiciel monolithique Présence de modules haut niveau permettant un premier niveau d'adaptation Conception modulaire, permettant des adaptations faciles par sélection et/ou création de modules 2 Fonctionnalités gérées par modules Tout à la main Recompilation possible mais complexe, sans outils, ni documentation. Recompilation facile, outillée (ex: make, ANT, maven...), et documentée. 1 Scripts Ant et Maven2 Toute modification demande une recompilation du code Architecture conçue pour des extensions statiques mais exige une recompilation Architecture de plugins, conçue pour des extensions dynamiques et sans recompilation 2 Possibilité de définir des handlers Stratégie du projet License Licence très stricte, comme la GPL Licence modérée entre les deux extrêmes (GPL et BSD), licence duale dépendante du type d'utilisateur (personne, société, ...) ou de leur activité. Licence très permissive comme BSD et Apache 2 MIT licence Licence très permissive comme BSD et Apache Licence modérée entre les deux extrêmes (GPL et BSD), licence duale dépendante du type d'utilisateur (personne, société, ...) ou de leur activité. Licence très stricte, comme la GPL 0 MIT licence Les droits sont détenus par quelques individus ou entités commerciales, facilitant le changement de licence Les droits sont détenus par de nombreux individus de façon homogène, rendant le changement de licence très difficile Les droits sont détenus par une entité légale, une fondation dans laquelle la communauté a confiance (ex: FSF, Apache, ObjectWeb) 1 Quelques individus Pas de moyen pratique de proposer des modifications de code Des outils sont fournis pour accéder et modifier le code (ex: CVS, SVN) mais ne sont pas vraiment utilisés pour développer le produit Le processus de modification de code est bien défini, exposé, et respecté, basé sur des rôles bien définis. 2 Code placé sous SVN/CVS Pas de feuille de route publiée Feuille de route sans planning Feuille de route versionnée, avec planning et mesures de retard 1 Roadmap pas très bien définie (Fusion avec Celtix) Le logiciel n'a pas de sponsors, l'équipe principale n'est pas rémunérée Le logiciel a un sponsor unique qui détermine sa stratégie Le logiciel est sponsorisé par l'industrie 1 1 Société référencée Pas de stratégie détectable ou forte dépendance à un acteur unique (individu, société, sponsor) Vision stratégique partagée avec plusieurs autres projets open-source mais sans engagement fort des propriétaires des droits Indépendance forte de l'équipe de développement, droits détenus par une entité, fort engagement dans un processus de standardisation 2

JAX-RPC supporte SOAP avec des attachements, vous pouvez employer JAX-RPC APIs pour envoyer des attachements MIME. Mais les types MIME ne peuvent pas être décrits par l'interface WSDL. JSR/API non implémentée JSR/API partiellement implémentée, ou implémentation défectueuse JSR/API implémentée, implémentation stable Non supporté. 0 SAAJ fournit une manière standard d'envoyer des documents XML par Internet depuis la plateforme de Java. SAAJ 1.3 supporte SOAP 1.2. Pour plus d'informations sur les spécifications de SAAJ. SAAJ est souvent utilisée par des APIs de plus haut niveau comme JAXR et JAX-RPC. Mais, elle peut tout à fait être utilisée de manière indépendante. JSR/API non implémentée JSR/API partiellement implémentée, ou implémentation défectueuse JSR/API implémentée, implémentation stable Support prévu pour la version 2.0 0 JSR/API non implémentée JSR/API partiellement implémentée, ou implémentation défectueuse JSR/API implémentée, implémentation stable 0 Donne un moyen uniforme d'utiliser les registres basés sur des standards tels que ebXML ou UDDI. Permet l'accès à différents types de registres XML. Ces registres XML sont une infrastructure permettant la construction, le déploiement et la découverte de Web services. JAXR permet l'interaction avec plusieurs standards, dont UDDI (Universal Description, Discovery, and Integration) et ebXML (Registry and Repository standard). API non implémentée API partiellement implémentée, ou implémentation défectueuse API implémentée, implémentation stable 2 JAX-WS est la pièce maitresse de la « pile intégrée » qui inclut JAX-WS 2.0, JAXB 2.0, et SAAJ 1.3. La pile intégrée représente une nouvelle architecture logique de la fonctionnalité des services Web. JSR/API non implémentée JSR/API partiellement implémentée, ou implémentation défectueuse JSR/API implémentée, implémentation stable Incomplet 1 La JSR 181 définit un format d'annotations facilitant la définition des services WEB JSR/API non implémentée JSR/API partiellement implémentée, ou implémentation défectueuse JSR/API implémentée, implémentation stable Supporté sur JDK1.4 et JDK5 2 La JSR 222 fournit une manière aisée de lier un schéma XML à une représentation en code Java. JAXB utilise des schémas (W3C XML Schema) pour faire ces liens. Une fois ce lien créé (grâce à un compilateur qui va générer les packages correspondant à un schéma donné), vous pouvez facilement sérialiser/desérialiser les objets Java sous un format XML. JSR/API non implémentée JSR/API partiellement implémentée, ou implémentation défectueuse JSR/API implémentée, implémentation stable 2

XML-RPC est un protocole RPC (Remote procedure call), une spécification simple qui permet à des processus s'exécutant dans des environnements différents de faire des appels de méthodes à travers un réseau (protocole HTTP pour le transport des données et la norme XML pour le codage des données). XML-RPC est conçu pour permettre à des structures de données complexes d'être transmises, exécutées et renvoyées très facilement. XML-RPC est l'ancêtre de SOAP non supporté support limité supporté 0 Simple Object Access Protocol (SOAP): protocole RPC orienté objet bâti sur XML et recommandé par le W3C. Il permet la transmission de messages entre objets distants, ce qui signifie qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur une machine distante (par protocole HTTP, SMTP, etc ...) non supporté support limité supporté Support complet 2 La version 1.2 de SOAP présente un certain nombre de modifications dans la syntaxe et fournit de la sémantique supplémentaire (ou clarifiée) par rapport à SOAP 1.1 non supporté support limité supporté Support complet 2

En 2000, la note du W3C sur SOAP Messages with Attachments (SwA) a expliqué comment continuer à utiliser MIME (Multipurpose Internet Mail Extensions) pour des attachements référencés dans le header de SOAP. Si MIME est toujours utilisable, d'autres protocoles ont vu le jour. non supporté support limité supporté Support prévu pour la version 2.0 0 XOP (XML-binary Optimized Packaging) : permet d'inclure dans le fichier XML des données binaires (par exemple pour des fichiers images, son, video) pour « améliorer l'efficacité ». MTOM (pour Message Transmission Optimization Mechanism) est une description de la façon dont XOP est utilisé dans le transport SOAP HTTP. Il spécifie comment gérer les pièces attachées à un message Soap 1.2. Le message et la pièce attachée sont encapsulés dans une enveloppe Mime Multipart. MTOM fournit un mécanisme de pointeur logique - l'élément xbinc:Include -, qui permet de créer des références internes aux pièces attachées - directement dans le message Soap. Cette approche facilite le traitement des messages Soap et favorise leur atomicité. non supporté support limité à XOP MTOM complètement supporté 2

Ensemble de spécifications et de règles facilitant l'intéropérabilité entre services web régis par les protocoles SOAP non supporté support limité supporté 2 Complète Basic Profile 1.1. Fournit le support des messages SOAP à base de pièces jointes. non supporté support limité supporté 0

non supporté support limité supporté 2 non supporté support limité supporté 0 non supporté support limité supporté 0 non supporté support limité supporté 2 non supporté support limité supporté Experimental 1 non supporté support limité supporté 0

UDDI : acronyme de Universal Description Discovery and Integration, est une norme édictée par l'OASIS définissant une technologie d'annuaire basée sur XML et plus particulièrement destinée aux services Web, notamment dans le cadre d'architectures de type SOA (Service Oriented Architecture). Un annuaire UDDI permet de localiser sur le réseau le service Web recherché. Il repose sur le protocole de transport SOAP. non supporté support limité supporté Possibilité d'accès annuaires UDDI 2.0 via JAXR 2 abréviation de l'anglais Electronic Business using eXtensible Markup Language signifiant commerce électronique en utilisant XML, est une suite de spécifications basées sur le langage XML et définissant un standard pour le commerce électronique. Ce standard est édité par l'OASIS. ebXML s'adresse aux entreprises de toutes tailles, en permettant de définir les échanges électroniques entre l'entreprise et ses divers partenaires, comme les catalogues électroniques non supporté support limité supporté Possibilité d'accès annuaires UDDI 2.0 via JAXR 2

Le WSDL décrit une Interface publique d'accès à un Service Web : C'est une description basée sur XML qui indique « comment communiquer pour utiliser le service »; le protocole de communication, et le format de messages requis pour communiquer avec ce service. non supporté support limité supporté : le WSDL est exposé automatiquement 2 La version 1.1 n'est pas approuvée par le W3C, la version 2.0 a pour ambition de devenir un standard officiel approuvé par le W3C. non supporté support limité supporté : le WSDL est exposé automatiquement Support prévu pour la version 2.0 0

WS-Policy permet de spécifier et de prendre en charge les pré-requis et capacités des fournisseurs et consommateurs de services web. non supporté support limité supporté 0 "WS-MEX" permet d'obtenir les informations décrivant le service (WSDL, XSD et policies) Il vise la standardisation des opérations de récupération des "policies d’un endpoint" mais aussi son WSDL et son schéma de données (GetPolicy, GetWSDL, GetSchema). non supporté support limité supporté: exposition des WSDLs, XSDs et policies 0 WS-Security permet d'assurer l'intégrité et la confidentialité du contenu des messages et ce même en présence d'intermédiaires non supporté support limité supporté 2 WS-SecurityPolicy: Définition d'assertions décrivant la manière dont est sécurisé un message. non supporté support limité supporté Prevu pour version 2.0 0 WS-Trust: offre des méthodes permettant d'obtenir, de renouveler et de valider les jetons de sécurité utilisés par WS-Security non supporté support limité supporté 0 WS-SecureConversation: peut être vu comme une optimisation du framework de sécurité. non supporté support limité supporté 0 WS-Addressing : maintient une session entre plusieurs invocations non supporté support limité supporté 2 WS-ReliableMessaging : permet à un système de messages la gestion des pannes et de la perte ou désorganisation des messages. non supporté support limité supporté 0 WS-Coordination : Un framework permettant la coordination des actions au sein d'applications distribuées. Utilisé par WS-AtomicTransactions. non supporté support limité supporté 0 WS-AtomicTransaction : Prise en charge du "commit à deux phases". Toutes les opérations participant à une transaction atomique sont toutes exécutées avec succès ou toutes annulées. non supporté support limité supporté 0

Outil permettant de créer automatiquement les classes Java sur la base d'un WSDL. non supporté support limité, instable ou incomplet (ne génère que la partie cliente ou serveur) bon support (client et serveur), l'outil a une granularité fine de génération 2 outil permettant de créer automatiquement les WSDLs correspondant à des classes Java. non supporté support limité, instable ou incomplet (ne génère que la partie cliente ou serveur) bon support (client et serveur), l'outil a une granularité fine de génération 0 Facilité pour créer des livrables ou archives. Facilité d'intégration au build de génération de code non supporté: génération en ligne de commande support limité: tâche ant uniquement bonne intégration: tâche ant et plugin Maven1 et/ou Maven2 1 Fourniture de plugins pour les environnements de développement intégrés (IDEs) (plugins intégrant les fonctionnalités de génération de code et la création de livrables ou archives). aucun plugin plugin aux fonctionnalités limitées ou défectueuses bon plugin, bonne ergonomie 0 aucun plugin plugin aux fonctionnalités limitées ou défectueuses bon plugin, bonne ergonomie Plugin Eclipse permettant la génération de code à partir d »un WSDL 1 aucun plugin plugin aux fonctionnalités limitées ou défectueuses bon plugin, bonne ergonomie 0

non supporté supporté mais limité ou réalisé par un data binding obsolète ou non standard supporté et réalisé par un data binding standard et extensible (ex: JAXB) 2 Intercepteurs qui peuvent être facilement branchés dans l'environnement d'exécution du service pour réaliser des tâches avant l'arrivée des messages au service et/ou après le traitement du service, avant le renvoi au client. aucun handler/intercepteur supporté support pour handlers/intercepteurs logiques uniquement: capables de modifier le message du service support pour handlers/intercepteurs logiques et protocolaires : c'est à dire capables de modifier le message mais aussi son enveloppe associée au protocole (ex: SOAPHandler et LogicalHandler de JAX-WS 2.0) 2 Gestion des paramètres en entête de requête SOAP ? Ces paramètres sont invisibles, par défaut, pour le client ainsi que pour l'implémentation du service. C'est un contexte implicite pour le service web utilisé par le système de services web ainsi que les Handlers permettant de gérer des problématiques liées à l'environnement d'exécution du service (la sécurité par exemple). Si ces paramètres d'entête SOAP sont "bindés" dans la WSDL à une opération, ils sont ajoutés à la signature de l'opération et seront donc accessibles dans le code du service web. C'est ce qui forme le contexte explicite. paramètres d'entête non gérés support pour contexte implicite: les paramètres d'entête peuvent être connus des handlers support pour contexte implicite et explicite 1 Cette solution de mise en oeuvre de web-services fournit-elle un moyen de gérer les appels asynchrones ? appels asynchrones non supportésles appels asynchrones ont un support limité (au polling). Le client est capable d'envoyer une requête SOAP sans être bloqué, en attente de réponse. Mais le callback n'est pas supporté, seul un mécanisme de polling (boucle de rappel basée sur un temporisateur) est éventuellement prévu. appels asynchrones supportés par les mécanismes de polling mais aussi de callbacks: la conversation est supportée. Le client fournit une adresse de retour, un intercepteur: un "callback handler/end-point". Cette fonctionnalité est intégrée à JAX-WS 2.0. Les notions dérivées de session et conversation sont contenues dans la spécification WS-Addressing. Polling et Callbacks supportés 0

Déploiement difficile, ou nécessitant un outillage non standard, ou de nombreuses étapes ou un reboot du serveur Déploiement aisé, mais nécessitant un arrêt du service Déploiement aisé et à chaud (hot deploy) Déploiement de webapps via console du serveur d'Applicatiosn J2EE 2 pas d'interface ni de fonctionnalité d'administration de gestion du cycle de vie des services fonctionnalités d'arrêt de redémarrage à chaud des services fonctionnalités avancées de gestion du cycle de vie des services et/ou interface d'administration associées Via la console d'admin du serveur d'applications 1

pas d'interface ni de fonctionnalité de production de statistiques d'accès aux services statistiques disponibles uniquement en temps réel, en snapshots ou rapports succints statistiques disponibles sur une période. Génération de rapports évolués Via la console d'admin du serveur d'applications 1