Tuning JVM et GC (Garbage collector) young generation : influence de la taille de la young generation 1/3

Question : quelle est l’influence d’une young generation de petite taille

Ce travail a été réalisé en collaboration avec Hamed KOUBAA, Architect SOA.

introduction

L’objectif de cet atelier est de sensibiliser au choix des espaces mémoires de la JVM, basée sur un GC générationnel. Nous avons appliques au JDK de SUN.

Fixer la taille des zones mémoire de la JVM dépend de l’application, du cycle de création d’objets de l’application et nécessite une compréhension « détaillée» du fonctionnement du GC.

Les paramètres à donner à la JVM soutenant une d’une application Batch ne sont pas les mêmes que ceux d’une application web transactionnelle.

Afin d’illustrer les effets de la taille des zones mémoires de la JVM, nous avons délibérément utilisé un exemple simple et disponible : la fameuse démo Swing Java2D.

Le principe de l’atelier est simple : utiliser l’application java2D (inclus dans la jdk %java_home%/demo/jfc/Java2D) avec des paramètres différents de la JVM et interpréter les résultats obtenus.

pré requis

Les expérimentations de ce tutorial peuvent être réalisé sous Solaris, Linux et Windows : là où le JDK Hotspot de Sun fonctionne.

Il suffit d’Installer une JDK ultérieure à la version 5.0.

Les tests ont été réalisés avec JDK 1.0.0 build 17.

Noter que le JDK qui inclut des "démos" est nécessaire - un JRE n'est pas suffisant.

Configurer les variables d’environnement JAVA_HOME

- télécharger si besoin visualgc .

Maintenant vous êtes prêt pour démarrer l’atelier.

Manipulation des espaces mémoires de la jeune génération(young generation):

L’espace mémoire de la jeune génération (young generation) est constituer de la zone dite « Eden » plus deux espaces dits « survivor ».

L’objectif de cette partie de l’atelier est de savoir :

· Comment utiliser l’interface graphique de java perf pour lancer l'application Java 2D Demo et surveiller son rendement avec Visual GC.

· où trouver la ligne de commande qui règle les paramètres de la JVM

· Comment reconnaître si la jeune génération est trop petite, trop grande, avec une taille adéquate

Une jeune génération trop petite

Commencer par fixer la configuration suivante (appelé dans la suite LesCamandesGC)

-XX:NewSize=1m -XX:MaxNewSize=1m -Xms16m -Xmx16m -XX:MaxTenuringThreshold=0

Ces valeurs sont utilisées uniquement pour mettre l’accent sur les effets des paramètres du GC.

Lancer l'application Java 2D %java_home%/demo/jfc/Java2D avec cette commande

> java LesCamandesGC -jar Java2Demo.jar

- déterminer son identifiant de la machine virtuelle (VMID). La commande est « jps »

Ensuite utiliser ce VMID pour exécuter le programme jstat et recueillir des statistiques de base GC

- lancer l’application visual GC (télécharger si besoin visualgc ).

Visual GC donne un excellent aperçu de ce qui se passe dans la JVM. Lorsque vous combinez cette visualisation des statistiques supplémentaires recueillies pendant l'essai vous pouvez jauger la performance de l'application cible

L’application visualGC est composée de 3 volets :

1) Visual GC : Affiche les informations des applications de base comme le temps écoulé du processus et un certain nombre de statique (par exemple les options de ligne de commande).Notez que les zones d'écran représentant les Perm gen, Old gen, Eden et les espaces survivor (S0 et S1) sont dimensionnées proportionnellement à la capacité maximale des espaces.

2) Graph : Affiche des statistiques au fur et à mesure qu'elles évoluent dans le temps. Pour tous les exercices, l'intervalle d'échantillonnage a été choisie pour être une seconde.

3) Survivor Space histogramme : Le panneau histogramme affiche un aperçu de la répartition par âge des objets dans l'espace survivor actif après la dernière collection de la jeune génération. L'écran est composé de 32 régions de taille identique, un pour chaque âge objet possible.

Suite …

- Cliquez rapidement sur l’onglet transform > dans le carrée transform anim (celui en bas), augmenter le nombre d’objets de string et d’images animés au maximum.

Cette manipulation est importante pour obtenir l’effet recherché. En effet, les applications graphiques de l’onglet « transform » sont bien adaptés pour l'expérimentation du tuning de la JVM car ils créent beaucoup d'objets temporaires.

Faire un imprime-écran du visualGC après une minute et demie d’observation et essayer d’analyser le résultat.

Pour cet exemple, nous avons eu 160 collections mineures (c'est la jeune génération), 16 collections complètes « full » (c’est l'ancienne génération) et nous avons passé près de 1,5 secondes au garbage collection (cad un total de 1,66% de la durée totale en GC).

Interprétation :

Comment savoir si la jeune génération est trop petit?

- Le premier indice est le pattern en dents de scie dans l’old generation. (NOTE: la vitesse à laquelle les objets sont générés dépend du matériel spécifique que vous utilisez ... Dans certains cas, ceci peut prendre plus temps pour se manifester .)
certains objets qui sont encore en vie sont directement promu vers l'ancienne génération (la jeune génération est trop petite …).

- Un autre indice est le grand nombre de GC de type mineur, dans un petit espace de temps.

NB : Pour forcer l’observation de ce comportement, nous pouvons utilisé la config suivante ;

-XX:NewSize=1m -XX:MaxNewSize=1m -Xms16m -Xmx16m -XX:MaxTenuringThreshold=0

Pourquoi une jeune génération trop petite est un problème?

La collection des anciennes générations est généralement plus chère que les collections des jeunes générations.

En trouvant la taille appropriée de la jeune génération, on permet au GC mineurs, qui sont plus rapides, de nettoyer les objets temporaire en ne laissant passer que les objets encore vivant pour être promus en « old generation ».

NB : Vous pourriez vous demander, pourquoi ne nous fixons-XX: MaxTenuringThreshold = 0?

Avec ce paramétrage, nous demandons essentiellement à la JVM de promouvoir tout objet qui est vivant au cours d'un GC mineur à l’old generation.

à utiliser uniquement pour des besoins de démo!

Mais, pour des applications batch, où la majorité des objets sont “de type old” un MaxTenuringThreshold  de petite taille peut aider ….

Tuning JVM et GC (Garbage collector) : Avantages du "generational collection"

Un des avantages du "generational collection" est qu'il peut rendre les pauses causés par les GC plus courtes en ne rassemblant pas toutes les générations à la fois.

Rappelons que lorsque la demande d'allocation de mémoire ne peut être satisfaite,

• le GC déclenche d'abord "une collecte mineure", qui rassemble seulement la plus jeune génération. Puisque plusieurs des objets dans la jeune génération seront déjà morts (le collecteur copiant n'a pas besoin d'examiner les objets morts), les pauses mineures de GC peuvent être courtes et peuvent souvent reprendre un espace significatif du Heap.

• Si la collecte mineure libère assez d'espace du heap, le programme peut reprendre immédiatement.

• Mais, si ce n'est pas le cas, le GC procède à la collecte des générations plus élevées jusqu'à ce qu'assez de mémoire ait été reprise (une Full collection).

• Si le GC, ne peut reprendre assez de mémoire après une "Full collection", il augmentera la taille du heap, ou il lèvera une Erreur OutOfMemoryError

Les paramètres les plus connues sont :

-XX:PermSize, -XX:MaxPermSize, -XX:NewSize, -XX:MaxNewSize, -Xms, -Xmx

-XX:PermSize	La taille de la génération permanente
-Xms	La taille initiale du Heap
-Xmx	La taille maximale du Heap
-XX:MinHeapFreeRatio	Pourcentage de l'espace libre minimum au sein d'une collection. Le GC accroît ou réduit la taille des collections pour tenter de préserver cette proportion. Par défaut elle est souvent de 40% (dépend de la plate-forme).
-XX:MaxHeapFreeRatio	Pourcentage de l'espace libre maximum au sein d'une collection. Le GC accroît ou réduit la taille des collections pour tenter de préserver cette proportion. Par défaut elle est souvent de 70% (dépend de la plate-forme).
-XX:NewRatio	Un ratio est utilisé qui indique le rapport entre la taille de la tenured gen et la young gen. Ce ratio est ensuite appliqué sur la valeur de l'option Xmx qui fixe la taille totale du heap. -XX:NewRatio=n ou n est un nombre entier. Si n vaut 3 alors la young gen est 3 fois plus petite que la tenured generation.
-XX:NewSize	Fixe la taille de la young gen -XX:NewSize = 4m fixe la taille la young generation à 4 MO.
-XX:MaxNewSize	Fixe la taille maximale de la young gen - XX:NewSize = 40m fixe la taille maximale la young generation à 40MO.

• Les commandes en –X ne sont pas documentées !!!

· java –X

Dans la suite nous allons montrer l’importance des choix des valeurs de certains de ces paramètres

Tuning JVM et GC (Garbage collector) : Rappel sur les generational garbage collectors

Question : quelle est la spécificité des GC (Garbage collector) générationnel

La technique employée pour les Garbage collector, depuis la JVM 1.2, est appelée "generational garbage collection" combine ces deux techniques pour tirer le meilleur parti des différents algorithmes du GC.

Ainsi, le heap (tas) est divisé en plusieurs zones basées sur l'âge d'un objet. Les différentes générations sont nettoyées (Garbage collection) séparément en utilisant des algorithmes de collection différents.

La mortalité enfantine des objets

L’idée est basée sur le constat de la mortalité enfantine des objets. La majorité des objets ont une durée de vie très courte "mortalité enfantine". Une étude statistique a montré que 80-98% des objets nouvellement alloués, meurent en quelques million d'instructions. Une autre a montré que 80-98% des objets nouvellement alloués, meurent avant qu'un autre Megabyte a été alloué.

Ce constat a un grand impact sur les algorithmes choisis pour le GC.

Generational collector

Ainsi un GC de type "Generational collector" divise le heap en plusieurs zones (générations).

Le objets sont créés, systématiquement, dans une zone dédiée dite young generation(dédié aux jeunes objets).

Les objets qui répondent à des critères de promotion, tels qu'avoir survécu à un certain nombre de collectes (lire GC), sont alors promus à la zone dédiée aux générations plus anciennes.

Cette zone est dite older generation (ou Tenured).

Un "generational collector" est libre d'employer une stratégie différente de collecte pour ses différentes zones et d'exécuter la collecte des "garbage" sur les générations séparément.

Dans la suite, nous utilisons les termes « anglais » afin de faciliter le lien avec les paramètres.

Le tuning de la JVM est le choix des paramètres

La JVM présente quelques dizaines de paramètres, permettant le tuning des performances.

Le plus important est de se fixer des objectifs et de conaitre sa cible.

Voici, quelques éléments à considérer, lors des choix des paramètres de chacune des zones mémoire constituant le Heap :

• Durée de Pause : Est ce que le collecteur arrête le programme pour réaliser la collecte (dit stop-the-world)? Pour combien de temps? Est ce que la durée des pauses peut être limitée ?

• Prédictibilité des pauses : Est ce les pauses causées par le GC peuvent être programmées à des périodes convenables à l'utilisateur du programme et non lorsque le GC le décide?

• Usage CPU : Quel pourcentage de la CPU est consommé par le GC?

• Utilisation de la Mémoire : Certains GC nécessite l'usage d'espace mémoire non accessible par l'utilisateur du programme, ce qui augmente la taille totale de la mémoire utilisée. La taille utilisée est supérieur à la mémoire nécessaire réellement au programme.

• Interaction avec la mémoire virtuelle : Pour les systèmes qui n'ont pas beaucoup de mémoire physique, une opération de GC peut nécessiter une interaction avec la mémoire virtuelle ce qui dégrade les performances.

• Interaction avec le Cache : Même pour les applications dont le heap peut résider dans la mémoire le GC aura comme impact de "flasher" les données utilisées par le programme, à cet instant, en dehors du cache, ce qui dégrade les performances

Suite de l’article sur les paramètres de la JVM, permettant le tuning des performances, dans les prochains postes ….

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.

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 :

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>

La réponse est alors la suivante

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)

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

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

Tutorial JBPM : BMP, Processus & JBPM

Voici quelques liens utiles pour débuter avec JBPM :

En français à partir du site :

• · BPM & Moteur de workflow : l’offre open source
• · La version 4 de JBPM prend le virage de BPMN
• · Graph Oriented Programming (GOP) avec JBPM
• · Comment modéliser un processus métier avec JBPM : exemple “gestion des entretiens”
• · Jbpm 4 Tutorial : JBPM 4 a simplifié son model de programmation et a confirmé l’orientation BPMN
• · Un peu de monitoring Métier (BAM) avec JBPM et SeeWhy (event-driven business intelligence )
• · Quelle est la différence entre JBPM et Intalio ?

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/

• · Part 1: modeling the process with BPMN
• · Part 2: coding the business process
• · Intermezzo: how does jBPM fit into my architecture?
• · Part 3: prototyping with the jBPM console
• · Part 4: the end application
• · Part 5: BI and BAM

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 :

Préciser le package et le nom de la classe

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 :

Exécuter le projet :

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

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)

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

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

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 :

F# .Net, Programmation fonctionnelle et web service : Storm un projet open source de chez codeplex, un concurrent à SOAPUI en .Net

Codeplex ; la forge de projets open source de Microsoft, et aussi le nom de la nouvelle fondation open source de Microsoft, a vue la mise à jour d’un projet intéressant à compter parmi les outils du monde SOA.

Il s’agit de STORM : un outil open source pour le test des web services.

STORM c’est quoi ?

STORM permet de

-· Tester de services web (développés en utilisant n'importe quelle technologies (. NET, Java, etc)

-· Dynamiquement invoquer les méthodes de service Web, même ceux qui ont des paramètres d'entrée avec des types de données complexes

-· Test de multiples services Web à partir d'une interface utilisateur.
-. Modifier / manipuler les requêtes SOAP

L’équipe de SOAPUI, n’a pas à avoir peur de ce nouveau projet (existe depuis moins d’une année), qui dans sa version 1.1.0, ne peut rivaliser avec le numéro un du domaine.

STORM est développé en F# .Net

L’originalité de STORM se trouve dans le fait qu’il est développé en F#

Ce qui lui confère les bases pour les tests fonctionnels de web services.

Bref,

Un projet intéressant à double raison

1) Utilise le nouveau langage Fonctionnel de Microsoft : on sait maintenant que F#, fonctionne

2) Permet de Tester des web service

F# (F Sharp) c’est quoi ?

F# (F Sharp) est un langage de programmation fonctionnelle de la famille des .NET. F# est orienté-objet et fait partie de la famille des langages ML ( Meta Language).

SOTRM exploite le Framework.NET 2.0 et se base sur F# 1.9.3.14 (F# n’est forcément installé sur la machine d’exécution)

Testons STORM ?

Avant de commencer, télécharger à partir de http://www.codeplex.com/storm (depuis octobre 2008, c’est la version 1.1.0 qui est disponible).

A première vue, je suis séduit

1) Ça fonctionne sans problème, sur Windows XP SP3, il faut préciser que j’ai installé .Net Framework 3.5 (ça arche pour .Net 2.0)

Utilisons un web service Publique dont le WSDL est publié au

http://www.deeptraining.com/webservices/weather.asmx

dont le WSDL est le suivant

STORM présente les services fournis :

Choisir un Ville, Tunis par exemple

Lancer l’appel au web service avec la Valeur City=Tunis

La requête SOAP est la suivante

On peut avoir une vue POXO

Comme d’habitude, le temps annoncé est « super »é à Tunis !

La console de log présente les séquences d’appel et les temps d’exécution du point de vue du consommateur du service.

http://www.deeptraining.com/webservices/weather.asmx loading http://www.deeptraining.com/webservices/weather.asmx Acquiring the wsdl... Resolving the wsdlendpoint... Generating code... Code generated successfully. Compiling into an assembly... Analyzing the compiled assembly generated from http://www.deeptraining.com/webservices/weather.asmx Found method : GetWeather from type Weather Elapsed Time : 9,3125(sec) Invoking... Done. Elapsed Time : 0,765625(sec) Invoking... Done. Elapsed Time : 0,546875(sec) Invoking... Done. Elapsed Time : 0,515625(sec) Done.

Retour sur Codeplex

Reste que je m’étonne du faible, nombre de développeurs .Net connaissant codeplex, sans commune mesure avec sourceforge, très célèbre dans la communauté Java par exemple, autant

Une histoire de culture de l’open source, peut être, et ça pourrait expliquer la création de la fondation open source de Microsoft du même nom.

Mais ceci est un autre sujet