All posts in JAX-WS

Portail Liferay avec GWT intégré en SOA pour Pierre et Vacances

Aujourd’hui je viens vous faire partager une très belle expérience projet. Je vous parlerai donc d’un projet que nous avons réalisé pour notre client Pierre et Vacances, qui a su nous faire confiance jusqu’au bout pour le développement et l’infogérance de son extranet commercial.

Faire des choix en matière d’architecture logiciel en 2010 peut être un exercice difficile, c’est pourquoi l’approche de DocDoku en matière de choix techniques est basée sur les principes suivants :

  • pragmatisme, dans le choix des langages et des technologies,
  • ouverture d’esprit, nous effectuons une veille technologique permanente,
  • mise en contexte, chaque problème étant différent, les réponses à apporter doivent l’être également,
  • industrialisation, il ne s’agit pas de s’emparer de la toute dernière nouveauté mais de bâtir des solutions robustes, matures et maintenables,
  • respect des standards établis, pour garantir la pérennité des applications, et maximiser l’investissement consenti par nos clients, nous nous appuyons sur les standards unanimement reconnus.

Dans le cadre de l’extranet commercial développé pour Pierre et Vacances, les grands principes architecturaux retenus ont été les suivants :

  • utilisation du composant portail open source Liferay permettant un gain de productivité certain en particulier sur les modules génériques (droits d’accès, profils utilisateurs, agenda, publication de news…) mais respectant également la JSR 286, norme de communication entre le portail et les applications qui y sont hébergées, supportée par de nombreux éditeurs (IBM, Sun, Oracle, RedHat). Ceci permet de surcroît de limiter notre dépendance vis-à-vis d’une solution portail en particulier.
  • développement d’une architecture en couches permettant notamment de découpler les composants les uns des autres et de les faire évoluer indépendamment.  Une séparation en couches permet d’adapter en effet l’architecture physique en fonction des besoins de distribution pour une bonne capacité à monter en charge.  Une architecture n-Tiers en 4 couches distinctes a été choisie :
    • La couche d’accès aux données avec JPA-Hibernate dont le rôle est la connexion à la base de données, l’exécution des requêtes ou l’appel des procédures stockées.
    • La couche de service EJB3 et JAX-WS-Metro, ensemble des règles métiers et processus de l’application. Cette couche sera implémentée en Java via des composants transactionnels.
    • La couche métier POJO qui constitue le diagramme de classes des entités (le modèle objet).
    • La couche de présentation avec GWT et Portlet Liferay : l’interface utilisateur affiche les résultats traités par la couche métier.  Ici le framework Ajax GWT a été choisi pour à la fois offrir une ergonomie poussée et une forte maintenabilité.
  • mise en place d’une architecture de type SOA pour pouvoir exposer de façon universelle les fonctions de l’extranet pour les futures applications du SI.

Tout ceci est en production évidemment depuis la fin octobre 2009.

Agilement.

web services avec JAX-WS

Initialement le client (java web start) DocDoku communiquait au serveur (composants ejb) à l’aide du protocole corba IIOP.
Malheureusement, à tort ou à raison, les proxies http sont souvent le passage obligé pour accéder à internet dans de nombreuses sociétés.
Nous avons donc décidé de passer aux web services. Aujourd’hui cette migration est terminée mais je dois avouer que ce fut plus compliqué que prévu. Voici un bref retour d’expérience :

Au niveau sécurité, les options sont nombreuses, nous avons néanmoins opté, par prudence, pour la simplicité : authentification basic sur du SSL.
Ce poste explique ceci en détails.

Ensuite, la grande difficulté a été d’utiliser nos POJOs sur le client et le serveur sans passer par une couche d’objets intermédiaires mappant le wsdl.
Etrangement, aucun tutorial de Sun n’explique clairement cela et les assistants de netbeans génèrent invariablement cette couche d’objets (avec la commande wsimport) même si le webservice a été créé à partir d’une interface SEI (Service Endpoint Interface).
Sous les conseils d’Alexis, j’ai filé un bug chez netbeans.
Enfin, la solution est la suivante, il faut donc définir une interface pour l’EJB avec endpoint webservice et non simplement annoter les méthodes avec @WebMethod.
Ensuite, importer les classes produites par wsgen également sur le client.
Enfin, récupérer le web service Port par javax.xml.ws.Service.getPort(Class<T> serviceEndpointInterface).