Have a look to wp.me/pcSx0-nn to get a free copy of QuickHubApp @github OS X client (cc @chamerling)—
Cedric Gatay (@Cedric_Gatay) January 12, 2012

My tweet is here:

Have a look to wp.me/pcSx0-nn to get a free copy of QuickHubApp @github OS X client (cc @chamerling)—
Pierre-Yves Ricau (@Piwai) January 12, 2012

Mail: py.ricau at gmail

my tweet : https://twitter.com/#!/sfui/status/157194044232056832

Have a look to wp.me/pcSx0-nn to get a free copy of QuickHubApp @github OS X client (cc @chamerling) quickhubapp.com—
Laurent (@ouaibou) January 11, 2012

Have a look at wp.me/pcSx0-nn to get a free copy of QuickHubApp @github OS X client (cc @chamerling)—
Nicolas Fonrose (@nfonrose) January 07, 2012

My email is at gmail.com

My email : OyoKooN[at]gmail[dot]com

Le titre est bien choisi. Et pour cause, le mot “component” n’a pas la même signification dans Petals et chez Talend. Les approches derrière sont elles aussi différentes. Les composants Talend sont des socles de génération (en gros, ils permettent de générer du code et de l’intégrer dans un script ou une classe Java). Avec Petals, les composants sont des bases de code réutilisables et configurables.

Autrement dit, quand on utilise Talend, on va générer du code (créé en combinant l’utilisation de plusieurs composants Talend), alors qu’avec Petals, on va créer des configurations pour les composants (le principe étant de minimiser la quantité de code à écrire). Les composants Petals sont donc plus génériques, mais cela les rend plus difficile à écrire. Ce n’est pas un problème de framework (même si ça pourrait être mieux), c’est un problème de conception (trouver ce qui est générique et qui devrait être configuré). A noter qu’écrire un composant Talend n’est des plus simples non plus, mais dans la mesure où leur périmètre fonctionnel est plus restreint, il est plus facile de maîtriser leur complexité.

Après, je me base sur mon expérience des composants pour l’intégration de données. L’ESB de Talend s’appuie sur Camel, qui possède lui aussi des composants (enfin, des modules). Je n’ai pas encore eu l’occasion d’aller voir qui fait quoi dans cet ESB (Camel, script d’intégration de données, etc). Pour cette raison, je ne suis pas non plus certain que le SE Talend supporte tous leurs connecteurs (en tout cas, pas ceux de Camel).

Quoiqu’il en soit, modules Camel, composants Talend et composants Petals ont aussi une différence d’utilisation. Les composants Talend, c’est au niveau de l’outillage, pour la génération de code. Les modules Camel, ce sont des librairies Java dont on aura anticipé l’usage avant. Et les composants Petals, ce sont des extensions logicielles que l’on peut déployer et activer (resp. désactiver et désinstaller) à chaud dans le bus. Cela constitue une deuxième différence importante, après celle de la définition.

Maintenant, il est vrai que le nombre de connecteurs est artificiel. Nous avons un connecteur JDBC qui peut aller taper dans plusieurs base de données. Il serait facile de le décliner pour chaque type de BD. Et d’un connecteur, on passe à 50. Si j’étais au marketing, c’est sans doute une évolution que je demanderais (la preuve, tu te sens obligé de décortiquer une telle annonce, c’est bien la preuve que ça marque les esprits ).

PS : je viens de voir que tu as écrit en anglais, alors que j’ai commenté en français. Comme j’ai la flemme de tout traduire, je vais laisser ça comme ça…

Julien L.

En l’état, je ne vais pas me laisser seul, notamment parce que mon planning pour les 2 prochains mois est déjà saturé. Et la roadmap du prochain (prochain) studio va être costaud. Je ne pense pas non plus que ce refactoring puisse être intégré pour la v4 de Petals (celle dont les RC vont commencer à sortir en septembre).

Par contre, pour la version suivante, je pense que ce débat va être nécessaire.
Ce sera l’occasion de confronter les idées, même si je m’attends à pas mal de convergences. Quant à mon histoire de tests, je vais passer sur des projets de tests ad-hoc. Mais on devrait pouvoir les migrer ensuite facilement, vu que ce sera du pur Java avec du JUnit.

Je me prends la tête sur ces frameworks de tests. Ça fait un an et demi d’ailleurs…
Et la seule solution potable, c’est de passer par un conteneur en mémoire, qu’on pourrait directement appeler depuis des tests JUnit (et donc dans Maven). Ce serait super pratique, déjà pour envoyer directement des messages à un composant (provides). Et avec une autre implémentation du transporteur, on pourrait aussi tester les composants qui consomment des services.

Petite réflexion que je me faisais, alors que je me voyais déjà victorieux du refactoring du conteneur… Tant qu’à refactorer, pourquoi ne pas dégager Fractal par la même occasion ? Dans mon cas, il me faudrait faire un effort pour ne pas bundliser les modules du noyau. Mais même en Java pur, ça doit se faire. Il suffit que l’assemblage fasse le disptach entre les composants et qu’il ait un système de class loader efficace (hypothèse forte, je sais…). Au moins, on pourrait débugguer simplement….

J’ais envis de proposer Petals pour mes futur client, mais quid de l’avenir de Petals avec le départ de Pascal Portes ? Et les sites de docs qui ne sont pas très à jour ? Un petals 4 en vue ?

Toujours aussi intéressant de te lire Christophe.
SOA4All semble avoir le mérite de définir des choix de design pour faire du “pur” middleware et autre bus de service.

Où se situe le DSB par rapport au standard AMQP , http://www.amqp.org ?

Par contre, l’URL de base est interdite à l’utilisateur anonyme. Les accès publics pour les produits sont à cette URL : https://svn.petalslink.org/svnroot/trunk/dev/prod/

when I try to use your method I get an error :
Insufficient configuration for Conduit.

???

Even so… you’ve produced a nice article and I really enjoy your writing style.

Pour ce qui est du lightweight, je ne critique aucunement Jonas mais plutot la mise en oeuvre lourde de CXF pour assurer ce transport robuste. Il est clair que l’on ne peut pas tout avoir, le coté lightweight de l’approche et la robustesse de transport asynchrone ne sont peut etre pas compatibles.
Je suis plutot habitué à utiliser CXF de facon simple et rapide (exposer un service rapidement avec JAXWS sur HTTP est un bon exemple). Mais il est clair que lorsque l’on doit mettre une solution d’entreprise en place se basant sur un serveur J2EE, du coup c’est un peu moins rapide. Encore une fois tout depend du contexte.

Par contre, en quoi est-ce que l’approche est “non lightweight” ?
JOnAS présente toutes les caractéristiques d’un serveur d’application léger :
- avec un lancement simple et un démarrage rapide
- modulaire
- configurable à la carte
- construit sur un noyau minimum et extensible

Comme tu le dis l’utilisation de JOnAS permet d’avoir un système de classe entreprise qui délivre les messages avec des clients et des serveurs qui peuvent tomber. ce qui est un pré-requis dans une solution asynchrone fiable.

Mais malheureusement, de trop nombreux développeurs, sous de fortes contraintes extérieures omettent de faire des commentaires intelligents.

Souvent les commentaires sur les setters / getters sont affligeants, puisqu’ils ne répondent pas aux questions suivantes :
- quelles sont les valeurs acceptées par ce champ (ainsi que les éventuels controles effectués par les getters / setters)
- puis-je mettre / recevoir un null (merci Java 7 pour le coup du null safe invocation)
- quel type d’exception suis-je susceptible de rencontrer et pourquoi
- …

La plupart de ces remarques sont valables pour la plupart des méthodes en fait

J’adore ce fonctionnement qui me permet de zapper les transports, et je me suis remise à faire du sport.
Au plaisir de vous lire
Valérie

Merci pour ce commentaire. Je vois que vous êtes aussi en “mode télétravail” mais plus en tant qu’indépendante qui est quand même quelque chose de bien différent où vous êtes rattachée à des clients tandis que je suis salarié d’une entreprise à temps plein. J’imagine quand même que le fonctionnement à la maison doit se rapprocher de celui que j’ai!

J’ai un service avec deux portType, j’ai créé un jbi pour la 1er interface, mais j’obtiens l’erreur suivante lors du déploiement :

Failed to parse the WSDL description bound to the provided service ‘myFirstPort’
Caused by: SchemaException: WSDL 1.1: The endpoints of this service do not implement the same interface

vous avez une idée comment résourdre ce problème ?

Merci d’avance

Te serait -il possible de le faire en anglais sur le wiki