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

mercredi 28 avril 2010

.Net 4 : WCF data services une amélioration de ADO.Net data services

Si on étudie la nouvelle version de .Net, la 4.0, sortie ce 12 avril 2010, pour n’en choisir que la meilleure amélioration ?

que choisir ?

Difficile, ce choix, diront les adeptes. En vue du grand nombre de nouvelles fonctionnalités offertes.

Je vais écarter Workflow Foundation 4.0 (WF4), car il me semble qu’il soit une refonte de l’offre workflow. WF4 est plus qu’une amélioration à WF 3.5…

WCF Data Services Framework

Je pense que la meilleure amélioration concerne ADO.NET Data Services Framework.

Cela s’appelle désormais, WCF Data Services Framework. Bien sûre WCF : Windows Communication Foundation, l’ABC de l’exposition des services dans le Framework .Net et chez Microsoft.

WCF Data Services expose les données au moyen de services de type RESTful accessibles via HTTP. Il utilise le framework Entity Data Model (EDM) pour réaliser facilement, et sans code (ou presque) cette exposition.

Les données sont accessibles directement en utilisant le fameux URI (Uniform Resource Identifier) du HTTP. Un simple GET permet de faire une sélection complexe sur une base de données,  sans se préoccuper des détails. En toute sécurité, bien sûre.

Le data service peut être configuré pour renvoyer les données sous le format Atom et/ou JSON (JavaScript Object Notation).

Lors d’un projet, courant le mois de mars 2010, , j’ai utilisé Jquery pour exploiter des Data Services exposés en moins de 1à lignes de codes C#. Le projet consistait en l’intégration d’ une application basée sur la version 4.0 beta 2 de .Net et une autre déployé sous Tomcat (Java EE) et générée par W4 le fameux moteur de BPM.

Open Data Protocol : Un Protocol pour l’exposition des données

Microsoft a adopté REST et fait la promotion d’un protocole d’échange de données dit Odata (Open Data Protocol). OData est inspiré du protocole Atom Le Protocol des flux RSS.

Dans le. NET Framework 4, il ya eu des améliorations importantes dans les services de données (par rapport à la version .Net 3.5). Il y a eu des améliorations dans le mapping des données, les projections, la pagination coté serveur, le comptage.

Reste à tester les performances (annoncées comme améliorées) de ce nouveau service RESTful offert nativement dans .Net 4.0.

Un dernier mot : ce service est l’exemple typique que SOA n’est pas web service.

OData, est un protocole à suivre de tout près, il se base sur un principe d’uniformité des représentations des données, de l’accès et des opérations  … mais ceci est un autre sujet

mercredi 10 mars 2010

SOAPUI 3.5 ajoute le support des tests JMS, JDBC et AMF (flex)

Eviware a annoncé la version 3.5 de son outil de test de web service, le plus complet et le plus populaire du monde open source : SoapUI.

Les principales nouveautés de cette version 3.5 de SoapUI :

- Le support de test des bases de données à travers JDBC : cette fonctionnalité permet de tester des requêtes SQL et des appels à des procédures stockées pour toutes bases de données accessibles à travers JDBC. Les résultats sont convertit en XML.

- Le support de l’envoi et de la réception de messages (text, xml, binaire) vers des files d’attente avec le protocole JMS (point à point : Queues & ou publish / subscribe : Topics). Comme pour les entêtes http et soap, il est possible de spécifier les entêtes et les propriétés JMS. SoapUI se base sur HemesJMS pour le support de JMS .

- Le support de test des interfaces Flex en exploitant le protocole AMF (un exemple expliqué ici) (envoi des appels à distance de type AMF sur http, AMF c’est le format de message qu’utilise les ActionScript Flash/Flex pour interagir avec le serveur dit backend).)

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

Ainsi, d’un simple outil permettant le test des web service, de REST, SoapUI devient de plus en plus «une sorte de couteau suisse » pour le teste d’autres protocoles et amorce un virage vers le teste des applications de type RIA.

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

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.

mercredi 7 octobre 2009

Risk management, SaaS, e-Commerce et application en ligne : La Conférence ECIG à Sousse (Tunisie)

La conférence eCommerce et Gouvernance de l’Internet 2009 - ECIG 2009, va se dérouler à Sousse (Tunisie , traduction : au Soleil), le 8, 9 et 10 octobre 2009.

ECIG 2009 est co-organisée par Le Groupe Sup de Co La Rochelle, l’Institut pour le Management de la Recherche et de l'Innovation (IMRI) – Université Paris - Dauphine, le CEntre de REcherche en sciences de GEstion (CEREGE) et l’Université de Sousse

Notons que cette conférence, qui traitera en autre du Risk Management des applications en ligne : Nouvelles menaces, fraudes et solutions, SaaS, a le soutien de l’Association Information et Management (AIM) et la collaboration de l’Institut Supérieur de Gestion (ISG) de Sousse, de l’Institut des Hautes Etudes Commerciales (IHEC) de Sousse et de l’Ecole Doctorale en Sciences Economiques et de Gestion de Sousse.

Le 09 octobre : un atelier professionnel sur le « Risk Management des applications en ligne : Nouvelles menaces, fraudes et solutions »

Le sujet s’inscrit dans le cadre de la maîtrise des risques opérationnels lors des échanges en ligne qui est devenu un facteur essentiel de développement des applications distantes.

L’atelier traitera des thèmes suivants :

  • Risk management (gestion de risque) pour les nouveaux modèles des applications hébergées : SaaS, IaaS, PaaS & cloud
  • Risk management (gestion de risque) pour le Web Banking
  • Risk management (gestion de risque) pour les applications distribuées en finance, monétique, monnaie électronique, paiements mobiles, etc.
  • Risk management (gestion de risque) pour le travail collaboratif en entreprise
  • Risk management (gestion de risque) pour les Echanges de Documents Informatiques en e-Government

Cet atelier professionnel va s’atteler à lancer le débat entre professionnels et académiciens autour de la thématique de la maîtrise des risques. En effet, le risk management est un facteur essentiel de développement du e-Business.

Ma contribution ;

Au cours des débats j’aurais la chance de « présenter » le modèle SaaS (Software-as-a-Service), et la notion de gestion de risque, réel, imaginaire et perçu.

Le programme : en pdf

Le site : http://www.ecig2009.org/







mardi 6 octobre 2009

SOA is apparently still alive

For those who say that SOA is dead, the second edition International SOA Symposium sounds like a resurrection!

This 2nd International SOA Symposium - Rotterdam, will be hold in October 22-23, 2009

clip_image002[4]

In the other side, for the French SOA community the demonstration that SOA is alive will be made by the “SOA Forum :

clip_image004[4]

http://www.itnewsinfo.com/invitation/SOA2009/index.html

Mardi 6 October 2009

Paris

For 2nd International SOA Symposium, the topics are very varied: the traditional topics of SOA (Gouvernance, ESB, REST / SOAP, BAM...) and nails, SaaS and PaaS (Google Apps, Azure, ..):

  • Defining Next Generation SO
  • The Reincarnation of SOA
  • SOA as an Architectural Pattern: Best Practices in Software Architecture
  • New Directions in Building Architectures in Support of Business Operations
  • Next Generation Service-Orientation: The Grid, The Cloud, and The Bus
  • Moving from Classic SOA to Next Generation SOA: A Study of Modern Architecture Refactoring
  • Exorcising the Evil SOA: A Necessary Step Towards Next Generation SOA
  • Next Generation SOA Practices and Patterns
  • The Next Generation of Business-Driven SOA: The Convergence of Performance-Driven Business and Service-Orientation
  • Next Generation SOA Security & Governance: New Threats, New Risks, New Opportunities
  • The Critical Role of Architects in an Enterprise SOA
  • The Convergence and Unification of SOA, EDA & BPM: Benefits and Challenges
  • SOA Maturity Models
  • Hacking Services
  • Event-Driven SOA
  • An In-Depth Look at Service-Oriented Modeling and Architecture (SOMA)
  • Service Modeling: Making Sure Your Services Deliver Value
  • Modeling REST Service Capabilities
  • Business Processes and Service Specifications
  • Achieving Process Excellence: Closing the Gap Between Process Analysis, Modelling and Process Orchestration
  • Service-Oriented Business Architecture and Business Model Innovation
  • Results-driven Approach to SOA Adoption: A Roadmap for IT Managers
  • Proving the Business Value of SOA Investments
  • Why Business People & Software Architects / Engineers Don't Understand Each Other and How Enterprise Architects Can Bridge the Gap
  • Value Creation Through Service-Orientation
  • SOA Rollout Strategies
  • The Service-Oriented Architecture Rationalization Framework
  • Mission impossible? Applying Agile to the World of SOA and ERP
  • The Future's In Scope, But Where Do We Start?
  • SOA & Agile Development: A Use Case
  • The Federal Service Bus: A Case Study About Governance
  • A Case Study: Combining Services, Events and Rules
  • The 2nd SOA Project at the Dutch Energy Sector: A Case Study About Learning from the Past
  • The Real Business Case of SOA
  • SOA Meets the Cloud
  • SOA and the Private Enterprise Cloud, a Match Made in Heaven?
  • Enabling Hybrid Enterprise Cloud SOA
  • BI, BPM, and BRM Guide SOA Through The Cloud
  • Securing Cloud-Based Services
  • Integration with the Cloud: Securely Integrating Enterprise Systems with Google Apps
  • Platform as a Service: Application Platform Metamorphosis
  • Calculating ROI for Cloud Computing Projects
  • Journey to the Center of the Cloud: Patterns for Claims-based Identity and Access
  • SOA Governance Touch Points
  • Understanding SOA Governance
  • The Most Important Mistakes You Can Make With SOA Governance
  • SOA Governance and Management Practices
  • Governing REST-Style SOA
  • Understanding SOA Security Patterns
  • How Smart Use Cases Drive Service-Oriented Projects
  • Real-Life Use Cases of SOA Design Patterns at the Dutch Tax and Customs Administration
  • Service-Oriented Solution Evaluation Criteria
  • REST-Inspired SOA Design Patterns (and Anti-Patterns)
  • To ESB or Not to ESB: That is the Question
  • SOA by Mainframe
  • Navigating the Bermuda Triangle
  • Embedded SOA
  • Building the Modern ESB with the Microsoft ESB Toolkit: An Architectural Overview With a Focus on Dynamic Messaging
  • User Interfaces and SOA
  • Jumpstarting SOA Adoption Using Portals: The Vision-In Approach
  • An Insider's Look at BizTalk Server 2009: Integration Server, SOA Foundation, Gateway to Azure
  • The Service Repository, Modern Toy or Critical Governance Tool?
  • Building .NET Services for Collaboration and Composition
  • This is Not a REST Talk
  • Techniques for Composing REST Services
  • Hydras and Hypermedia
  • Introducing Transactions to REST
  • Hypermedia: The Confusing Bit from REST
  • Lessons Learned in the Real World: Priming Services into Production
  • Citizen-Centric Government: A Happy Marriage Between SOA and Semantics
  • U.S. Department of Defense, Office of the Secretary of Defense: An SOA Case Study
  • SOA at the U.S. Joint Forces Command
  • Event-Driven SOA in a Dredging Environment
  • SOA Design Patterns in the Cloud
  • Next Generation Services: The Implications of Software + Services (aka The End of One-Size-Fits-All IT)
  • SOA, Software + Services & Cloud Computing
  • Latency Threatens the SOA Cloud
  • Stratus, Cumulus or Nimbus: What Type of Cloud are You Building?
  • Building a Brokerage Marketplace to Sell services in the Cloud
  • Amazon Web Services: Cloud Computing for the Enterprise
  • Cloud Application Architecture: Rebuilding applications for the cloud
  • Data Analytics in the Cloud

in reference à : 2nd International SOA Symposium - Rotterdam, October 22-23, 2009 (made with the Google Sidewiki)

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

vendredi 25 septembre 2009

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).

clip_image001

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

clip_image003

STORM présente les services fournis :

clip_image004

Choisir un Ville, Tunis par exemple

clip_image005

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

La requête SOAP est la suivante

clip_image006

On peut avoir une vue POXO

clip_image007

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

clip_image009

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

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

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.