Mule Summit Automne 2013

Bonjour,

FastConnect et MuleSoft ont le plaisir de vous inviter ainsi que les membres de votre équipe, au Mule Summit, évènement annuel clé dans le domaine de l’intégration, qui aura lieu à Paris le 16 Octobre 2013.

Cet évènement va réunir les clients de MuleSoft, la communauté et les équipes techniques ainsi que les dirigeants de MuleSoft pour une journée d’échange autour de l’offre MuleSoft, à travers des présentations sur les nouveaux produits, les roadmaps et des tables rondes.

Cette journée vous permettra de :

  • Découvrir comment mieux vous préparer pour le New Enterprise
  • Apprendre les meilleures techniques d’intégration des utilisateurs expert en Mule et des architectes expérimentés
  • Avoir une visibilité sur la roadmap de MuleSoft et influencer l’orientation du produit
  • Rencontrer les experts MuleSoft et de l’industrie, y compris le fondateur de MuleSoft, Ross Mason

Je vous invite à consulter le site internet de notre partenaire MuleSoft pour plus d’information et le programme de cette journée :
http://mulesummitparis.eventbrite.com

Voici les détails pratiques à retenir :
Mule Summit Paris
Date: 16 Octobre 2012
Horaires: 8h30 – 18h30
Lieu: Les Salons de l’Aéroclub de France, 6 rue Galilée, 75016 Paris (métro Boissière – ligne 6)

Si d’autres collaborateurs souhaitent participer à cet évènement, n’hésitez pas à nous envoyer leurs noms et coordonnées le plus tôt possible, pour un enregistrement sans frais.

Cordialement,

L’équipe Mule
contact@fastconnect.fr

Les nouveautés de Mule 3

Mule 3 apporte un nombre important de nouveautés par rapport a mule 2.
Parmi celles-ci on retrouve principalement :

  • l’ajout de la notion de flow
  • l’ajout de Mule Studio avec un environnement de developpement graphique
  • l’ajout d’un data mapper graphique

Flow

Un « Flow » est un mecanisme simple et flexible qui permet d’orchestrer des services en utilisant les capacités sophistiquées de Mule ESB.

Un Flow est composé d’un « Message Source » et d’un enchaînement de « Message Processor ». Par rapport à l’utilisation des « Services », qui définissent explicitement les phases d’inbound et d’outbound d’un composant, ce qui limite la flexibilité, les « Flows » ne définissent rien explicitement. On peut configurer dans un même « Flow » les différentes étapes nécessaire à la résolution de la problématique et ainsi éviter d’agréger des services ensemble à l’aide des « vm transport » ou des « chaining router ».
flow_mule

Mule Studio

http://www.mulesoft.com/sites/all/themes/mulesource/images/products/xml-mule-flows.png

Mule Studio est un environnement de développement intégré basé sur Eclipse. Il permet de développer, débugger et déployer des applications Mule ESB. Il laisse le choix au développeur d’utiliser l’environnement graphique ou d’éditer les fichier xml à la main.

L’environnement graphique permet au développeur de disposer des blocs afin de créer des Mule Flows qui sont à la base des applications Mule. D’un simple drag and drop, il est possible de créer une séquence d’événement pour traiter les messages. Chaque bloc peut être configurer à l’aide d’une boite de dialogue grâce à des champs d’options.

http://blogs.mulesoft.org/wp-content/uploads/2011/03/mule-studio.png

Toutefois il reste possible d’éditer les fichiers de configuration xml à la main. Les développeurs peuvent facilement changer de mode d’édition car Mule Studio synchronise les relations et les paramètres des différents composants.
Mule Studio améliore l’éditeur xml en y apportant l’auto-complétion intelligente (listes des composants, listes des options pour un composant, …) grâce à une liste déroulante qui se met à jour en temps réel en fonction du contexte.

http://blogs.mulesoft.org/wp-content/uploads/2011/06/Screen-shot-2011-06-27-at-3.07.12-PM.png

Data Mapper

http://www.mulesoft.com/sites/all/themes/mulesource/images/products/data-mapping-capabilities.png

Mule Data Mapper est entièrement intégrer à Mule Studio

  • Transformation visuelle des données
  • Génération des meta-données à partir de schémas ou d’un échantillon de données
  • Les formats de données supportés sont XML, JSON, CSV, POJOs, and Excel
  • Des transformation plus complexes peuvent être appliquées en utilisant des règles, des recherches et des capacités d’édition plus avancée.

Bonus

La vidéo de présentation de Mule 3:

Mule Data Integrator – The DADS-U Transformation

My colleague (Luc Boutier) and myself worked end of last year on a POC around Mule Data Integrator (MDI).

MDI is a graphical tool to ease data transformation which is proposed by MuleSoft. It support out of the box several descriptive format to easily import the data structure.

This paper is about the mapping of a french data structure called DADS-U. It’s used by government to collect company’s informations (company structure, employees informations, etc…) for french retirement system.
The greatest difficulty we encountered was to map this structure which uses a proprietary format composed by <key,value> pairs and does not match default formats implemented by MDI (like CSV etc…).

BEGIN FILE
	S10.G01.00.001.001,'732829320'
	S10.G01.00.001.002,'00010'
	S10.G01.00.002,'Unknown'
	S10.G01.00.003.001,'Service du Personnel'
	S10.G01.00.003.002,' '
	S10.G01.00.003.003,'285'
	S10.G01.00.003.005,' '
	S10.G01.00.003.006,'Unknown'
	S10.G01.00.003.008,' '
	S10.G01.00.003.010,'75000'
	S10.G01.00.003.011,' '
	S10.G01.00.003.012,'PARIS'
	S10.G01.00.004,' '
	(...)
END FILE

And could correspond to this logical tree: for exemple « S10.G01.00.00X » could be a branch or a leaf.

BEGIN FILE
	S10
	|	`- S10.G01.00.001
	|	|		`- S10.G01.00.001.001 -> value
	|	|		`- S10.G01.00.001.002 -> value
	|	`- S10.G01.00.002 -> value
	|	`- (...)
	S20
	|	`- (...)
	S30
	|	`- (...)
	S90
	|	`- S90.G01.00.001 -> value
	|	`- S90.G01.00.002 -> value
END FILE

Because this file could have a more than 10MB size we had to create MDI structure semi-automatically using intermediate MDI structures & maps.

So this is the method to do:

  • Firstly you must import this file and create a new structure using MDI software and add several other element to recognize pairs line by line. You must have a MDI structure composed by:
    BEGIN MDI STRUCTURE
    	Line (0:*)
    	|	`- Element: Row (0:*)
    	|	|	`- Element: Key_part1
    	|	|	`- Element: Separator
    	|	|	`- Element: Key_part2
    	|	|	`- Element: Separator
    	|	|	`- Element: Key_part3
    	|	|	`- Element: Separator
    	|	|	`- Element: Key_part4
    	|	|	`- Element: Separator
    	|	|	`- Element: Key_part5
    	|	`- Element: Separator
    	|	`- Element: Value
    END MDI STRUCTURE

    Example for the first line:

    BEGIN MDI STRUCTURE
    	Line: 1
    	|	`- Element
    	|	|	`- Element: "S10"
    	|	|	`- Element: "."
    	|	|	`- Element: "G01"
    	|	|	`- Element: "."
    	|	|	`- Element: "00"
    	|	|	`- Element: "."
    	|	|	`- Element: "001"
    	|	|	`- Element: "."
    	|	|	`- Element: "001"
    	|	`- Element: ","
    	|	`- Element: "732829320"
    END MDI STRUCTURE
  • Secondly you must create a new structure like below and apply a « Drag and Drop » mapping via MDI to apply these calculation:
    BEGIN MDI STRUCTURE
    	Line (0:*)
    	|	`- Element: Row (0:*)
    	|	|	`- Element: Key
    	|	|	`- Element: Index -> Integer - range of the key
    	|	|	`- Element: Leaf -> boolean - if the line is a branch or a leaf
    	|	`- Element: Separator
    	|	`- Element: Value
    END MDI STRUCTURE

    Example for the first line:

    BEGIN MDI STRUCTURE
    	Line: 1
    	|	`- Element
    	|	|	`- Element: "S10.G01.00"
    	|	|	`- Element: 1
    	|	|	`- Element: false
    	|	`- Element
    	|	|	`- Element: "001"
    	|	|	`- Element: 2
    	|	|	`- Element: false
    	|	`- Element
    	|	|	`- Element: "001"
    	|	|	`- Element: 3
    	|	|	`- Element: true
    	|	`- Element: ","
    	|	`- Element: "732829320"
    END MDI STRUCTURE
  • Thirdly you must make a new mapping using « Drag and Drop » mode from the previous structure to a default MDI structure (« Builtin » default project -> « Structures/UpdateImporter »).
    • For optimal functioning, it’s important that the different loops beyond final structure have MDI « Sequences » type.
    • It will be composed of three loops (Dadsu, Line, Element) and each loop corresponds to the element « Element(0:*) » of the « UpdateImporter » structure.

Finally you have a DADS-U structure (of any size):

BEGIN MDI STRUCTURE
	Dadsu
	|	`- Lines
	|	|	`- S10.G01.00
	|	|	|	`- 001
	|	|	|	|	`- 001
	|	|	|	|	`- 002
	|	|	|	`- 002
	|	|	|	`- 003
	|	|	|	|	`- 001
	|	|	|	|	`- 002
	|	|	|	|	`- 003
	|	|	|	|	`- (...)
	|	(...)
END MDI STRUCTURE

The aim of this paper is not to describe how to use MDI, but rather to show an approach to adapt a proprietary format of MDI and avoid creating a structure by adding items one by one. Which can be time consuming if the structure you want to map is consistent.

Xavier

Apache Camel and ServiceMix who’s the ESB ?

I’ve been recently, with Jean-Michel BEA, to an event organized by FUSE/progress software (fusesource starting from the beginning of the week) which propose enterprise support around some apache technologies. We work in FastConnect on various ESB platform and ServiceMix is one of them.

In ServiceMix 3.x everything relied on the JBI specification. This has changed for good in ServiceMix 4. Indeed the JBI specification implies many constraint (internal format of messages must be XML, services have SOAP interfaces etc…). This creates constraints on both performance and usability in many situations.

On top of the JBI facilities to define services and connections, ServiceMix uses Apache Camel for routing. ServiceMix 3.x versions created constraints on the product learning curve as you had to know the JBI specifications/configurations, Apache Camel and understand how to configure all this into ServiceMix.

With ServiceMix 4 you can still use JBI and Camel for routing but the new point is that the preferred way to create a new ServiceMix 4 application will be to just use Camel. Configuration as pure Camel is easy and you get rid of the Xml format constraint solving your usability and performance issues (of course if your working with Xml and SOAP you can still do it).

The question we can point out is now:
– If JBI is recognized as a wrong standard and kind of a failure what is the point of ServiceMix now ?
Let me explain, if we use Camel configuration only, why should we use ServiceMix and not just Apache Camel ? Such a new way to define things point more Camel as the ESB and ServiceMix as the ESB « preferred container ». Well people told me that using the internal bus (NMR) is great to integrate with existing JBI (that’s for sure) and potentially with BPM (Apache Agila etc…) when BPM server/process is used in the same VM as ServiceMix.

So what I understood from all this and my vision of the overall tools
– If you have existing JBI and you want to move smoothly to a more Camel based application then yes ServiceMix4 makes sense.
– If you are starting your ESB adoption from scratch on top of Apache/FUSE technologies then I guess you can just use pure Camel. And then choose the container that suits your need in which you will deploy your ESB application.

Regarding ServiceMix 4 as a container it offers to you the following benefits:
– Integration with Camel has been tested and certified.
– Integration with Apache Agila if you want to use both of them embedded in the same VM is performant (thanks to ServiceMix NMR)

But it also get with the following constraint:
– ServiceMix 4 runtime is based on Apache Karaf, you will then benefits from all the great modularity and deployment features from OSGi… But well as any OSGi container it means that you have to use OSGi and to be honest this sounds more like a constraint to me.

I’ll be interested to get your feedbacks on this subject :)