世界人の blog

En cherchant à mettre en oeuvre Camel, je me suis heurté à une petite difficulté.

Dans mon contexte, je ne connais pas lors de la phase de développement les routes exactes qu’il me faudra mettre en place.

Or dans la documentation Camel et dans les nombreux exemples, les routes sont décrites sous forme de fichier xml Spring.

<camelContext id="camel"
    xmlns="http://camel.apache.org/schema/spring"">
   <route>
      <from uri="seda:a" />
      <to uri="seda:b" />
   </route>
</camelContext>

Heureusement pour moi Camel utilise aussi un DSL Java et il m’a rendu beaucoup de service. Ainsi mes composants au démarrage peuvent interroger l’environnement et déterminer dynamiquement les routes à construire.
Mais voilà que pour intégrer facilement ces composants dans le système c’est encore Spring qui est utilisé.
Ma question était alors : comment utiliser spring avec un RouteBuilder écrit en Java ?
La réponse était extrêmement simple, mais aussi difficile à trouver. Je n’ai pas trouvé de documentation sur ce point précise. Et j’ai envisagé bien des solutions.

La plus radicale étant de ne pas définir de Camel Context dans spring mais un bean qui lui-même fait tout le travail en java. Exactement comme si je le faisais sans spring.
L’intérêt de spring devient alors plus que marginal.

Voici donc que mettre dans spring.xml pour utiliser un RouteBuilder

<camelContext id="camel"
    xmlns="http://camel.apache.org/schema/spring">
   <package>org.mydomain.smx</package>
</camelContext>

reste à définir une classe myRouteBuilder.java dans le package.

package org.mydomain.smx;
import org.apache.camel.builder.RouteBuilder;

/**
*  A Camel RouteBuilder
*/
public class MyRouteBuilder extends RouteBuilder  {
   public void configure() {
      from("seda:a")
      .to("seda:b");
   }
}

C’est tout.
A+JYT

Dans l’article précédent (Urbanisme territorial), je terminais en disant que chaque application de la communauté doit pouvoir communier avec ses partenaires. Je vais ici aborder les différentes formes de communication inter-application.

Batch

Le premier mode d’échange que nous allons voir et probablement le plus ancien est l’échange par fichier de données. Le traitement par lot (Batch processing en englais) définit un fonctionnement simple. Pour communiquer, une application produit un fichier de données. L’application partenaire lit le fichier pour le traiter.
Ce mode de fonctionnement autorise de forts volumes de données. En effet, les seules limites sont le temps et l’espace. Pour l’espace, cela semble évident. On ne peut mettre sur un disque une bande ou tout autre support plus d’information qu’il ne peut en contenir. La limite temporelle est moins évidente. Elle vient du fait que les deux applications ont besoin de ces informations pour travailler. Et ce besoin est borné dans le temps. On ne peut donc échanger plus d’information que ce qu’on peut produire et lire dans le laps de temps imparti.

Ce mode d’échange, bien que très simple à de très nombreux avantages.

• Le premier est le fort volume de données, que l’on peut échanger. Avec les avancées technologiques, l’espace est toujours plus grand et on lit ou produit toujours plus dans le même laps de temps. Loin de rendre ce procédé obsolète, la technologie le met sur le devant de la scène.
• C’est un procédé robuste. Si la production de donnée échoue, on peut recommencer. Si la lecture échoue, on a toujours le fichier pour recommencer ou rattraper l’erreur. Cela demande quelques précautions.
• C’est un procédé éprouvé. Il existe depuis longtemps et on sait le maitriser.
• Il permet la communication entre technologies différente. La seule contrainte alors étant de se mettre d’accord sur la nature du fichier échangé.
• Enfin il permet l’échange d’information point à point (une application communique avec une seule), point à multipoint (une application communique avec plusieurs), et l’agrégation (plusieurs applications communiquent avec une ou plusieurs).

Parmi les inconvénients:

• On peut citer l’obligation pour les diverses parties de connaitre le format d’échange. Il est nécessaire d’avoir cette connaissance en commun.
• L’information dans l’application qui reçoit n’est disponible qu’après un laps de temps important. Il ne peut y avoir de temps réel, ou quelque chose d’avoisinant.
• S’il y a agrégation, c’est à l’application, lectrice, d’en assurer le traitement.

Remoting

L’appel direct (remoting en anglais) est lui aussi un procédé relativement simple. Pour communiquer une application ouvre un canal de communication direct vers son homologue. Libres à elles alors d’échanger les données qu’elles veulent. Pour être mise en place, cette solution nécessite des prérequis.

Les machines physiques qui hébergent les applications doivent avoir une visibilité commune sur le réseau. Lorsqu’une application met la communication en oeuvre, l’application partenaire doit être active et prête à recevoir la communication. Les deux applications souvent rester actives durant tout l’échange.

Cela peut sembler beaucoup, mais ces conditions ne sont pas rares.

Les avantages sont nombreux. On compte parmi eux :

• La possibilité de communication temps réel.
• La possibilité de mode question/réponse
• L’acquittement
• La rapidité.

Parmi les inconvénients on trouve :

• Le mode synchrone qui peut être une gêne.
• La nécessité de faire de petits échanges. (les gros échanges pénalisent les deux applications).
• Les deux applications doivent connaitre la technologie de l’autre.
• La nature des données échangées doit être une connaissance commune.
• La communication est toujours point à point.

Webservices

Les webservices sont une évolution naturelle dans le contexte internet du remoting. Le point de départ vient du besoin d’utiliser les canaux internet pour faire du remoting. Rapidement, cela s’est avéré insuffisant.S’y sont adjoint une abstraction du message, ainsi que de son transport. Cela a permis de définir l’échange en rendant les deux parties relativement indépendantes. Le principe s’apparente à un service postal. L’émetteur met son message dans une enveloppe et le remet à un transporter. Je n’entrerais pas ici dans les protocoles, car c’est plus le principe qui est intéressant que les différentes mises en oeuvre.

Pour les avantages et les inconvénients, on peut reprendre ceux du remoting, avec les changements suivants :

• Les applications n’ont pas à avoir en commun des structures de données communes ni des technologies communes.
• Suivant la technologie retenue la communication peut être synchrone ou asynchrone.
• la communication peut être multipoint à point (n vers 1).

Messaging

La communication par message est elle aussi née de certaines limites du remoting. Elle introduit un courtier (broker en anglais) entre les applications qui communiquent. Son rôle étant d’acheminer le message. Le but étant de permettre une communication instantanée comme dans le remoting sans avoir les contraintes de synchronicité qui lui sont associées. Le courtier étant un agent actif du système il permet au passage de faire de la communication multipoint (n vers m). Enfin il offre des garanties d’acheminements.

Il garde les avantages et les inconvénients du remoting hors mis :

• La synchronicité. Les communications peuvent être asynchrones. Les applications peuvent être arrêtées ou démarrées indépendamment.
• La communication multipoint. Plusieurs applications peuvent communiquer entre elles (n vers m).
• Le broker devient un noeud sensible du système.

Bonjour.

Avant de rentrer dans le vif du sujet je vais essayer de planter le contexte. Le projet consiste donc à fédérer un ensemble de systèmes d’information. Il s’agit des systèmes d’information d’établissement jouissant d’une autonomie importante. Le directeur de l’établissement est maître de ces choix et de son budget. Le DSI de chacun d’entre eux est seul en charge de son Système. La convergence se fait par la volonté commune de convergence. La politique de décision nous importe peu. Le point qui nous intéresse est que lorsqu’une décision de convergence est prise l’ensemble des acteurs s’engage (même s’il est contre) à la mettre en oeuvre.

Dans ce cadre, il semble évident qu’il n’est pas question de remplacer les différents systèmes d’information par un système central partagé. Techniquement parlant vu que chacun reste maître à bord chez lui, il peut être tentant de cloisonner les différents systèmes. Et de définir pour chacun d’entre eux un point de visibilité.

Vu que nous parlons ici d’urbanisme, je vais faire quelques analogies.

Lorsqu’on parle d’urbanisme, on pense aussitôt à la notion de ville. Dans notre contexte, on peut considérer que chaque établissement est une ville et qu’il possède son plan d’urbanisme. C’est effectivement ainsi que cela se présente. La problématique qui nous intéresse est tout autre. Nous n’avons pas à faire à l’organisation d’une ville, mais d’un territoire bien plus vaste qui inclut un grand nombre de cités.

Que serait cette notion de point de visibilité dans l’aménagement d’un territoire ?

Nous en avons un exemple partiel avec le tunnel sous la manche. Deux territoires définissent un terminal au bout du tunnel. Que ce soit des transports de personnes, de marchandise, de courriers, etc., les deux territoires mettent en place l’infrastructure jusqu’au terminal et le tout est transporté dans le tunnel selon le même protocole. Les terminaux du tunnel sous la manche définissent de fait ce qui peut passer ou pas d’un territoire à l’autre.

Dans le cadre qui nous intéresse, cela revient à exposer sur ce point de présence les services que propose le système d’information à l’extérieur, ainsi qu’une image (un proxy) des services extérieurs que le système utilise.

Cette approche est séduisante. Car elle préserve le cloisonnement des systèmes. Mais elle a aussi ses inconvénients. Sa mise en oeuvre demande un travail important et l’évolution n’est pas très évidente. Une application A du système 1 communique avec l’application B du système 2. Pour cela, l’application A doit mettre en oeuvre un canal de communication avec le point de présence du système 1 pour cet échange. Les points de présence doivent être capables d’assurer cet échange. L’application B doit mettre en place un canal avec le point de présence du système 2. Le nombre d’acteurs est donc important. Autre inconvénient dans ce cas, il est impossible d’avoir une application centrale commune à tous. Chacun étant cloisonné dans son Système.

Je ne débattrais pas plus avant de cette approche dont les tenants et les aboutissants sont nombreux. Je dirais simplement que ce n’est pas ce qui a été retenu dans notre projet. Je l’ai évoqué, car il me semble important dans la recherche de notre solution de connaître diverses approches même si nous ne les avons pas retenus.

Nous avons donc écarté la centralisation complète, ainsi que le cloisonnement total. Il ne nous reste que l’ouverture.

Pour reprendre l’analogie territoriale, nous avons à faire ici à une communauté d’agglomérations. Chacune a son propre plan d’urbanisme, toutes participent aux décisions de convergence. Cela implique la mise en place de plan commun de communication comme un réseau de transport en commun unique ou plusieurs réseaux concertés. Ou encore la mise en place d’infrastructure commune. Chaque service d’une ville communique avec ses partenaires de la communauté d’agglomération. Certains de ces partenaires sont des services centraux, d’autres des services locaux de la même ville, d’autres encore des services locaux d’une autre agglomération de la communauté.

En terme d’urbanisme de système d’information, c’est l’approche qui a été retenue pour notre projet. Les applications d’un système d’information de la fédération doivent pouvoir communiquer avec n’importe quel partenaire de la communauté.

A+JYT