Article publié par Guillaume Arnaud le 15 juillet 2010.
Catégorie(s) : Java / JEE
Comment valider un bean ? L’idée de départ, comme toutes les bonnes idées, est très simple. Avant, pour confirmer que des données étaient valides selon certains critères métiers, le développeur pouvait être amené à intervenir sur plusieurs couches. Il pouvait agir, par exemple, sur la couche présentation, en ajoutant du javascript pour contrôler un champ du formulaire, ou bien ajouter du code de vérification dans la couche DAO avant de persister en base. Cette spécification a eu pour objectif, d’une part d’enrichir les entités métiers sur les valeurs que pouvaient prendre ses propriétés, et d’autre part de fournir un service capable de valider ces entités avec en plus un certain niveau d’information sur les cas non valides.
Article publié par Guillaume Arnaud le 23 février 2010.
Catégorie(s) : Java / JEE, SOA
Vous avez une application Java qui doit envoyer et recevoir des messages à droite et à gauche pour des raisons qui n’appartiennent qu’à vous… Votre premier réflexe sera sûrement de contacter votre vieil ami JMS. Pour ça, vous aurez aussi besoin d’un broker de message, mais vous n’êtes pas très riche et des outils comme WebSphere ou Tibco sont hors de portée… Vous aurez alors de fortes chances de vous tourner vers votre autre vieil ami ActiveMQ. Bon d’accord, l’amitié ça compte, mais par ailleurs d’autres amis (des vrais !) vous signalent qu’ils ont eu quelques problèmes de blocage de file avec ActiveMQ et qu’ils ont eu du mal à identifier ces problèmes. En plus vous avez encore d’autres amis qui aimeraient bien communiquer avec vous sur ce même broker mais leurs applications tournent en ruby et C++ qui parlent mal le JMS… C’est le moment idéal de vous présenter un nouvel ami : AMQP !
AMQP (Advanced Message Queuing Protocol) est un protocole de messagerie créé à l’initiative de la banque JP Morgan Chase pour gérer la communication entre ses différents partenaires. Le but affiché était de fournir une solution alternative aux solutions payantes et relativement chères dans le domaine du MOM (Message-Oriented Middleware) dominé largement par Websphere MQ d’IBM et RendezVous de Tibco (93% du marché à eux deux en 2008). Un certain nombre de partenaires se sont fédérés autour de ce projet pour aboutir à une première spécification en 2006. L’ambition avouée est qu’elle devienne l’équivalent du HTTP pour l’internet, ce qui explique qu’elle décrive aussi bien les différentes sémantiques liées au MOM que la partie plus bas niveau du transport de ces messages. Cette normalisation permet la multiplication des solutions clientes ou serveurs dont la compatibilité sera garantie par cette spécification. Par exemple, un broker de message écrit en Erlang comme RabbitMQ transférera de façon transparente un message d’un client ruby vers un autre client Java/JMS.
Notez bien qu’AMQP s’identifie clairement comme un protocole et non comme une API, contrairement à JMS. Donc un client Java basé sur JMS peut, moyennant des adaptations plus ou moins coûteuses, communiquer avec un broker AMQP.
Complet
Twitter
