Affichage des articles dont le libellé est BPM. Afficher tous les articles
Affichage des articles dont le libellé est BPM. Afficher tous les articles

mardi 22 juin 2010

Industrialisez vos applications avec LEONARDI

Pour ceux qui cherchent à industrialiser le développement des applications métiers, la solution de trouve chez W4 : c’est LEONARDI.

La solution a été intégrée aux outils proposés par W4 suite à l’acquisition de Lyria.

Rappelons que W4 est spécialisé dans l'automatisation de processus (BPM), et Lyria dans le développement rapide d'interfaces.

LEONARDI, permet de structurer les développements et réduire vos coûts avec :

  • · la solution pour développer des IHM multi-cibles ;

  • · la solution la plus rapide du marché pour développer vos applications métiers ;

  • · la solution pour automatiser le développement d’applications pour des projets d’envergure ;

  • · la solution pour moderniser vos applications sans être un expert de toutes les technologies.

Industrialisez vos applications métiers avec LEONARDI est le titre due Web séminaire LEONARDI de 45mn, annoncé pour 1er juillet à 11h00 (heure de Paris)

Pour s’inscrire le lien http://www.w4.eu/formulaire_leonardi_webseminaire.aspx

Pour les curieux : prenez un avant gout de la solution en étudiant le projet open source en relation avec LEONARDI sur  le site de http://www.lyria.com/

à suivre ….

mardi 18 mai 2010

Alfresco présente Activiti BPMN 2 : 1er moteur BPMN 2.0 open source sous licence Apache

En avril, dernier, lorsqu’on a parlé, dans ce blog, du départ de deux membres importants quittent l’équipe JBPM, nous avons annoncé que Tom Baeyens et Joram Barrez promettent, sur le blog de Joram Barrez, le lancement imminent d’un nouveau Moteur BPM basé sur la norme BPMN 2.0 sous la licence apache.

Une partie de l’annonce était « We’re building a new BPM platform that’s architected for new IT requirements. It will be Apache licensed and it will run BPMN 2.0 natively ! »

C’est annoncé !!,

C’est sous les couleurs de Alfresco, le Leader de l’ECM open source, que les deux “mousquetaires du BPM” proposent ce nouveau moteur, nommé Activiti.

Activiti va rendre le Business Process Management (BPM) une commodité.

il a au moins la particularité d’être le 1er moteur BPM (et en plus BPMN 2.0) open source sous licence Apache.

Activiti un moteur BPM

La première version alpha d’Activiti intègre les fonctionnalités suivantes :

- Activiti Engine – Fichier JAR contenant la machine virtuelle de processus et l’implémentation du langage de processus BPMN ;

- Activiti Probe – Console d’administration système permettant de commander le moteur Activiti ;

- Activiti Explorer – Application utilisateur permettant de gérer facilement les listes de tâches et d’exécuter les tâches de processus ;

- Activiti Modeler – Outil de modélisation des processus BPMN 2.0 via un navigateur, basé sur Ajax, destiné aux analystes métier.

Selon Tom Baeyens, « Activiti va véritablement bouleverser le paysage BPM », explique Tom Baeyens. « Avec sa licence Apache et sa richesse fonctionnelle,

A l’instar de l’approche de Micorsoft avec WPF 4.0 chez les développeurs .Net, l’équipe d’Activiti, va essayer de déclencher une large adoption de la technologie BPM chez les développeurs Java.

Activiti est ainsi à même de s’imposer comme l’implémentation standard du BPM et du BPMN.

Remarquons l’utilisation du moteur de modélisation web SIGNAVIO, pour la modélisation.

clip_image002

Il est prévisible que ce moteur de BPM, Activiti deviendra le moteur de gestion des processus métier par défaut d’Alfresco.

bravo pour cette initiative, à la sauce Apache, une licence business frendly …

étape suivante : tester et mettre à l’épreuve…

site web

http://www.activiti.org/

jeudi 13 mai 2010

JBPM 5 : une version majeure en préparation

L’équipe BPM de JBoss (RedHat) a annoncé le lancement du projet JBPM 5 : la prochaine génération de plateforme BPM.

La principale information, est que jBPM 5 sera basé sur l'expérience combinée de jBPM et de Drools Flow (ainsi que les projets en relation : RiftSaw et Overlord).

Un effort de capitaliser sur les avantages des deux solutions sera la principale direction du projet, si on considère que la compatibilité totale avec BPMN 2 est déjà acquise.

Aucune feuille de route n’a été présentée pour le moment.

mardi 13 avril 2010

JBPM 4 et BPMN 2.0: deux membres importants quittent l’équipe

Tom Baeyens (chef de projet JBPM chez RedHat) et Joram Barrez (développeur Leader JBPM chez RedHat) ont quitté le projet JBPM. Rappelons que Tom a rejoint JBoss en 2004. Joram a apporté son expertise dans des domaines comme la performance, l'intégration et le respect des normes.

Tom Baeyens et Joram Barrez annoncent, sur le blog de Joram Barrez, le lancement imminent d’un nouveau Moteur BPM basé sur la norme BPMN 2.0 sous la licence apache. Une partie de l’annonce « We’re building a new BPM platform that’s architected for new IT requirements. It will be Apache licensed and it will run BPMN 2.0 natively ! »

Peut on interpréter cela comme la poids de RedHat, qui ralentit le projet, d’un point de vue des « entrepreneurs de JBPM», et que la prochaine version de JBPM ne sera pas nativement BPMN 2.0 ?

Dans tous les cas, c’est une tendance de fond, les principaux projets open sources sont ou seront contrôlés par des entreprises qui fixeront les feuilles de routes (avec ou sans la communauté).

Espérons que cette nouvelle disposition de l’équipe JBPM, ne ralentisse pas le virage de JBPM 4 vers la norme BPMN 2.0, et notamment dans le volet outillage et monitoring.

Source : http://www.jorambarrez.be/blog/2010/03/29/alive-and-kicking/

----

Open source : le modèle du logiciel libre serait-il menacé par les grands fournisseurs de software

jeudi 14 janvier 2010

BPMN 2.0 & JBPM : la version 4.3 de JBPM est compatible BPMN 2.0

La démocratisation de BPMN (Business Process Modeling Notation) est en marche. Avant même la sortie officielle des spécifications de la version 2.0 de BPMN, la communauté open source innove. C’est l’information qui filtre du lancement de la nouvelle version 4.3 de JBPM, une partie de la spécification BPMN 2.0 est déjà implémentée.

architecture soa, service oriented architecture, java software, open source, eclipse,alm, j2ee, java ,bpm

L’équipe de JBOSS devance les autres et pense que l’année 2010 sera l’année de la consécration du langage de notation des processus métiers BPMN 2.0.

Cette initiative montre que lorsque les standards sont ouverts, la communauté open source peut prendre le leadership.

D’autres nouveautés de la version 4.3 de jBPM :

- Une meilleure intégration avec Spring

- Ajout de l’activité de type JMS

- Une meilleur intégration avec le moteur de règles métiers de Jboss : le fameux Drools.

- Ajout de la fonction count() pour toutes les requêtes dans l’API ProcessInstanceQuery (Interface dans le apckage org.jbpm.api ) de JBPM

o long count() : execute a count(*) query and returns number of results

-

Pour plus d’information sur JBPM : visiter l’excellent site http://www.jorambarrez.be et notamment

http://www.jorambarrez.be/blog/2009/12/04/jbpm-goes-bpmn/

jeudi 15 octobre 2009

Tutorial Mule ESB : pas à pas

Cet article présente une série de présentations et de tutoriels pour démystifier Mule ESB : http://net-progress.blogspot.com/)

1 les projets d’intégration avec ESB.

1.1 de la nécessité d’un projet d’intégration dans un S.I. (Système d’information).

1.2 Les types d’intégration.

1.3 Intégration par les données :.

1.4 Intégration par les API :.

1.5 Intégration par les processus.

1.6 Un ESB est service de l’intégration.

2 Mule ESB 2.x est il un ESB.

2.1 Ce qu’est un ESB.

2.2 Rôle d’un ESB.

2.3 Mule ESB est il un ESB.

2.4 La concurrence open source.

2.5 Autres usages possible pour Mule.

3 Tutorial Mule ESB : une introduction.

3.1 C’est quoi Mule.

3.2 qu’est ce qu’un service Mule.

3.3 Séparer la logique métier de la logique de routage.

4 Tutorial Mule ESB : les principales composantes.

4.1 Présentation.

4.2 Installer Mule et son IDE.

4.2.1 Installer Mule.

4.3 Installer l’IDE de Mule.

5 Tutorial Mule ESB : Créer un projet d’intégration avec Mule en utilisant l’IDE Eclipse.

5.1 Créer un projet Mule.

5.2 Créer une configuration Mule.

5.3 Lancer l’exécution du projet à partir d’Eclipse.

5.4 Sélectionner la configuration Mule.

6 Tutorial Mule ESB & Eclipse : déployer un projet d’intégration avec Eclipse.

6.1 Déployer le projet à partir d’Eclipse.

6.2 Exécuter le projet.

7 Tutorial Mule ESB : Une application simple, Echo sans altération de message.

7.1 Introduction.

7.2 Présentation générale du fichier de configuration de Mule.

7.3 Construction pas à pas d’un exemple simple :

8 Tutorial Mule ESB : Une seconde application simple, Echo avec modification du message

9 Tutorial Mule ESB & Spring Ioc: Utilisation des beans Spring avec Mule.

10 Tutorial Mule ESB : illustration des capacités de Mule.

10.1 Description :.

10.2 Le sujet :

10.3 Pour commencer :

10.4 Configuration de Mule.

10.5 Définir les transformateurs.

10.6 Définir le modèle.

10.7 Définir un service.

10.8 Définir les entrées du service.

10.9 Définir le composant du service.

10.10 Définir la sortie du composant.

10.11 Finaliser le projet.

10.12 Exécuter le projet.

10.13 Retour sur les transformations.

lundi 12 octobre 2009

Tutorial Mule ESB : illustration des capacités de Mule

NB : cet article fait partie d’une série de présentation et de tutorials pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Dans l’exemple présenté dans cette partie, nous allons explorer les capacités d’un ESB : Protocol de transport, transformation et gestion des exceptions

Description :

L’exemple a pour objectif de répondre à une demande de résultat dans un examen pour un étudiant donnée. Les aspects suivants seront traités

1. Réception de l’invocation par deux méthodes (VM et http)

2. Développement et Utilisation de transformateurs spéciaux

3. Utilisation d’une stratégie de gestion des exceptions

4. Réponse synchrone par http et affichage directe dans la page web

Le sujet :

Il s’agit d’un service en ligne de suivi des résultats des examens nationaux.

Un utilisateur pourra trouver les résultats de ses examens à travers une interface web dans son portail favoris.

Ce portail communique avec le serveur de l’université via un protocole de son choix : Mule est capable de varier le protocole d’exposition d’un service indépendamment de son implémentation

Pour commencer :

Créer un projet Mule vide et définir le fichier de configuration : resultat-examen-http-config.xml

Les Pojo en relation avec le projet sont :

Etudiant (sous sa forme la plus simple, pour les besoins du tutorial)

1:  package com.oxia.att.mule.intro.beans;
2: import java.io.Serializable;
3: public class Etudiant implements Serializable {
4: private static final long serialVersionUID = 7010138636008560022L;
5: private String nom;
6: private String universite;
7: // getter & setter …
8: public boolean isValid() {
9: if (nom == null)
10: return false;
11: // accépter seulement si le nom a plus de 2 caractère
12: if (nom.length() > 1)
13: return true;
14: return false;
15: }
16: }

ResultatExamen : objet contenant le résultat de l’étudiant (sous sa forme la plus simple, pour les besoins du tutorial)




1:  package com.oxia.att.mule.intro.beans;
2: import java.io.Serializable;
3: public class ResultatExamen implements Serializable {
4: private static final long serialVersionUID = -3140370545357738491L;
5: private StringBuffer resultat = new StringBuffer();
6: public StringBuffer append(String str) {
7: return resultat.append(str);
8: }
9: public StringBuffer append(StringBuffer sb) {
10: return resultat.append(sb);
11: }
12: public String toString() {
13: return resultat.toString();
14: }
15: }

Le projet se présente sous cette forme :




clip_image001




Configuration de Mule


Le prologue :


1:  <?xml version="1.0" encoding="UTF-8"?>

Fixer les namspaces à utiliser




1:  <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
2: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:spring="http://www.springframework.org/schema/beans"
3: xmlns:http="http://www.mulesource.org/schema/mule/http/2.2" xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
4: xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
5: xsi:schemaLocation="
6: http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
7: http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
8: http://www.mulesource.org/schema/mule/http/2.2 http://www.mulesource.org/schema/mule/http/2.2/mule-http.xsd
9: http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
10: http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">




Définir les transformateurs



Définir les transformateurs à utiliser




1: <custom-transformer name="StringToEtudiant"
2: class="com.oxia.att.mule.intro.transofrmer.StringToEtudiant" />
3: <custom-transformer name="EtudiantToResultatExamen"
4: class="com.oxia.att.mule.intro.transofrmer.EtudiantToResultatExamen" />
5: <custom-transformer name="ResultatExamenToString"
6: class="com.oxia.att.mule.intro.transofrmer.ResultatExamenToString"/>
7: <custom-transformer name="HttpRequestToEtudiant"
8: class="com.oxia.att.mule.intro.transofrmer.HttpRequestToEtudiant" />
9: <custom-transformer name="ExceptionToString"
10: class="com.oxia.att.mule.intro.transofrmer.ExceptionToString" />
11: <custom-transformer name="HttpRequestToParameter"
12: class="org.mule.transport.servlet.transformers.HttpRequestToParameter" />
13: <custom-transformer name="ObjectToString"
14: class="org.mule.transformer.simple.ObjectToString" />



Donnons ici un exemple de transformateur qui reste, rappelons le, un code spécifique à Mule.




Exemple de code source d’un transformateur spécifique développe dans le cadre de ce tutorial




1:  package com.oxia.att.mule.intro.transofrmer;
2: import org.mule.api.transformer.TransformerException;
3: import org.mule.transformer.AbstractTransformer;
4: import com.oxia.att.mule.intro.beans.ResultatExamen;
5: import com.oxia.att.mule.intro.beans.Etudiant;
6: public class EtudiantToResultatExamen extends AbstractTransformer {
7: public EtudiantToResultatExamen() {
8: super();
9: this.registerSourceType(Etudiant.class);
10: this.setReturnClass(ResultatExamen.class);
11: }
12: public Object doTransform(Object src, String encoding)
13: throws TransformerException {
14: ResultatExamen resultatExamen = new ResultatExamen();
15: Etudiant etudiant = (Etudiant) src;
16: resultatExamen.append("Le candidat : ");
17: resultatExamen.append(etudiant.getNom());
18: resultatExamen.append(" de L'universite : ");
19: resultatExamen.append(etudiant.getUniversite());
20: return resultatExamen;
21: }
22: }

Une classe de Transformation


· hérite de la classe AbstractTransformer


· et implémente la méthode doTransform(…).

Cette classe a accès au Payload du message et suppose qu’il est de type Etudiant




Il est préférable de rester indépendant du protocole de transport afin de réutiliser les transformations dans d’autres situations :




1:  Etudiant etudiant = (Etudiant) src;



Définir le modèle



1:  <model name="ResultatExamenSample">
2: La définition des services
3: </model>


Définir un service



Rappelons, que dans un service il ya 4 parties




























<component />



Le composant



<outbound>



</outbound>



Le point de sortie



<default-service-exception-strategy>



</default-service-exception-strategy>



La gestion des exceptions



</service>





Définir les entrées du service



Dans le premier service nommé DonneesEtudiant, nous allons avoir deux points d’entrée :




· Un point d’entrée http


· Un point d’entrée vm

1:  <inbound>
2: <inbound-endpoint address="http://localhost:8888"
3: transformer-refs="HttpRequestToEtudiant" synchronous="true">
4: </inbound-endpoint>
5: <vm:inbound-endpoint path="etudiant"
6: transformer-refs="StringToEtudiant" synchronous="true" />
7: </inbound>


Pour appeler le service avec HTTP, lancer cette URL dans un navigateur



http://localhost:8888?nom=Khalil




pour faire appel à ce service avec la programmation, utiliser la classe MuleClient:



MuleClient client = new MuleClient();



client.send("vm://etudiant", "Khalil", null);




UMOMessage response = client.send("vm://etudiant", "Ross", null);


System.out.println("response = " + response.getPayload());

Définir le composant du service


Utilisons ici un appel direct à la classe de service (un Simple POJO)

1: <component class="com.oxia.att.mule.intro.service.VerifierCandidat" />


Définir la sortie du composant


Nous illustrons dans cette partie l’usage des filtres :

Les Filtres permettent de préciser les conditions qui doivent être remplies pour un message afin qu’il soit acheminé à un service. Il existe plusieurs types de filtres offerts par Mule que vous pouvez utiliser. Il est possible de créer vos propres filtres.




Nous utilisons ici un routeur spécial : le <filtering-router> : qui présente l’avantage de filtrer selon le contenu et dispatché vers le point de sortie approprié.



· Si le résultat est de type Etudiant alors tout va bien



· Si c’est une exception (ici de type com.oxia.att.mule.intro.exception.CandidatException) alors on passe en mode erreur



1:<outbound>
2:<filtering-router>
3: <vm:outbound-endpoint path="getResultatExamen" synchronous="true" />
4: <payload-type-filter
5: expectedType="com.oxia.att.mule.intro.beans.Etudiant" />
6:</filtering-router>
7:<filtering-router>
8: <vm:outbound-endpoint path="userErrorHandler" synchronous="true" />
9: <payload-type-filter
10: expectedType="com.oxia.att.mule.intro.exception.CandidatException" />
11: </filtering-router>
12:</outbound>


Et



1:  default-service-exception-strategy>
2: <vm:outbound-endpoint path="systemErrorHandler" />
3: </default-service-exception-strategy>


Finaliser le projet



Pour finaliser le projet, il reste à indiquer les destinations getResultatExamen, userErrorHandler et systemErrorHandler



Pour cela une solution est définir des nouveaux services :



1:  <service name="ResultatExamen">
2: <inbound>
3: <vm:inbound-endpoint path="getResultatExamen"
4: transformer-refs="EtudiantToResultatExamen"
5: responseTransformer-refs="ResultatExamenToString"
6: synchronous="true" />
7: </inbound>
8: <component
9: class="com.oxia.att.mule.intro.service.ObtenirResultatExamen" />
10: </service>
11: <service name="UserErrorHandler">
12: <inbound>
13: <vm:inbound-endpoint path="userErrorHandler"
14: responseTransformer-refs="ExceptionToString" synchronous="true"/>
15: </inbound>
16: </service>


Dans ce dernier service, nous utilisons le fameux routeur <pass-through-router>




1:  <service name="SystemErrorHandler">
2: <inbound>
3: <vm:inbound-endpoint path="systemErrorHandler" synchronous="true" />
4: </inbound>
5: <outbound>
6: <pass-through-router>
7: <stdio:outbound-endpoint system="ERR" />
8: </pass-through-router>
9: </outbound>
10: </service>


Exécuter le projet



Une fois lancé il suffit d’utiliser une simple page HTML



1:  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
2: <html xmlns="http://www.w3.org/1999/xhtml">
3: <head>
4: <title>Obtenir Résultat Examen</title>
5: </head>
6: <body>
7: <form method="GET" action="http://localhost:8888">
8: <input type="text" name="nom"/>
9: <input type="submit" value="Demander le Résultat de l'Examen" />
10: </form><br />
11: </body>
12: </html>


clip_image001[4]




La réponse est alors la suivante



clip_image002



Le serveur indique que tout s’est bien passé









INFO 2009-07-12 00:08:53,890 [connector.http.0.receiver.2] org.mule.transport.vm.VMMessageDispatcher: Connected: endpoint.outbound.vm://getResultatExamen






Si on provoque une exception (il suffit d’envoyer un nom de 1 caractère)



clip_image003



Le résultat est toujours affiché ( la situation est maitrisée)



clip_image004



Le serveur indique qu’on est passé en mode exception :



<><><><><>





INFO 2009-07-12 00:12:24,000 [connector.http.0.receiver.2] org.mule.transport.vm.VMMessageDispatcher: Connected: endpoint.outbound.vm://userErrorHandler



vendredi 9 octobre 2009

Tutorial Mule ESB & Spring Ioc: Utilisation des beans Spring avec Mule

NB : cet article fait partie d’une série de présentation et de tutoriaux pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Un des avantages de Mule est son choix stratégique de s’intégrer d’une manière native avec Spring, le plus célèbre des framework Ioc.

Mule gagne ainsi du terrain par rapport aux autres ESB open source, en facilitant l’intégration des adeptes de Spring dans sa communauté et en facilitant la réutilisation des codes source des applications métiers exploitant le framework Spring.

Je me pose encore la question, du moment que va choisir Spring (et maintenant Vmware) pour mettre la main sur Mule. Ce n’est pas pour diminuer de la qualité de Spring, mais pour que la communauté Spring bénéficie du savoir faire de Mule en la matière.

Avant d’indiquer la méthode d’injection des beans Spring, rappelons que Mule 2.0 est devenue très modulaire grâce à l’utilisation des namespaces

Lorsqu’on souhaite utiliser Spring, il faut ajouter les Xmlns

1:  xmlns:spring="http://www.springframework.org/schema/beans" 


Ainsi, l’entête du fichier de configuration



1:  <?xml version="1.0" encoding="UTF-8"?> 
2: <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
3: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4: xmlns:spring="http://www.springframework.org/schema/beans"
5: xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
6: xsi:schemaLocation="
7: http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
8: http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
9: http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">


Deux méthodes permettent d’ajouter des beans Spring dans une configuration Mule



1) Déclarer les beans directement dans la configuration



1:<spring:bean id="composantSimple"  
2: class=" com.oxia.att.mule.intro.ComposantSimple ">
3: <spring:property name="prefix" value="prefix injecté par Spring" />
4:</spring:bean>




2) Lier la configuration à un fichier externe de configuration de Spring. Exemple



1: <spring:beans> 
2: <spring:import resource="applicatinContext-dao.xml"/>
3: <spring:import resource=" applicatinContext-service.xml "/>
4: </spring:beans>


Dans la suite nous allons utiliser la première méthode.



La configuration doit être changée pour ne plus indiquer la classe du Composant mais une référence vers le Bean Spring.



1:  <component> 
2: <spring-object bean="composantSimple"/>
3: </component>


Exécuter le projet :



clip_image002



On constate que



le message est « passé » au bean Spring et que l’injection des propriétés (dépendance : ici la définition de prefix) de bean Spring sont correctes







Est ce que la stratégie de Mule s’arrimer au numéro 1 de l’Ioc pour attire plus d’adepte va s’avérer gagnante,







le temps nous le dira …






mais ceci est un autre sujet.

lundi 5 octobre 2009

Tutorial JBPM : BMP, Processus & JBPM

Voici quelques liens utiles pour débuter avec JBPM :

En français à partir du site :



En anglais liens très intéressants partir du site de Joram Barrez (jBPM core developer at JBoss/Red Hat ) http://www.jorambarrez.be/blog/about/



jeudi 1 octobre 2009

Tutorial Mule ESB : Une seconde application simple, Echo avec modification du message

NB : cet article fait partie d’une série de présentation et de tutorial pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Reprenons l’exemple précédent (voir lien suivant ), pour y ajouter un élément nouveau :

Traiter le message obtenu au niveau du point d’entrée (<inbound>) avant de le transférer vers le point de sortie </outbound>

C’est l’occasion d’utiliser le tag XML component :

<component>

</component>

Le service métier à invoquer

Avant de configurer le service « métier », il est temps de développer la classe Java qui sera responsable de traiter le message :

Il est très important de savoir que cette classe java est indépendante de Mule : il s’agit d’un simple POJO (on verra même comment l’injecter avec de l’Ioc et Spring)

La classe Java est la suivante : com.oxia.att.mule.intro.ComposantSimple

Avec Eclipse :

clip_image002

Préciser le package et le nom de la classe

clip_image004

Puis développer la classe :

Ceci est un exemple simple

1:  package com.oxia.att.mule.intro; 
2: import java.util.UUID;
3: package com.oxia.att.mule.intro;
4: import java.util.UUID;
5: public class ComposantSimple {
6: private String prefix="Le préfix du message_";
7: private String numero;
8: /*
9: * exemple simple de méthode métier qui
10: * exploite le message obtenu ( Mule est responsable de tout transformer ...)
11: * et retourne un nouveau message ( Mule est responsable de tout transformer ...)
12: *
13: */
14: public String hello(String message) {
15: numero = "_"+ UUID.randomUUID().toString();
16: System.out.println("le message originale est : " +message);
17: message = prefix + message + numero ;
18: System.out.println("le message en sortie est : " +message);
19: return message ;
20: }
21: public void setPrefix(String prefix) {
22: this.prefix = prefix;
23: }
24: }
Maintenant il suffit d’indiquer à Mule d’utiliser cette classe Java comme destination su message obtenu au niveau du INBOUD (utiliser une nouvelle configuration de Mule (echo-system-2-config.xml)

1:  <component class="com.oxia.att.mule.intro.ComposantSimple"/> 
Le projet se présente comme suit :

clip_image001

Exécuter le projet :

clip_image003

On constate que

  • le message est « passé » au POJO sous format String

Mule a découvert (tout seul) la méthode à utiliser, grâce à son algorithme de résolution :

  • deux candidata public void setPrefix(String prefix) et public String hello(String message),
  • la méthode set public void setPrefix(String prefix) ne retourne rien alors que la méthode public String hello(String message), retourne un String : c’est une cible


En cas d’ambiguïté, il est possible d’indiquer la méthode dans la configuration du composant

mais ceci est un autre sujet

mardi 29 septembre 2009

Formation SOA & Open Source par la pratique: Atelier de Mise en ouvre des architectures orienté service (SOA) avec des outils open source

J’anime, à Tunis, du 26 au 30 octobre prochain un Atelier pratique de formation sur la mise en ouvre des architectures orienté service (SOA) avec des outils open source.

Bien que SOA n’est pas une histoire d’outils, l’objectif de cet Atelier est de mettre en pratique, par les participants des concepts de base de la démarche SOA et de l’intégration d’application d’entreprise. Les participants, exploiteront mettront en ouvre des web services avec la démarche Contract-First, utilseront l’ESB Mule pour réaliser des intégrations avec ou sans web service et mettront en place un outil de gouvernance,

1.1 Objectif de l’Atelier

La complexité croissante des Systèmes d’Information et les opportunités technologiques rendent de plus en plus indispensable de disposer d’un cadre pour organiser, structurer et fédérer les travaux sur le Système d’Information et d’instaurer une interopérabilité naturelle dans les services afin de réduire le besoin d’intégration.

Ce workshop apporte un retour d’expérience des meilleures pratiques pour la mise en œuvre des architectures orientées services avec des outils open source.

L’objectif de ce workshop est de former les participants à la pratique des architectures orientés services. Les outils open source suivants seront utilisés :

  1. Java 1.6
  2. Eclispe IDE
  3. Mule ESB
  4. ActiveMQ (MOM)
  5. Spring
  6. Hibernate
  7. Et d’autres outils de monitoring, de suivi, et de gestion d’environnements SOA …

1.2 Compétences à acquérir

A l'issue de ce séminaire, les participants seront en mesure de:

  1. Comprendre les problèmes d’intégration d’applications en SI
  2. Comprendre les fondements des architectures orientées services SOA
  3. Capacité de mettre en ouvre des services web avec différentes méthodes
  4. Capacité d’exploiter et de mettre en ouvre l’ESB Mule 2.2.1
  5. Evaluer les étapes d’un projet de mise en ouvre par la pratiques d’une approche SOA

1.3 A qui s'adresse ce séminaire?

· Développeur Java

· Intégrateur SI

· IT manager

· Architectes d'applications

1.4 Niveau requis

Pour bénéficier pleinement de ce cours, les stagiaires doivent avoir :

  • Une connaissance de Java.
  • Une compréhension des enjeux des SI dans l’entreprise

1.5 Détails du programme

1.5.1 Introduction à l’Architecture d’Entreprise et à l’EAI (Entreprise Application Intégration

Présenter des problématiques d’intégration des applications d’Entreprise (EAI)

  • Définition du SI
  • Les motivations de l’Architecture de SI
  • Nouvelles architectures informatiques
  • Métaphore de la cité & Plan d’occupation des sols (POS)
  • intégration des applications d’Entreprise (EAI)
  • EAI & Architecture d’entreprise
1.5.2 Présentation de XML
  • Architectures d’interopérabilité
  • Présentation de XML
    • XML les objectifs de conception
    • Notion de base : balise et attributs
    • Pourquoi XML?
    • La notion de Schéma XML
  • Formats d’échange, Interopérabilité et portabilité des données
1.5.3 SOA (Architecture Orientée Service) et EDA

Présenter la démarche SOA, et présenter des concepts et de la démarche SOA (architecture orientée services), des besoins en infrastructures et de la notion de maturité SOA

  • Problématique de l’intégration en entreprise et intra-entreprises
  • SOA : initialement un simple besoin d‘intégration
  • SOA, différents points de vue
  • Présentation du concept SOA
  • La notion de service (au sens SOA)
  • SOA s’applique à tous les niveaux de l’EAI
  • Principes fondamentaux de l’architecture SOA

1.6 Rôle d’un ESB et présentation de Mule ESB

  • Les concepts de Mule ESB et l’infrastructure nécessaire
  • Un premier exemple avec MULE ESB
  • Les différentes composantes de Mule
  • Place de Mule ESB dans un SI

1.7 Présentation de Spring Ioc et Hibernate

  • Les concepts Spring & de l’Ioc
  • Mule ESB et Spring
  • Introduction à Spring & Hibernate

1.8 Présentation des MOM

  • Besoins & définitions :
    • Middleware Orienté Message : les clés de l'intégration grâce aux mécanismes asynchrones. Les fonctions principales d'un MOM : routage, intégrité transactionnelle, déclenchement de process.
  • - L'opportunité de désolidariser les applications pour assurer la flexibilité d'une solution EAI. Acteurs et enjeux : IBM, BEA, TIBCO.
  • La norme JMS de Java EE
    • La norme JMS
    • ActiveMQ un MOM open source

1.9 Mule d’un point de vue développements

  • Intégration avec Spring
  • L’IDE Eclipse
  • La gestion des exceptions
  • Etendre Mule
    • Les transformations,
    • Les Filtres
    • Les Routeurs
  • Les Test unitaires
  • Le transport dans Mule
  • Les Web Services
    • Rappel sur SOAP
    • Contract Fist
    • La consommation
  • Les transactions dans Mule
    • Transaction étendue XA
    • Garantie de délivrance des messages
    • Transaction base de données et MOM
  • Gestion des codes sources dans un environnement multi développeurs
  • Le log & les pistes d’audit
  • La Sécurité
  • Intégration automatique
  • Les bests practices

1.10 Mule ESB d’un point de vue Analyste métier

  • Définir les services : cycle de vie d’un service
  • Spécifier les besoins
  • Spécifier le contrat de service
  • Spécifier les aspects métiers du SLA

1.11 Mule d’un point de vue Système

  • Les différentes possibilités de déploiements de Mule
  • EAI pattern
  • Scheduling
  • Choix du déploiement et conséquences
    • Sans Serveur d’application
    • Avec Serveur d’application
    • Hub & Spoke ou Network centric
    • Rôle du MOM
    • LDAP ou SSO
  • Monitoring & supervision
    • Lien avec le système de supervision en place
  • La gestion des SLA
  • Intégration continue
  • Les bests practices

1.12 Définition d’une architecture cible

  • Liste des architectures de déploiement possibles
    • Comparaisons
  • Développement de l’architecture cible
    • Règles d’architecture

1.13 Mise en place de la gouvernance

  • Cycle de vie d’un service
  • Zoom sur la phase d’identification des services : quelle approche
  • Comité de gouvernance
  • Cycle de vie des services
  • Template de spécification des services
    • Spécifications fonctionnelle
    • SLA (Service Level Agreement)

dimanche 27 septembre 2009

Tutorial Mule ESB : Une application simple, Echo sans altération de message

NB : cet article fait partie d’une série de présentation et de tutoriaux pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Introduction

L’application à développer est très simple, mais montre les premiers pas dans la création d’un projet d ‘intégration :

Nom du projet : Exercice_01_echo_System

Son objectif est limité : présenter une abstraction de la console de saisie IN et de sortie OUT

Pour commencer, créer un projet de type Mule (Exercice_01_echo_System) et un fichier de configuration de Mule (echo-system-config.xml)

Présentation générale du fichier de configuration de Mule

Le fichier de configuration de Mule est au format XML. L’IDE de Mule présente se base surl la version vision simplifie d’un éidteur XML de

clip_image002

clip_image004

Une configuration Mule, minimale est de ce type :

<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns=" …

<model …>

<stdio:connector…/>

Les déclarations globales au niveau de la configuration

<service …>

Une déclaration d’au moins un service

<inbound>

</inbound>

Au moins un point d’entrée, pour recevoir les messages

Une abstraction du transport et des détails des protocoles

<component>

</component>

Le service métier à invoquer

<outbound>

</outbound>

Un point de sortie, pour envoyer des messages

Une abstraction du transport et des détails des protocoles

</service>

 

</model>

</mule>

 

Le lien est alors simple à faire avec cette vision de l’intégration

clip_image006

Construction pas à pas d’un exemple simple :

Utiliser une configuration de Mule : echo-system-1-config.xml.

La première partie du fichier XML est le prologue :

1:  <?xml version="1.0" encoding="UTF-8"?>  


La seconde partie est la définition des namespaces à utiliser par Mule



1:  <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"  
2: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3: xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
4: xsi:schemaLocation="
5: http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
6: http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">


Ensuite on déclare le connecteur qui sera utilise par les points de contactes : ici on utilise le système d’entrée sorties classiques IN/OUT. Chez Mule la déclaration est basée sur le namespaces stdio.



1:  stdio:connector name="SystemStreamConnector"  
2: promptMessage="Saisir les informations nécessaires: "
3: messageDelayTime="1000"/>


Dans sa première version, le Service de l’application cible ne fait que deux choses :



1) recevoir sur le Système IN : des messages en texte



2) expédier ces messages vers le Système OUT



on a donc besoin de deux partie



1) <inbound>



a. Pour définir ce <inbound>, on utilise le namespaces du protocole de transport cible






<inbound>



<stdio:inbound-endpoint system="IN"/>



</inbound>





1) <outbound>



b. Pour définir ce < outbound >, on utilise le namespaces du protocole de transport cible : <stdio:outbound-endpoint system="OUT"/>



c. Mais il faut ajouter une indication sur le Routage du message en définissant le routeur à utiliser. Dans notre cas nous avons besoin simplement d’un routage systématique sans altération du message ni filtrage : c’est l’objectif du routeur de Mule dit <pass-through-router>






<outbound>



<pass-through-router>



<stdio:outbound-endpoint system="OUT"/>



</pass-through-router>



</outbound>







Ainsi la définition du service est la suivante



1:    <model name="echoSystemSimple">  
2: <service name="echoService">
3: <inbound>
4: <stdio:inbound-endpoint system="IN"/>
5: </inbound>
6: <outbound>
7: <pass-through-router>
8: <stdio:outbound-endpoint system="OUT"/>
9: </pass-through-router>
10: </outbound>
11: </service>
12: </model>


Le fichier de configuration devient :



1:  <?xml version="1.0" encoding="UTF-8"?>  
2: <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
3: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4: xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
5: xsi:schemaLocation="
6: http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
7: http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">
8: <stdio:connector name="SystemStreamConnector"
9: promptMessage="Saisir les informations nécessaires: "
10: messageDelayTime="1000"/>
11: <model name="echoSystemSimple">
12: <service name="echoService">
13: <inbound>
14: <stdio:inbound-endpoint system="IN"/>
15: </inbound>
16: <outbound>
17: <pass-through-router>
18: <stdio:outbound-endpoint system="OUT"/>
19: </pass-through-router>
20: </outbound>
21: </service>
22: </model>
23: </mule>


L’exécution du projet dans Mule est très simple :



clip_image001

mercredi 23 septembre 2009

Tutorial Mule ESB & Eclipse : déployer un projet d’intégration avec Eclipse

NB : cet article fait partie d’une série de présentation et de tutoriaux pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Déployer le projet à partir d’Eclipse

Bien que la meilleure solution de déploiement soit l’usage d’un outil de Build automatique (Ant ou Maven), il est simple de déployer un projet Mule à partir d’Eclipse

Avant de commencer, rappelons que Mule a besoin de 2 éléments pour exécuter un projet d’intégration

1) Le fichier de configuration

2) Le ou les fichier(s) jar des classes du projet :

a. ces fichiers doivent être disponibles dans le classpath

b. le plus simple c’est de les copier dans le répertoire préparé par mule pour ce besoin

-  le répertoire %MULE_HOME%lib\user

clip_image002

Ainsi, il suffit d’exporter le projet sous format JAR dans ce répertoire

%MULE_HOME%lib\user

Pour cela

1) sélectionner le projet dans le navigateur de projet d’Eclipse

2) avec un click droit de la souris, sélectionner : Export

clip_image004

la suite est très simple : choisir type d’export vers un fichier JAR

clip_image006

Choisir les fichiers à exporter et autre paramètre classique d’un Jar Java.

clip_image008

Choisir le répertoire vers d’export du projet Jar (pour simplifier, copier directement vers le répertoire cible %MULE_HOME%lib\user).

clip_image010

Fixer les paramètres selon les besoins.

clip_image012

Fixer les paramètres selon les besoins. Puis choisir Finish

clip_image014

Une fois le fichier jar généré, il est possible de lancer l’exécution du projet en dehors d’Eclipse.

Exécuter le projet

Copier le fichier de configuration dans un répertoire (au choix) : bonjour-oxia-config.xml

Exemple

F:\TestProjet\conf

Créer un fichier command Windows .bat : bonjour-oxia-config.bat

Dans le répertoire

F:\TestProjet\

Le contenu du fichier est

"%MULE_HOME%\bin\mule.bat" -config .\conf\bonjour-oxia-config.xml

Lancer l’exécution

bonjour-oxia-config.bat

clip_image016

Arrêter l’exécution avec « CTRL-C »

clip_image018

dimanche 20 septembre 2009

Tutorial Mule ESB & Eclipse : Créer un projet d’intégration avec Mule en utilisant l’IDE Eclipse

NB : cet article fait partie d’une série de présentation et de tutoriaux pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Créer un projet Mule

Une fois installé, le plugin de Mule ajoute un nouveau type de projet dans Eclipse : le projet de type Mule

Dans Eclipse : ajouter un projet Mule est simple

Choisir

File à New à other

clip_image002

Choisir Mule : Mule Project

clip_image004

Cliquer Next >

clip_image006

Donner un nom au projet

Cliquer Next >

clip_image008

Ajouter des répertoires sources, des librairies nécessaires (comme pour un projet java Eclipse classique)

Cliquer Finish

Le projet est ainsi crée

clip_image009

Nous remarquons l’existence de

Répertoire

description

src

Mettre les codes sources

Conf

Mettre les fichiers de configuration de Mule

Bin

Contient les .class

Créer une configuration Mule

Sélectionner le projet Mule

Cliquer sur : File à New à other

clip_image011

Choisir Mule configuration

clip_image013

A ce stage, un assistance de création d’entête de Namespaces est disponible, selon les besoins en protocole de transport, en routeurs …

clip_image015

Le résultat est un fichier de configuration Mule (vide) prêt à l’emploi

clip_image017

Le fichier est le suivant :

1:  <?xml version="1.0" encoding="UTF-8"?> 
2: <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
3: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4: xmlns:ftp="http://www.mulesource.org/schema/mule/ftp/2.2"
5: xmlns:file="http://www.mulesource.org/schema/mule/file/2.2"
6: xmlns:http="http://www.mulesource.org/schema/mule/http/2.2"
7: xmlns:https="http://www.mulesource.org/schema/mule/https/2.2"
8: xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
9: xsi:schemaLocation="
10: http://www.mulesource.org/schema/mule/ftp/2.2 http://www.mulesource.org/schema/mule/ftp/2.2/mule-ftp.xsd
11: http://www.mulesource.org/schema/mule/file/2.2 http://www.mulesource.org/schema/mule/file/2.2/mule-file.xsd
12: http://www.mulesource.org/schema/mule/http/2.2 http://www.mulesource.org/schema/mule/http/2.2/mule-http.xsd
13: http://www.mulesource.org/schema/mule/https/2.2 http://www.mulesource.org/schema/mule/https/2.2/mule-https.xsd
14: http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
15: http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd">
16: </mule>


Lancer l’exécution du projet à partir d’Eclipse



Cette version de l’IDE est limité, en terme d’assistant graphique, mais présente l’avantage de permettre de lancer l’exécution du projet à partir de Eclipse et de présenter la capacité de débogage nécessaire à la mise en ouvre de tout projet Java.



Préparer une configuration Mule valide : l’exemple suivant permet de montrer les capacités de Mule qui intègre par exemple le support du Schedular Quartz.



1:  <?xml version="1.0" encoding="UTF-8"?> 
2: <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
3: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4: xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
5: xmlns:quartz="http://www.mulesource.org/schema/mule/quartz/2.2"
6: xmlns:spring="http://www.springframework.org/schema/beans"
7: xsi:schemaLocation="
8: http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
9: http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
10: http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd
11: http://www.mulesource.org/schema/mule/quartz/2.2 http://www.mulesource.org/schema/mule/quartz/2.2/mule-quartz.xsd">
12: <spring:bean id="bonjourOXIA" class="java.lang.String">
13: <spring:constructor-arg>
14: <spring:value><![CDATA[
15: BONJOUR OXIA
16: BONJOUR OXIA
17: BONJOUR OXIA
18: ]]>
19: </spring:value>
20: </spring:constructor-arg>
21: </spring:bean>
22: <model name="bonjouroxiaModel">
23: <service name="bonjourService">
24: <inbound>
25: <quartz:inbound-endpoint jobName="welcome" repeatInterval="3000" repeatCount="1">
26: <property key="payload" value-ref="bonjourOXIA" />
27: <quartz:event-generator-job />
28: </quartz:inbound-endpoint>
29: </inbound>
30: <outbound>
31: <pass-through-router>
32: <stdio:outbound-endpoint system="OUT"/>
33: </pass-through-router>
34: </outbound>
35: </service>
36: </model>
37: </mule>


Sélectionner la configuration Mule



clip_image002[4]




Le serveur est ainsi lancé, sous le contrôle d’Eclispe avec la configuration souhaité






clip_image004[4]

Architecte SOA & Professionnel Open Source Headline Animator

 
Khaled BEN DRISS
Cloud Computing, SOA et Web 2.0 : Des sujets techniques sur SOA et l'Open Source : de Java & .Net, PHP5, Symfony, à SaaS / PaaS en passant par Azure, google appengine, le BPM, la Modélisation et d'autres sujets du coté du serveur et cloud computing.