 Poste réalisé par Mohamed Karim LILI (Ingénieur logiciel confirmé à OXIA) |
Dans Camel, il y a deux abstractions pour modéliser les messages :
|
Message
Les messages «(Message) sont des entités utilisées par les
systèmes pour communiquer entre eux en utilisant des chaînes de communications
(Messaging channels). Les messages transitent suivant une direction : à
partir d’une source vers une destination (receiver) :
L’entité « Message » possède un Body (qui contient
les données payload), un header et une partie « Attachements », ceci
est illustré dans la figure suivante :
Les messages possèdent un identifiant unique avec un
identifiant de type java.lang.String
généré par le protocole utilisé et n’a pas de format garanti. Pour les
protocoles n’ayant pas de système d’identification unique, Camel utilise son
propre générateur UID.
Le « Header » content des valeurs associées au
message, comme l’identifiant de l’émetteur (sender), des données sur
l’encodage, les informations d’authentification, etc. Les Headers sont des
entités clé-valeur, la clé est unique et est un String sensible à la casse, et
la valeur est de type java.lang.Object, les
headers sont stockés dans une Map au sein du message.
Un message peut aussi contenir des « Attachments »
qui sont typiquement utilisés pour les web services et les composants email.
Le Body est de type java.lang.Object,
ce qui voudrait dire que le message peut sauvegarder n’importe quel type de
données. Lorsque la source et le récepteur utilisent des formats de données
différents, Camel offre un large choix de mécanismes pour transformer les
données dans un format acceptable, qui dans la plupart des cas est
converti en coulisses par Camel en utilisant
ses propres converters Embedded.
Exchange
L’Exchange est le conteneur Camel du message durant le
routage. C’est un support pour les différents types d’interaction entre les
systèmes, plus connu sous le nom de MEP (Message exchange Pattern). Les MEPs
sont utilisés pour différencier entre les « one-way »
et les « request-response »
styles de messages.
L’exchange Camel peut ainsi être :
·
InOnly : un « one-way » message (Event message), par
exemple : les messages JMS sont des messages « one way »
·
InOut : Ce sont des messages « request-response »,
par exemple, les messages http sont souvent des messages request reply dans
lesquels le client demande à trouver une page web, en attendant la réponse du
serveur.
Ci-dessous un schéma expliquant l’architecture d’un
Exchange :
Sommaire
- Introduction à Apache CAMEL (partie 1/6) : Problématique
- Introduction à Apache CAMEL (partie 2/6) : Qu’est ce que « Apache Camel » ?
- Introduction à Apache CAMEL (partie 3/6) : Comment fonctionne Camel ?
- Introduction à Apache CAMEL (partie 4/6): Le modèle message de Camel (Camel Message model)
- Introduction à Apache CAMEL (partie 5/6) : Le DSL Camel (Domain Specific Language)
- Introduction à Apache CAMEL (partie 6/6) : tutorial CAMEL
Bibliographie, Netographie et lien utiles
Camel in Action, Clause Ibsen et Jonathan Anstey, Editions MANNING
Articles
0 commentaires :
Enregistrer un commentaire