Archive for the 'java' Category


Sercices Oriented Architecture: Les outils et ressources de base 0

Les outils:

Deux éditeurs sont incontournables: Netbeans et Eclipse.
Netbeans propose des editeurs bpel , xsd et wsdl assez intuitifs. Il est particulièrement adapté à glassfish pour tester des applications jbi.

De la même manière, Eclipse propose de nombreux plugins permettant de développer des applications bpel et bpmn. La démarche serait plutot top down: Je commence par écrire un fichier bpmn ( Des spécifications uniquement business) et j’arrive à générer un fichier bpel (Un langage d’execution). Eclipse est plustot destiné à générer des applications jbi pour servicemix.
Il existe une version d’eclipse comportant tous les plugins: spagic.

Pour ceux qui veulent apprendre à manipuler BPEL, je conseille netbeans.

JBI : Un exemple avec ServiceMix 0

Ce tutorial accompagne la création d’une première application:
Il s’agit de surveiller un répertoire, et lorsqu’un fichier xml apparaît dans ce répertoire, le déplacer vers un autre répertoire, et envoyer le contenu dans une queue JMS et d’en archiver une copie.

JBI Components

Les JBI Components (Binding Components et « Service Engine» ) sont des plug-ins qui rajoutent des fonctionnalités au « JBI Container» .

 

Vous pouvez installer un « JBI Component»  en le copiant dans le répertoire « hotdeploy» .

 

Un « JBI Component»  se compose d’un fichier zip, appelé aussi « Service Assembly»  ou SA.
Un SA se compose:

  • D’un fichier META-INF/jbi.xml
  • De plusieurs fichier zip appelés SU (Service Unit) . Chaque SU contient au moins un fichier xbean.xml

Il est possible de regarder les Components déployés avec une console jmx (jconsole), d’arrêter ou de démarrer les SA.

Créer un SA (Service Assembly)

Créer un projet

Recopier ce pom.xml dans un directory vide.
 

4.0.0 bg.servicemix parent 1.0-SNAPSHOT pom Tutorial http://servicemix.org

Exécuter la commande:

mvn install

Cela valide le fait que mvn est installé, et que le fichier pom.xml est correct.

 

ServiceMix fournit plusieurs achetypes Maven pour faciliter la créattion de projets.

Créer un projet SU (Service Unit) avec Maven et l’archetype « servicemix-service-unit» 

Nous commencerons par utiliser l’archétype permettant de créer des SU (Service Unit)

Depuis le directory que nous avons créé, la commande suivante créera un « service unit»  projet appelé « tutorial-file-su» :

mvn archetype:create -DarchetypeArtifactId=servicemix-service-unit -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeVersion=3.2.1 -DartifactId=tutorial-file-su

Mettre la version correspondant à la version de serviceMix.

 

Nous remarqons que le premier fichier pom.xml que nous avions écrit a été modifié, et qu’un nouveau répertoire a été créé, contenant un pom.xml.

Rajouter une dépendance pour un « component»  JBI

Chaque SU (Service Unit) est detiné à être un « component»  JBI. Nous spécifions cela dans le pom.xml , en rajoutant une dépendance au pom.xml.

L’outillage maven de servicemix fera le reste.

Le component « servicemix-file»  fournit l’integration du JBI aux fichiers. Il peut être utilisé pour lire et écrire des fichiers, ou surveiller (poll) un répertoire.Il est décrit ici

org.apache.servicemix servicemix-file ${servicemix-version}

Configurer le xbean.xml

 

Ensuite, nous aurons à configurer notre nouveau SU pour fournir réellement un service.
Nous faisons cela en créant un fichier appelé xbean.xml dans le répertoire src/main/resources

 

L’exemple définit 2 namespaces: Le prefixe « file»  fait référence à un namespace pour adresser les fonctionnalités standard, tandis que le prefixe « tut»  sera utilisé pour le namespace dans lequel notre service sera défini.

 

 

Définition d’un « file sender endpoint» 

 

Un « file sender»  peut être utiliser pour écrire des fichiers localement.
Voilà un exemple de « file sender» :

 

Remarquez les 2 attributs service (Qui font référence à l’ensemble du SU) et endpoint (Qui fait référence au sein du service , à cet interface file:sender).

 

Définition d’un « file poller endpoint» 

 

Nous allons lire les fichiers XML dans un répertoire (spécifié par l’attribut « file» , aussi veillez a ce que ce directory existe sur votre système )

La ligne XML ci-dessous est destinée à configurer un « poller» , qui vérifiera la presence d’un nouveau fichier toutes les n secondes. Ce fichier sera envoyé au « file sender»  endpoint spécifié par les attributs « targetService»  et « targetEndpoint» .

 

Le poller appartient au même service que le « sender» ; mais à un autre endpoint.Il a 2 attributs targetService et targetEndpoint qui désignent vers quelle appli seront envoyée les fichiers (Dans notre exemple,c’est le même service).

 

En résumé:

Vous spécifiez le component cible pour un SU comme une dépendance dans Maven (» dependancy»  dans le pom.xml).

Dans ServiceMix, la pluspart des SU seront configurés par des fichiers xbean.xml

 

Créer le SA (» Service Assembly» ) avec Maven et l’archetype « servicemix-service-assembly» 

 

De la même manière que nous avons créer notre SU avec un archetype Maven, nous allons créer notre projet SA .

Exécuter cette commande :

mvn archetype:create -DarchetypeArtifactId=servicemix-service-assembly -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeVersion=3.2.1 -DartifactId=tutorial-sa

Un nouveau projet a été généré

 

Ajouté le SU dans le SA

 

Nous voulons ajouter le SU que nous avons créé au SA. L’outil Maven le fera automatiquement si nous mettons une dépendance dans le pom.xml du SA.
Nous avons à utiliser le groupId, l’artifactId et la version du SU ici:

xxx org.apache.servicemix.tutorial tutorial-file-su 1.0-SNAPSHOT xxxx

Utilisons Maven pour construire l’ensemble:

mvn install

Déployer le SA

Avant de commencer, assurez vous que ServiceMix est démarré.

Maintenant , naviguez dans le directory de votre SA, et utiliser le plugin JBI « Maven»  pour déployer votre projet:

cd tutorial-sa mvn jbi:projectDeploy

Tester le SA

 

Nous avons configurer notre SU « file»  pour surveiller la presence de fichiers dans un directory, et les envoyer à un autre répertoire.
Copier juste un fichier xml dans le répertoire surveillé, et ServiceMix le déplacera après quelques secondes vers le « endpoint» 

 

Rajouter 2 SU

A la place de simplement copier des fichiers depuis un directory vers un autre, nous allons maintenant envoyer un message vers une queue JMS. Nous voulons aussi archiver une copie du message en utilisant le pattern « wiretap» .

 

En premier, nous avons à créer 2 projets supplémentaires pour nos 2 SU.
A la place d’utiliser le simple archetype « servicemix-service-unit»  comme precedemment,nous allons utilser 2 nouveaux archetypes:

  • « servicemix-eip-service-unit»  pour créer le module « tutorial-eip-su» 
  • « servicemix-jms-provider-service-unit»  pour créer le module « tutorial-jms-su» 

 

Nous connaissons la syntaxe:
mvn archetype:create -DarchetypeArtifactId=XX -DarchetypeGroupId=org.apache.servicemix.tooling -DartifactId=YY

mvn archetype:create -DarchetypeArtifactId=servicemix-eip-service-unit -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeVersion=3.2.1 -DartifactId=tutorial-eip-su mvn archetype:create -DarchetypeArtifactId=servicemix-jms-provider-service-unit -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeVersion=3.2.1 -DartifactId=tutorial-jms-su

Ces archetypes sont un peu plus sophistiqué :
Ils ajoutent les < dependency > pour les components JBI qu’ils ciblent. Ils fournissent un xbean.xml pour démarrer.

Après cela, ajouter ces 2 nouveaux SU au SA en rajoutant les < dependency > au pom.xml du SA.

 

La documentation de serviceMix décrit comment utiliser jms : servicemix-jms.

 

Modifier le fichier xbean.xml de tutorial-jms-su, afin d’accéder à une queue appelée « queue/tutorial»  sur ActiveMQ (qui est embarqué dans ServiceMix).

 

 

 

Configurer le « tutorial-eip-su» 

 

Le « Servicemix-eip component»  est un container « routeur»  où plusieurs types de routage peuvent être déployés en tant que SU.

 

Modifier le fichier xbean.xml de « tutorial-eip-su»  pour définir le « wiretap»  que nous voulons.

Les différents pattern sont définis dans la doc de ServiceMix-eip
voici le shema du « wire-tap»  pattern:
wire-tap

 

 

 

 

Nous voulons envoyer les messages au « jms endpoint» , aussi, nous spécifions cette information au premier < eip:exchange-target/ >

Le deuxième fait référence au endpoint < file:sender /> que nous avons déclaré plus tôt.

 

Modifier la configuration de tutorial-file-su

 

Nous avons à modifier le « targetService»  du endpoint < file:poller > pour réferrer à notre nouvellement créé « wiretap» .
Cela pourrait être comme cela:

 

 

Construire et deployer

 

Quand tout est fait, vous étes prèt pour construire et deployer le SA.
Lors du build, les logs devraient ressembler à cela:

[INFO] Scanning for projects… [INFO] Reactor build order: [INFO] Tutorial [INFO] Tutorial :: File SU [INFO] Tutorial :: JMS SU [INFO] Tutorial :: EIP SU [INFO] Tutorial :: SA … [INFO] ——————————– [INFO] BUILD SUCCESSFUL [INFO] ——————————– …

Test

 

Si vous copiez un fichier dans le directory surveillé par le « poller» , il sera copié dans le directory « sender» , comme avant.

Cependant, il devrait aussi y avoir une copie du message dans notre queue JMS.

Pour le controller, connectez vous à ServiceMix avec la console JMX et naviguez vers org.apache.activemq/localhost/Queues.

Une queue devrait avoir été créée avec le nom « queue/tutorial»  et l’attribut « EnqueueCount»  indique le nombre de messages qui ont déjà été envoyés.

JBI – Java Business Integration: C’est quoi ? 0

JBI est un standard java (JSR 208) qui définit une architecture pour permettre l’interoperabilité d’applications avec un système d’échanges de messages.
Les messages entre les « components»  sont échangés à travers un « Normalized Message Router»  (NMR). Le NMR sert de « Message Exchange Pattern»  (MEP). Le NMR sert d’intermédiare pour échanger des messages, quelquesoit l’endroit où est le « Component» . Les plugins ne communiquent pas directement les uns avec les autres: Ils communiquent exclusivement vers le NMR.

jbi

JBI Components

Les « plugins»  mentionné ci-dessus sont quelquefois appelé « JBI components» .

« Binding Components» 

Un « binding component»  (BC) a 2 buts:

  • Communiquer en utilisant un protocole distant.
  • Normaliser les messages reçus

Les BC sont utilisés pour communiquer en dehors l’environnement JBI.

Exemples de protocoles fournis par les BC: http, jms,ftp,smtp,xmpp,rmi,corba,xmpp

JBI Components

Les JBI Components (Binding Components et « Service Engine» ) sont des plug-ins qui rajoutent des fonctionnalités au « JBI Container» .

 

 

Vocabulaire

  • Java Business Integration (JBI) : C’est le nom d’une JSR (Java Spécification)
  • Entreprise Service Bus (ESB) : C’est la même chose qu’un JBI, mais pas forcemment normalisé.
  • Component Les composants proposent des services accessibles par l’intermédiaire d’interfaces. Ce sont les parties enfichables dans le framework JBI. Il se divisent en deux sous-familles:Service Engine (SE) et Binding Component (BC)
  • Service Engine (SE) :Les SE fournissent la logique métier et les transformations (XSLT, …). Il peuvent consommer eux-même d’autres SE.
  • Binding Component (BC) : Les BC fournissent la connectivité, qu’il s’agisse de protocoles (FTP, HTTP,…), de piles (SOAP, JMS, …) ou de services externes au conteneur JBI. Ils permettent l’accès de depuis l’extérieur au services d’une application JBI.
  • Rôles : Les composants peuvent avoir les rôles suivants : Consumer (Le composant utilise un service ) et Provider (Le composant fournit un service ) Chaque composant peut être à la fois consumer et provider.
  • EndPoint :Les services proposés par les composants sont accessibles via des endpoints. Un service correspond à un endpoint.
  • Normalized Message Router (NMR) :Le Normalized Message Router reçoit et envoi des messages de la part de composants. Il est responsable du routage des messages. Les messages sont tous dans un format normalisé
  • Normalized Message :Les Normalized Messages sont les messages echangés par une application JBI. Ce sont des documents XML formé :D u contexte du message ( Il inclut des informations tels que le protocole de communication, des informations spécifiques à d’autres composants … )et du contenu du message (Toutes les données)
  • Delivery Channel :Les composants se « connectent » sur le NMR grâce au delivery channel. C’est une voie de communication bidirectionnelle leur permettant d’envoyer et de recevoir les messages
  • Service Unit (SU) :Chaque composants à déployer est défini dans un SU. Celui contient toutes les informations relatives au composants (fiche de transformation Xslt… ) et obligatoirement un descripteur qui se trouve dans un dossier META-INF à la raçine de l’archive.
  • Service Assembly (SA) :Les composants qui doivent interagir ensemble sont rassemblé dans un SA. Celui-ci contient obligatoirement un descripteur où se trouvent toutes les informations relatives aux SUs à deployer, ainsi que les archives de ces Sus.

 

Dans notre prochain tutorial, nous implementeront une application sur ServiceMix

SOA et SCA: Le Projet Apache Tuscany 0

Le projet Tuscany a pour but de créer une infrastructure SOA.


Tuscany est basé sur les spécifications définis par l’» Open CSA» .

SCA (Service Component Architecture) définit un modèle simple à base de service permettant la construction , l’assemblage et le déployment de services (Existant et nouveau) et de façon indépendante des languages et technologies.


SDO (Service Data Object) fournit une interface pour manipuler les différentes formes de données, y compris des documents XML, qui peuvent exister dans un réseau de Services eet fournit les mécanismes pour des conversions.

Première Application Tuscany

Ce tutorial est inspiré (traduit ?) de getting started with tuscany

Etape 1 : Telecharger java, tuscany et maven

Téléchargement: « Tuscany Java SCA release« .

Construire le « Calulator»  en java

Cet exemple illustre comment définir votre application en restant concentré sur la logique métier. Il vous ammene à travers les étapes de la construction d’un « Calculator» . Toutes les connections entre les « Components»  à l’intérieur du « Composite»  sont locales et décrires en utilisant des Interfaces Java.

Etape 0 – Obtenir les librairies nécessaires

Pour cela il faut utiliser maven.


voila le POM.xml:

  1.  
  2. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  3.     <modelVersion>0.0.0</modelVersion>
  4.     <groupId>com.bg.soa.test</groupId>
  5.     <artifactId>bg_soa_test_tutos_tuscany</artifactId>
  6. <packaging>jar</packaging>
  7.     <version>1.0-SNAPSHOT</version>
  8.     <name>bg_soa_test_tutos_tuscany</name>
  9.     <url>http://maven.apache.org</url>
  10.  
  11.     <repositories>
  12.         <repository>
  13.             <id>apache.incubator</id>
  14.             <url>http://people.apache.org/repo/m2-incubating-repository</url>
  15.         </repository>
  16.     </repositories>
  17.  
  18.     <dependencies>
  19.  
  20.         <dependency>
  21.             <groupId>org.apache.tuscany.sca</groupId>
  22.             <artifactId>tuscany-host-embedded</artifactId>
  23.             <version>1.2-incubating</version>
  24.         </dependency>
  25.  
  26.         <dependency>
  27.             <groupId>org.apache.tuscany.sca</groupId>
  28.             <artifactId>tuscany-implementation-java-runtime</artifactId>
  29.             <version>1.2-incubating</version>
  30.             <scope>runtime</scope>
  31.         </dependency>
  32.  
  33.          <dependency>
  34.             <groupId>org.apache.tuscany.sca</groupId>
  35.             <artifactId>tuscany-binding-ws-axis2</artifactId>
  36.             <version>1.2-incubating</version>
  37.             <scope>runtime</scope>
  38.         </dependency>
  39.  
  40.         <dependency>
  41.             <groupId>org.apache.tuscany.sca</groupId>
  42.             <artifactId>tuscany-host-tomcat</artifactId>
  43.             <version>1.2-incubating</version>
  44.             <scope>runtime</scope>
  45.         </dependency>   
  46.  
  47.         <dependency>
  48.             <groupId>junit</groupId>
  49.             <artifactId>junit</artifactId>
  50.             <version>3.8.1</version>
  51.             <scope>test</scope>
  52.         </dependency>
  53.     </dependencies>
  54. </project>
  55.  

Si vous travaillé avec eclipse, placé ce fichier à la racine de votre projet, puis tapez:

  1.  
  2. mvn eclipse:eclipse
  3.  

Etape 1 – Définir quels sont les blocs nécessaires.

Réflechissez à comment votre application peut être divisé en petites fonctions et/ou services.Chaque bloc est une unité logique d’opération qui peut être utilisée dans une application englobante. Pour notre exemple, le « Calculator»  sera divisé en 5 blocs: AddService bloc, SubstractService bloc, MultiplyService bloc, DivideService bloc et un bloc principal qui accepte des requètes et les route vers le service approprié.Nous appelerons ce bloc « CalculatorService» .

Etape 2 – Implémenter chaque bloc

Maintenat que vous avez identifié les blocs de fonctionnalité de votre application, vous ètes prét pour les créer.

En SCA chaque bloc de fonctionnalité est appelé un « Component» . Aussi regardons comment on implémente un « Component» .

Nous prendrons comme premier exemple le bloc – ou « Component»  – AddService .

Le « Component»  AddService fournira un service qui additionne 2 nombres l’un à l’autre.Le « Component»  CalculatorService utilise le « Component»  AddService à chaque fois qu’on lui demande de faire une addition.


Si nous devions écrire le « Component»  AddService en Java classique, nous pourrions commencer par décrire une Interface Java.

  1.  
  2. package com.bg.soa.tuscany.calculator;
  3.  
  4. public interface AddService {
  5.  
  6.     double add(double n1, double n2);
  7.  
  8. }
  9.  

Maintenant , nous fournissons une implementation de cette interface.

  1.  
  2. package com.bg.soa.tuscany.calculator;
  3.  
  4. public class AddServiceImpl implements AddService {
  5.  
  6.     @Override
  7.     public double add(double n1, double n2) {
  8.         return n1+n2;
  9.     }
  10. }
  11.  

Mais Attend! On est en train d’écrire un « Component SCA»  ? Ca doit être plus compliqué qu’une interface et son implementation, non ? Bon, en fait, un SCA « Component»  peut être écrit en Java classique, c’est ce que nous avons fait.


Nous pouvons utiliser SCA pour exposer ce service que fournit le « Component»  addService à d’autres acteurs, par exemple des Web-Services, JMS ou RMI, sans changer une ligne de code à l’implémentation de AddService.

Regardons le « Component»  CalculatorService. Il est interessantparcequ’il va devoir appelé le « Component»  AddService.


Dans l’application finale, il aura aussi à appeler les « Component»  SubstracService, MultiplyService et DivideService.


A nouveau, nous commencerons par définir une interface parceque CalculatoService doit lui-même fournir une interface que d’autres appelleront.

  1.  
  2. package com.bg.soa.tuscany.calculator;
  3.  
  4. public interface CalculatorService {
  5.  
  6.     double multiply(double n1, double n2);
  7.     double add(double n1, double n2);
  8.     double substract(double n1, double n2);
  9.     double divide(double n1, double n2);
  10.  
  11. }
  12.  

Maintenant, nous implementons cette interface:

  1.  
  2. package com.bg.soa.tuscany.calculator;
  3.  
  4. import org.osoa.sca.annotations.Reference;
  5.  
  6. public class CalculatorServiceImpl implements CalculatorService {
  7.  
  8.     private AddService addService;
  9.     private SubtractService subtractService;
  10.     private MultiplyService multiplyService;
  11.     private DivideService divideService;
  12.  
  13.     @Reference
  14.     public void setAddService(AddService addService) {
  15.         this.addService = addService;
  16.     }
  17.  
  18.     ... methodes set pour les autres attributs à rajouter
  19.  
  20.     public double add(double n1, double n2) {
  21.         return addService.add(n1, n2);
  22.     }
  23.  
  24.     ...implementation des autre méthodes définies dans l'interface ici.
  25. }
  26.  

On aura remarqué l’annotation « @Reference» .


Nous avons maintenant quelques « Components»  implémenté en Java.Chaque « Component»  a une interface bien définie, utilisant java dans notre exemple.

Step 3 – Assembler l’application:

Tout est parfait, mais comment exécuter ces deux « Components» . Oui bien sûr, le programmeur java qui est en nous veut foncer, écrire les lignes permettant de connecter nos deux « Components»  ensemble et de les éxecuter. On pourrait le faire facilement dans notre cas:

  1.  
  2. public class CalculatorClient {
  3.     public static void main(String[] args) throws Exception {
  4.  
  5.         CalculatorServiceImpl calculatorService = new CalculatorServiceImpl();
  6.         AddService            addService        = new AddServiceImpl();
  7.         calculatorService.setAddService(addService);
  8.  
  9.         System.out.println("3 + 2=" + calculatorService.add(3, 2));
  10.         //appeler les autres methodes ici, si nous avons implementé SubtractService, MultiplyService, DivideService
  11.     }
  12. }
  13.  

Mais cela n’utilise pas Tuscany SCA, et étendre ce code pour implementer un Web-Srvice par exemple ne serait pas simple.


En premier, changeons le code pour appeler le « Tuscany SCA runtime»  avant d’appeler nos « Components» .

  1.  
  2. package com.bg.soa.tuscany.calculator;
  3.  
  4. import org.apache.tuscany.sca.host.embedded.SCADomain;
  5.  
  6. public class MainApp {
  7.  
  8.     static boolean isOn =true;
  9.     public static void main(String[] args) throws Exception{
  10.         SCADomain scaDomain = SCADomain.newInstance("Calculator.composite");
  11.         CalculatorService calculatorService = scaDomain.getService(CalculatorService.class, "CalculatorServiceComponent");
  12.         System.out.println("3 + 2 = " + calculatorService.add(3, 2));
  13.         while(true) Thread.sleep(10000);
  14.     }
  15. }
  16.  

Vous pouvez voir que nous commençons par utiliser une méthode static pour obtenir une instance de SCADomain.


Le SCADomain est un concept en SCA qui represente les frontières d’un sysème SCA.
Il pourrait être distribué entre plusieurs processeurs.
Pour l’instant, regardons comment cela fonctionne à l’intérieur d’une seule JVM.

Le paramètre « Calculator.composite»  fait référence à un fichier xml qui décrit comment les components dans l’application « Calculator»  sont assemblés.


Voilà le XML à l’intérieur de ce fichier « Calculator.composite»  qui est dans le classpath.


la dernière ligne est là pour empécher la JVM de s’arrêter. Nous verrons plus loin (Quand nos exposerons des WS par exemple) à quoi cela servira.

  1.  
  2. <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"  name="Calculator">
  3.  
  4.     <component name="CalculatorServiceComponent">
  5.         <implementation.java class="com.bg.soa.tuscany.calculator.CalculatorServiceImpl"/>
  6.         <reference name="addService" target="AddServiceComponent" />
  7.         <!-- references a SubtractComponent, MultiplyComponent et DivideComponent  -->
  8.     </component>
  9.  
  10.     <component name="AddServiceComponent">
  11.         <implementation.java class="com.bg.soa.tuscany.calculator.AddServiceImpl"/>
  12.     </component>
  13.  
  14.     <!-- definitions de SubtractComponent, MultiplyComponent et DivideComponent -->
  15.  
  16. </composite>
  17.  

Vous pouvez observer que nous avons défini 2 « components»  et spécifié les classes Java implémentant ces « components»  que Tuscany SCA a besoin de charger.
Ce sont les classes que nous avons juste implémentées.

Remaquez aussi que le « CalculatorServiceComponent»  a une référence nommée « addService» .


Dans le XML, cette référence correspond au « AddServiceComponent» .
Ce n’est pas une coincidence que le nom de la référence « addService»  corresponde au nom du champs addService que nous avons créé quand nous avons implémenté « CalculatorServiceImpl» .


Le moteur « Tuscany SCA»  parse les informations du fichier XML et les utilise pour construire les objets et leurs relations qui représente notre application « Calculator» .
Il crée en premiet des instances de AddServiceImpl et CalculatorServiceImpl.
Il injecte ensuite une référence de l’objet AddServiceImpl dans le champs addService de l’objet CalculatorServiceImpl.
Si vous regardez à nouveau comment nous avons implémenté le CalculatorService, vous remarquerez une annotation @Reference qui dit à SCA quel champs sont à référencé.


C’est equivalent à ce bout de code pour un clent java habituel:

  1.  
  2.         CalculatorServiceImpl calculatorService = new CalculatorServiceImpl();
  3.         AddService            addService        = new AddServiceImpl();
  4.         calculatorService.setAddService(addService);
  5.  



Une fois que le fichier composite est chargé dans le SCADomain, notre client demande au SCADomain de nous donner une référence vers le component appelé « CalculatorServiceComponent» .

  1.  
  2.     CalculatorService calculatorService = scaDomain.getService(CalculatorService.class, "CalculatorServiceComponent");
  3.  

Nous pouvons utiliser cette référence pour accéder aux méthodes que nous avons créées, ici par exemple, la méthode CalculatorServiceImpl.add().

Les spécifications SCA décrive souvent les applications SCA sous forme de diagramme.
Cela aide souvent quels sont les components qui composent une application et comment ils sont cablés ensemble.
Si nous traçons un diagramme de ce que nous avons construit dans notre exemple, nous obtenons quelquechose comme la figure suivante:

Step 4 – Déployer l’application:

Si le fichier « Calculator.composite»  est dans notre class-path, ainsi que les autres librairies (les .jar), nous pouvons éxécuter notre exemple.



Nous proposons ici un exemple de fichier ant permettant la compilation et l’execution.


Il faut bien sûr adapter les properties tuscanyHome …


On peut remarquer que la liste des librairies (des jar) est définie dans le manifest du tuscany-sca-manifest.jar . Ce jar est livré uniquement avec le binaire de tuscany (Pas avec les sources).

  1.  
  2. <project name="sample-calculator-webapp" default="compile">
  3. <property name="tuscanyHome" location="C:\java\tuscany-sca-1.2-incubating" />
  4. <property name="test.class" value="com.bg.soa.tuscany.calculator.MainApp" />
  5. <property name="test.jar" value="bg-sample-calculator.jar" />
  6.  
  7.     <target name="init">
  8.         <mkdir dir="target/classes" />
  9.         <mkdir dir="src/main/resources" />
  10.     </target>
  11.  
  12.     <target name="compile" depends="init">
  13.         <javac srcdir="src/main/java" destdir="target/classes" debug="on" source="1.5" target="1.5">
  14.             <classpath>
  15. <pathelement location="${tuscanyHome}/lib/tuscany-sca-manifest.jar" />
  16.             </classpath>
  17.         </javac>
  18.         <copy todir="target/classes">
  19.             <fileset dir="src/main/resources" />
  20.         </copy>
  21.         <jar destfile="target/${test.jar}" basedir="target/classes">
  22.             <manifest>
  23.                 <attribute name="Main-Class" value="${test.class}" />
  24.             </manifest>
  25.         </jar>
  26.     </target>
  27.  
  28.     <target name="run-classes">
  29.         <java classname="${test.class}" fork="true">
  30.             <classpath>
  31. <pathelement path="target/classes" />
  32. <pathelement location="${tuscanyHome}/lib/tuscany-sca-manifest.jar" />
  33.             </classpath>
  34.         </java>
  35.     </target>
  36.  
  37.     <target name="run">
  38.         <java classname="${test.class}" fork="true">
  39.             <classpath>
  40. <pathelement path="target/${test.jar}" />
  41. <pathelement location="${tuscanyHome}/lib/tuscany-sca-manifest.jar" />
  42.             </classpath>
  43.         </java>
  44.     </target>
  45.  
  46.     <target name="clean">
  47.         <delete quiet="true" includeemptydirs="true">
  48.             <fileset dir="target" />
  49.         </delete>
  50.     </target>
  51. </project>
  52.  

Utiliser d’autres configurations

En regardant en arrière, l’application « Calculator»  construite en utilisant le « Tuscany SCA»  n’est rien de plus qu’une application java ordinaire.
Cependant, nous avons un fichier xml « Composite»  qui décrit comment notre application est assemblée.

Cette notion d’ assemblage est importante et apporte de nombreux avantage si notre application devient plus complexe et que nous voulons la modifier, ou intégrer d’autres components, sans se soucier du langage dans lequel ils sont écrits.

Maintenant , disons que notre « Calculator»  est devenu populaire que nous voulons la mettre sur l’intranet de la société et la rendre acessible depuis les browser d’applications Web2.0.
C’est ce que nous cherchons depuis le début.Comme nous avons un fichier XML qui décrit notre application, cela devient facile avec « Tuscany SCA» .


Ce qui suit devrait faire l’affaire:

  1.  
  2. <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"  name="Calculator">
  3.  
  4.      <service name="CalculatorService" promote="CalculatorServiceComponent">
  5.          <interface.java interface="com.bg.soa.tuscany.calculator.CalculatorService"/>
  6.          <binding.ws uri="http://localhost:8181/CalculatorService"/>
  7.      </service>   
  8.  
  9.     <component name="CalculatorServiceComponent">
  10.         <implementation.java class="com.bg.soa.tuscany.calculator.CalculatorServiceImpl"/>
  11.         <reference name="addService" target="AddServiceComponent" />
  12.         <!-- references to SubtractComponent, MultiplyComponent and DivideComponent  -->
  13.     </component>
  14.  
  15.     <component name="AddServiceComponent">
  16.         <implementation.java class="com.bg.soa.tuscany.calculator.AddServiceImpl"/>
  17.     </component>
  18.  
  19.     <!-- definitions de SubtractComponent, MultiplyComponent and DivideComponent -->
  20.  
  21. </composite>
  22.  

Tout ce que nous avons fait, c’est rajouter le tag <service> qui indique à Tuscany comment exposer notre « CalculatorService» .


Nous n’avons pas modifier une ligne du code!

Pour tester, il faut prendre un browser et aller à l’adresse indiquée:
http://localhost:8181/CalculatorService?wsdl

Remarque: Lors de l’éxécution, vous pouvez avoir le message d’erreur suivant :Address already in use: Une autre application ecoute sur ce port. Cela peut être la même application que vous avez re-lancé.

Si nous voulons exposer le service en JSON, il faut modifier le service comme suit:

  1.  
  2.      <service name="CalculatorService" promote="CalculatorServiceComponent">
  3.          <interface.java interface="com.bg.soa.tuscany.calculator.CalculatorService"/>
  4.          <binding.ws uri="http://localhost:8181/CalculatorService"/>
  5.          <binding.jsonrpc/>
  6.      </service>
  7.  



Comme je ne suis pas à l’aise avec cette techno (JSON) , je ne l’ai pas testé!

Exposer le service en RMI, …

Il faudrait au niveau du service rajouter le tag suivant:

  1.  
  2.     <tuscany:binding.rmi host="localhost" port="8099" serviceName="CalculatorRMIService"/>
  3.  

Rajouter un « Component»  en script ruby, python, javascript, groovy ..

Il faut rajouter les dépendances suivantes dans le fichier POM.xml (Ou dans le classpath lors de l’execution)

  1.  
  2.         <dependency>
  3.             <groupId>org.apache.tuscany.sca</groupId>
  4.             <artifactId>tuscany-implementation-script</artifactId>
  5.             <version>1.2-incubating</version>
  6.             <scope>runtime</scope>
  7.         </dependency>
  8.  

Et dans le fichier .composite, il faut rajouter un « Component» :

  1.  
  2.     <component name="SubstractServiceComponent">
  3.         <tuscany:implementation.script script="com/bg/soa/tuscany/calculator/SubtractServiceImpl.rb"/>
  4.     </component>
  5.  

voilà le fichier composite complet:

  1.  
  2. <?xml version="1.0" encoding="UTF-8"?>
  3. <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0" name="Calculator">
  4.  
  5.      <service name="CalculatorService" promote="CalculatorServiceComponent">
  6.          <interface.java interface="com.bg.soa.tuscany.calculator.CalculatorService"/>
  7.          <binding.ws uri="http://localhost:8183/CalculatorService"/>
  8.      </service>   
  9.  
  10.     <component name="CalculatorServiceComponent">
  11.         <implementation.java class="com.bg.soa.tuscany.calculator.CalculatorServiceImpl"/>
  12.         <reference name="addService" target="AddServiceComponent" />
  13.         <reference name="substractService" target="SubstractServiceComponent" />
  14.     </component>
  15.  
  16.     <component name="AddServiceComponent">
  17.         <implementation.java class="com.bg.soa.tuscany.calculator.AddServiceImpl"/>
  18.     </component>
  19.  
  20.     <component name="SubstractServiceComponent">
  21.         <tuscany:implementation.script script="com/bg/soa/tuscany/calculator/SubtractServiceImpl.rb"/>
  22.     </component>
  23.  
  24. </composite>
  25.  



Il ne faut pas oublier de reférencer ce « Component»  lors de la définition du « Component»  CalculatorServiceComponent, ainsi que de rajouter un xmlns:tuscany.

Et bien sur il faut definir le script dans le fichier SubtractServiceImpl.rb

  1.  
  2. def substract(n1, n2)
  3.     return n1 - n2
  4. end
  5.  


Conclusion

Vous venez d’avoir un apercu de la puissance des SOA: Collaboration entre services, entre plusieurs protocoles, plusieurs technologies.
Et il y encore plus: Les « Policies»  (Gestion des droits des services), la répartition des applications sur plusieurs serveurs, l’orchestration de services, le déploiement de tuscany sur Tomcat …
C’est relativement simple à mettre en oeuvre (Beaucoup plus simple que J2EE 2.3 !) Il y a de quoi s’enthousiasmer.
Qu’en pensez vous ?

Comment choisir un Enterprise Service Bus (ESB) ? 0

Traduction de servicemix faq Servicemix est un projet Apache proposant un ESB (Enterprise Service Bus),un SCA (Service Component Application) et un JBI (Java Business Integration).

Devant les besoins d’intégration d’un middleware , il est logique de considérer l’adoption d’un ESB. En faisant les évaluations des logiciels, il est important d’approcher le choses de manière à ce que vos exigences soient l’instrument central du processus. Il y a habituellement deux niveaux d’évaluation qui doivent être considérés lors de l’adoption de n’importe quel software : vos besoins métiers et les fonctionnalités du logiciel (Ici de l’ESB). Il y a de nombreux points dans ces 2 niveaux, et nous allons les passer en revue.

Votre objectif métier

 

Ne dites pas que votre objectif métier c’est le SOA. C’est le comment, pas le pourquoi. SOA n’est qu’une façon de penser l’architecture logicielle. Votre objectif métier c’est le but que vous essayez d’atteindre dans votre activité à travers l’usage du logiciel que vous êtes en train de mettre en place. Voilà un exemple:

Notre objectif métier est de combiner des données météo avec des cartes pour fournir aux clients des prévisions météo immédiates pour leurs destinations quand ils font des réservations de voyage sur notre portail.
Cela facilite non seulement les projets de voyage, mais aussi permet à notre système d’annonces publicitaire de mieux cibler les clients . Cela apportera un plus à nos clients, mais permettra de mieux cibler les publicités pour tenter d’augmenter le taux de conversions (clics sur annonces).

Remarquez que l’objectif métier est concentré sur le but du logiciel du point de vue métier. Le but est de:

  • Améliorer l’expérience des clients grâce à l’usage de cartes et de météo
  • Augmenter le taux de conversion des annonces publicitaires

Comprendre vos objectifs métiers vous met en meilleure position pour définir des exigences fonctionnelles pour atteindre cet objectif.

Vos exigences fonctionnelles

Une fois compris les objectifs métiers du projet, passons aux exigences fonctionnelles. Ci dessous sont listés quelques exemples d’exigences fonctionnelles pour notre objectif métier:

  • Fournir un accès aux données météo
    • Cela demande l’intégration d’un socket pour récupérer les données
    • Il faudra parser les données
  • Fournir un accès aux données géographiques, aux cartes
    • Google offre une API (Google Map API ) pour accéder à ces données
  • Créer un « overlay»  permettant d’intégrer les cartes et la météo sur les destinations des clients
  • En combinant les prévisions et les destinations , donner des règles au système fournissant les publicités pour adapter les annonces aux destinations et aux prévisions météo
  • Si le client clicke sur une annonce, sauvegarder cette information en base de donnée et la lier au profil du client. Cela améliorera nos prédictions lorsque le client reviendra une autre fois.

Ces exigences fonctionnelles augmentent dramatiquement lorsque l’objectif métier est identifié et clairement communiqué à toutes les personnes concernées dans le projet. De telles exigences vont amener les choix d’architecture du système et du logiciel.

Vos choix d’architecture

Avant de commencer à contacter des fournisseurs, il est important d’établir quelques choix d’architecture. Ces choix ne sont pas gravés dans le marbre. Cela peut inclure de concevoir le système d’une façon « Orientée Service» , d’utiliser certains packages, et peut être le hardware et les softs de test. Vous avez peut être fait ces choix de façon implicite à travers vos expériences précédentes. Si il en est ainsi, il est important d’identifier et de communiquer ces décisions explicitement aux différentes parties-prenantes pour qu’il y ait un certain niveau de clarté dans le groupe.

En travaillant à travers ces exercices, vous devriez avoir non seulement un ensemble de solutions à partager, mais vous aurez aussi vos critères d’évaluation d’un ESB.

Vos critère pour évaluer un ESB

N’importe quelle évaluation de software demande la connaissance des sujets discutés plus haut. Sans une bonne maîtrise de ces sujets, il est difficile d’évaluer la capacité d’un logiciel d’atteindre des buts spécifiques.

Il est important aussi de ne pas comparer les solutions logicielles fonction par fonction. Cette méthode d’évaluation ne donne une image quand au but attendu du logiciel.

Par exemple:

Quelle importance si un logiciel A affirme fournir des accès sécurisés vers des ressources X, mais que son API est vraiment compliqué à utiliser ?

Quelle importance si un logiciel B annonce fonctions 1, 2 et 3 mais que ses performances sont déplorables ?

Une expérience personnelle avec un logiciel donné dans votre environnement est une priorité. Quand on parle d’ESB, c’est encore plus critique parce que l’ESB contrôle l’intégration du système et que deux scénarios d’intégration ne sont jamais identiques. Déployer un ESB dans votre environnement pour résoudre un ou deux de vos problèmes par une validation de conception vous donnera bien plus d’informations et de conclusions que n’importe quelles comparaisons sur papier.

 

SOA : Service Oriented Architecture 0

Le but des SOA: Unifier des systèmes hétérogènes, permettre une certaine « agilité»  à des systèmes répartis, accélérer les vitesses de développement et de déploiement, offrir (ou utiliser) des services à (de) partenaires (Cela s’appelle l’interopérabilité).

Les moyens:
Des services sont fournis (En général des web-services) , s’appuyant sur les normes les plus répandues (http, xml, soap, wsdl) . Toute les informations necessaires pour invoquer un service sont décrites dans un contrat: le wsdl.

Plusieurs normes et outils sont apparus pour manipuler ces services:
BPEL (Business Process Execution Langage) permet de composer des services à partir d’autres services. Cela est très puissant … mais a aussi des limites.

Plusieurs solutions sont apparues autour de ces concepts:
1 – JBI « Java Business Integration»  Spécifié la JSR 208 de la JCP (Java Community Process),
2 – ESB « Enterprise Service Bus» ,
3 – SCA « Service Component Architecture»  Spécifié par l’OASIS.

Qu’est ce qu’il faut en penser? Que choisir ? Que faut-il éliminer? Quelles sont leurs différences ? Leurs points communs ? Lesquels survivront dans 5 ans? Dans 1 ans?
Les spécifs, c’est clair, sont quasiment illisibles (230 pages pour JBI, J’ai arrêté l’impression de la première specif du SCA (Assembly Model Spécification) à 80 pages et ainsi de suite …).
Les experts (Mais qui sont ils ???? ) , sont tous suspects de partialité, défendent leurs crèmeries ou leurs prestations…

Restons pragmatique : Au bout du compte, ce sera un produit, un serveur, une application distribuée ou non. Essayons de faire le tour de ce qui existe …
Au secours! Quoi faire ? Quels critères sélectionnés?

Nom SCA JBI ESB Version
swordfish *** *** *** Sortie Imminente
Mule *** *** ***** -
Tuscany ***** - - 1.2
open-esb ***** ***** 2.0
petals ***** ***** ***** 2.1.2
servicemix ***** ***** ***** 4.0
WebSphere - - - -
fabric3 ***** * * 0.5 Alpha2 Release
Newton ***** * * 1.2
HydraSCA ****** * * -
Weblogic ***** * * -
Oracle ***** * * -
covansys ***** * * -

Comment choisir ?

Les outils de développement java: Eclipse, ant, maven, JUnit 0

Lors du developpment d’un projet java, beaucoup d’outils, de produits, de technologies sont utilisés . Une liste de ceux que j’utilise constamment est dressée ici.

Les IDE

IDE

Un environnement de développement intégré (EDI ou IDE en anglais pour « Integrated Development Environment» ) est une application regroupant au minimum un éditeur de texte, un compilateur, des outils automatiques de publication, et un débogueur.

* Eclipse (Sans doute le plus populaire)
* jBuilder
* Net Beans

Gestionnaire de version

Permet d’archiver les sources et de remonter dans l’historique.
Dans le monde java, les plus répandus sont les suivant.

* cvs (Un peu ancien)
* subversion
o Il existe un plugin eclipse: Help>Software Updates>Find And Install>new Feature>…
url: http://subclipse.tigris.org/update_1.0.x
o Google propose un hebergement sur serveur subversion libre et gratuit pour projets sous licence GNU:
exemple :https://bertrand123.googlecode.com/svn
user bertrand2.guiral password: ********

Bug Tracking

Un « bug tracking»  system ou « système de suivi de bogues»  aide les développeurs et utilisateurs à reporter et suivre les bugs. On peut le faire par mail, mais c’est vite ingérable. Les utilisateurs soumettent les bogues rencontrés dans le logiciel. Les développeurs les gère et essaye de les corriger. Parfois ce qui est un bug pour l’utilisateur n’en est pas un pour le developpeur!!

Bugzilla

Bugzilla ancien outil de Netscape a été libéré en 1998. Il est maintenant géré par Mozilla (Plus connu pour Firefox et Thunderbird).

Ant: Langage de script

Ant , « Another Neat Tool»  (un autre chouette outil), la fourmi in English, a un nom particulièrement bien choisi. Ant vise à assurer les opérations répétitives, un peu comme les « Make»  du monde unix.
Ant est principalement utilisé pour automatiser la construction de projets Java, mais peut être utilisé pour tout autre type d’automatisation dans n’importe quel langage.
Parmi les tâches typiques réalisées par Ant, citons : la compilation, la génération des javadoc, la génération de jar, la copie de fichiers, le déploiement sur les serveurs …..

Maven:Gestion de projet java

Maven est un outil logiciel libre pour la gestion et l’automatisation de production des projets . C’est génial, sauf qu’il y a 2 versions (maven 1 et maven 2 !!) qui ne sont pas compatibles.

Apache nous avais habitué à mieux (Maven est un produit Apache). Il y a certains recoupements des fonctionnaltés avec ant.

JUnit: Tests Automatisés

L’on peut distinguer les tests unitaires et les tests d’intégration.JUnit est l’outil très répandu dans le monde java pour la réalisation de tests unitaires.
Junit est un des outils clés des methodes « Test Driven Development»  ou « Développement piloté par les tests» .

Les outils livrés avec le jdk:
Ces outils sont dans le repertoire bin du jdk:

* javaws.exe L’application « Java Web start» , qui est associé au type de fichier .jnlp à l’installation de java sous windows, permet de lancer des applications simplement à partie du web. Ces fichiers remplacent avantageusement les applets.
* javap.exe Simple Desassembleur .
* jdb.exe Un debuger java.
* jconsole.exe Une console jmx
* jar.exe Permet de créer des fichier jar (Java Archive)

Voilà les essentiels.

Moi, j’utilise Eclipse, Ant, Maven pour gérer les dépendances, JUnit quotidiennement.

Et Vous, qu’utilisez vous? Quels sont vos outils?