Bonnes pratiques de l'integration des services dans Petals

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Bonnes pratiques de l'integration des services dans Petals

petals_fan
Bonjour,

Je souhaite savoir les bonnes pratiques pour integrer des services externes dans Petals ESB.

J'ai un ensemble de services REST à integrer dans Petals. J'ai pensé à quelques solutions. Vu que je n'ai pas encore fait un projet consistent avec Petals, je ne sais pas comment procéder.

- Est ce que je dois créer un provider pour chaque service REST ?
- Est ce que je dois créer un seul provider auquel j'envoie l'adresse du service REST voulu (mettre l'adresse dans le corps du message) ?
- Comment orchestrer les services REST ?

Pouvez vous me citer un exemple concret de l'integration et l'utilisation des services REST dans Petals ESB ?

Merci d'avance
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

Vincent Zurczak
Administrator
This post was updated on .
Bonjour.

Commençons par ce qui fâche.
Il n'y a pas d'intégration mâture de REST avec Petals. La principale raison est que Petals s'appuie sur le paradigme Web Service, que ce soit en interne comme sur la description des services avec WSDL. A la limite, on a déjà évoqué dans le cadre de réflexion des évolutions de la plateforme pour fonctionner sur un mode REST. Mais cela ne change pas le problème de fond : REST et SOAP ne travaillent pas facilement ensemble. Donc, si la plateforme devait fonctionner sur un mode REST, on aurait le problème à l'envers pour SOAP.

Autrement dit, le seul moyen d'intégrer des services REST dans Petals est de développer un composant (Petals) qui va gérer les interactions entre des services REST et l'ESB. Le composant SOAP actuel possède un mode REST, mais à ma connaissance, il n'est pas mâture. Je vous conseillerais donc de développer votre propre composant. Le composant en question sera un binding component (lien entre le bus et le monde extérieur). La difficulté à développer un BC, ce n'est pas simplement supporter un protocole de communication (contrairement par exemple à un binding SCA). C'est aussi et surtout gérer les accès à des ressources externes et internes sur un mode (Web) service.

Cela signifie que...
+ Pour invoquer un service REST depuis le bus, un consommateur lui enverra un message XML, conforme au WSDL du composant / de la SU pour REST. Ce message sera transformé en une requête à passer dans l'URL d'invocation REST. Cela correspond à un mode provider. On va créer / fournir un service dans Petals qui servira de point de sortie vers le service REST.

+ Pour qu'un service REST puisse invoquer un service Petals, il faut que l'invocation se fasse sur le BC REST, parser la requête et construire un message XML à envoyer au service à consommer. Attention, il faudra que le XML envoyé soit conforme au WSDL du service à invoquer, ce qui est loin d'être facile. Il y a plusieurs solutions possibles pour résoudre ce problème, aucune n'étant idéale. Ici, on fonctionnera donc en mode consumes, on va invoquer un service du bus. Et pour écouter les requêtes HTTP, il faudra embarquer un serveur Web (genre Jetty) dans le composant.


Après...
Doit-on créer des SU ou utiliser un service natif au composant (dés l'installation, on a un service dans la registry) ? C'est au choix du développeur, les 2 sont possibles dans Petals. La bonne pratique, c'est plutôt les SU, mais plutôt parce qu'au niveau du composant, on veut mutualiser certains objets. Dans le cas de REST toutefois, je ne sais pas si vaut la peine. Mettre l'URL du service dans le message ne serait pas plus coûteux. En revanche, sur le mode consumes, je pense qu'il vaut mieux créer des SU pour préciser les services à invoquer.


Enfin, la seule contrainte pour pouvoir orchestrer du REST avec BPEL, c'est de décrire le service Petals (qui masque le service REST) avec un WSDL. Après, il faut que ce WSDL ait une structure "potable". Celle-ci peut soit être générique (la même pour tout service REST), soit dépendre du service en question (il va falloir retoucher le WSDL à la main). Là-encore, plusieurs solutions sont possibles. EIP aura le même problème, puisqu'il manipule du XML. La solution la plus légère (et la plus brute) aussi serait peut-être d'avoir un BC simpliste pour REST et de le coupler à du POJO. Mais niveau réutilisabilité du service REST, cela laissera à désirer. A chaque réutilisation du service REST, il est probable qu'il faudra refaire un POJO. Ce sera donc plus de l'intégration que de la SOA.

« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

David P.
Bonjour,

Je remonte ce sujet un peu ancien qui m'a interpellé à propos de l'usage de REST dans Petals.
Y a-t-il eu des évolutions au sujet de REST en v4?

En fait, j'envisage d'utiliser Petals pour plusieurs types de besoins :

- Définir un proxy de web services REST. Ex : Une appli A appelle un WS REST sur l'ESB. L'ESB redirige vers le WS REST de l'appli B ou C en fonction de l'URL appelée.

- Agréger des WS REST et les exposer en tant que web service REST unitaire

- Accéder à l'API REST d'un outil de GED (Alfresco) pour manipuler des fichiers

Beaucoup de REST donc :-) Est-il possible de faire ça facilement avec Petals v4.0?

A l'origine, j'avais été séduit par la facilité de publication de WS SOAP issus d'autres applications, via le Studio. Aurais-je les mêmes facilités en faisant exclusivement du REST?

Merci d'avance
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

Vincent Zurczak
Administrator
Bonjour,

Il n'y a pas de réponse simple.
Sur la v4, il n'y a pas d'évolution car il n'y a pas de conversion standard entre REST et SOAP. Et aussi parce que nous avons travaillé sur d'autres aspects (on traite les demandes client en premier, ce qui est logique). Dans ce sens-là, la réponse est plutôt non.

Maintenant, que je vois vos cas d'usage, ils sont relativement précis et simples.
Il est donc possible de créer un composant Petals pour répondre à ces besoins. On peut après outiller ce composant dans le studio, ce qui le rendrait alors aussi simple à utiliser que la partie service web de Petals. En ce sens, la réponse est alors oui. Mais il faut développer ce composant.

En gros, le composant devrait gérer :
* La réception de messages REST (+ conversion en un message Petals).
* L'émission de messages REST (conversion d'un message Petals en REST).
* Comme c'est un connecteur pour un protocole de communication, ce sera un binding component.

La question, c'est "sera-t-il générique" ?
Pour le dispatch ou l'agrégation de services REST, on pourra utiliser un composant comme EIP ou BPEL pour gérer ça. C'est vraiment la partie connecteur qui est à faire. Ce n'est pas forcément compliqué.

Un exemple récent de connecteur qui pourrait servir de modèle, c'est le BC HL7 (protocole de communication utilisé dans le monde médical). Je l'ai fait cet été, de manière très simple, très rustique, mais qui marche bien. Au niveau REST, ça pourrait ressembler à ça. Et nous avons un guide développeur pour les composants Petals.

« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

David P.
Merci pour cette réponse rapide.

Je n'ai pas accès au code du BC HL7 visiblement. Le navigateur me demande le mot de passe du SVN. Si c'est possible, pouvez-vous me l'envoyer par mail ou le déposer sur un espace de téléchargement pour me faire une idée?

Sur la page produit de Petals (http://www.petalslink.com/produits/petals-esb), il est indiqué : Connecteurs vers les standards les plus répandus : WSDL, SOAP, REST, POP, SMTP, IMAP, EJB, JDBC…

Du coup, je ne saisi pas la nuance entre ces connecteurs et les binding components. Pouvez-vous m'éclairer sur ce point?

Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

Vincent Zurczak
Administrator
David P. wrote
Je n'ai pas accès au code du BC HL7 visiblement. Le navigateur me demande le mot de passe du SVN. Si c'est possible, pouvez-vous me l'envoyer par mail ou le déposer sur un espace de téléchargement pour me faire une idée?
Il y a un accès anonyme (anonymous/anonymous).

David P. wrote
Sur la page produit de Petals (http://www.petalslink.com/produits/petals-esb), il est indiqué : Connecteurs vers les standards les plus répandus : WSDL, SOAP, REST, POP, SMTP, IMAP, EJB, JDBC…

Du coup, je ne saisi pas la nuance entre ces connecteurs et les binding components. Pouvez-vous m'éclairer sur ce point?
Dans Petals, les connecteurs s'appellent des binding components. C'est un terme hérité de la spécification JBI, sur laquelle Petals est basé.

Pour REST, il y a eu une période où nous avons tenté de le supporter directement.
En fait, le connecteur SOAP était un composant à 2 facettes : une pour SOAP et une pour REST (ce qui était possible car le composant s'appuie sur Axis2). Mais ce support était imparfait, ou en tout cas, pas facilement réutilisable. Cette facette existe toujours mais n'est plus mise en avant. Si l'on souhaite faire du REST, il est préférable de créer un composant adapté à ses cas d'usage. De ce point de vue, il faudra donc que l'on mette à jour la présentation de Petals sur le site de la société.
« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

David P.
Ok, effectivement le codage d'un composant parait abordable, mais ça m'embête malgré tout d'en passer par là. Je vais réfléchir à d'autres possibilités.
Merci pour votre réactvité
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

Christophe S.
Hello,

Du neuf depuis avril dernier sur la cohabitation REST/SOAP ou bien en est-on toujours resté à la solution du codage d'un composant spécifique ?
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

Vincent Zurczak
Administrator
Bonjour,

Non, rien de neuf côté produit.
Les idées sont toujours dans les cartons. ;)
« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

gdebarros
Bonjour,

Rien de neuf concernant le support du REST sur Petals 4.3 ?

Cordialement.
Reply | Threaded
Open this post in threaded view
|

Re: Bonnes pratiques de l'integration des services dans Petals

Victor Noël
Administrator
Bonjour,

Il y a dans la future version de Petals, la version 5, un composant REST.

Pour Petals 4.3, il n'y en a pas.

Le problème avec REST, c'est que le mapping entre des URLs, qui pointent potentiellement sur des ressources (le R de REST), et des services (qui représentent donc des opérations) n'est pas évident.
Autant exposer un service Petals vers l'extérieur en REST peut être assez simple (l'API REST ne sera pas orientée ressource mais orientée opération), autant dans l'autre sens, ça peut vite devenir compliqué.

C'est un problème qui n'existe pas avec SOAP, surtout parce que SOAP est clairement défini, alors que REST est un mot clef qui veut dire tout et n'importe quoi.

Si c'est pour qu'un composant externe que vous développez appelle des services Petals, ça vaut le coup de se poser la question de travailler directement en SOAP : en pratique, du point de vue d'un client, SOAP et REST sont très similaire : on envoie un message en HTTP et on récupère une réponse. La seule différence c'est que en SOAP on est obligé d'utilise du XML alors que REST n'impose aucun format particulier.

Dans l'autre sens, vous pouvez envisager de porter le BC REST de la version 5 sur la 4.3 (et ne pas hésiter à partager le résultat avec la communauté :), il y aura un peu de boulot mais ce ne sera principalement que syntaxique. Ou vous pouvez vous adresser à Linagora pour faire ce portage éventuellement :)