[Clous PaaS SaaS] après Force.com et Azure c’est Google App Engine qui s’attaque au problème de solution multi-tenant

Nous observons actuellement une concurrence acharnée entre les offres de PaaS (plateforme as a Servce), de Salesfoce.com, Azure, Google App Engine, jusqu’à la nouvelle offre en préparation de Vmware/Spring.

Mais, la maturité de ce marché passe par la capacité d’offrir en native la prise en charge de de l’aspect multi locataire qui sera à même d’attirer les éditeurs de solution SaaS (Software as a Service) vers ce type de plateforme.

Une application SaaS est dite multitenant, si plusieurs organisations clientes (locataires) peuvent exécuter la même application déployée sur la même infrastructure.

La capacité de proposer une solution basée sur une architecture multi locataire (multi-tenant) est un des éléments fondamentaux de la viabilité économique d’une offre SaaS.

Rappelons que le PaaS Force.com (Salesforce ) est l’un des pionniers de ce domaine et que Microsoft a déjà annoncé que son offre PaaS Azure supporte l’aspect « multitenacy ».

C’est au tour de Google d’annoncer le support de l’aspect « multitenacy », comme l’amélioration majeure apporté par la version 1.3.6 de Google App Engine. La fonctionnalité est disponible pour toutes les API de Google App Engine : Datastore, Memcache, et Task Queues..

Google appengine réalise la ségrégation des applications basée sur un espace de nommage (namespace à la XML) unique affecté à chaque client (organisation). Ainsi, on pourra servir avec la même instance d’application les utilisateurs de plusieurs clients. Chaque client ne voit que sa propre copie personnalisée de l’application.

La bonne nouvelle, pour les développeurs, est que cette amélioration est activé par une simple configuration, aucun changement dans les codes sources n’est nécessaire..

Google app engine, cherche ainsi à séduire les éditeurs désireux de migrer, en mode SaaS, leurs logiciels ou d’en créer de nouveaux.

http://googleappengine.blogspot.com/2010/08/multi-tenancy-support-high-performance_17.html

SOA à l’ENIS : Conférence SOA (Architecture Orientée Services) : démystification"

Ce mercredi 28 avril 2010, à SFAX, j’aurais le plaisir, d’animer une conférence intitulée "SOA (Architecture Orientée Services) : démystification"

la conférence est destinée aux élèves ingénieurs de l’ENIS ‘Ecole Nationale d’ingénieur de Sfax: année terminale, de la spécialité informatique.

Le thème choisit est SOA (Architecture Orientée Services) : Les plus grands éditeurs en parlent, les SSII et les intégrateurs s'y préparent. Tout le monde a quelque chose à dire sur SOA !

L'architecture orientée services concerne tous les acteurs, des Systèmes d'information, des logiciels et des services et entame sa phase de déploiement.

La conférence apportera une vision claire, concrète, et un retour d’expérience du concept SOA : démystifier le concept et préciser la part de la mode (Buzz) dans un domaine que certains n'hésitent pas à le comparer à l'arrivée du client serveur, dans un cycle comme ceux que connaît l'informatique tous les dix ans.

Dans quel contexte et pour servir quels objectifs mettre en œuvre ce type d'architecture ?

Quel est l'éventail des technologies utilisables ?

et plusieurs autres questions, seront posés lors de cette conférence…

SOA (Architectures Orientées Services) ressuscitée selon IDC : Les dépenses SOA vont progresser de +24% entre 2008 et 2013

Les dépenses réalisées sur les architectures orientées services vont progresser de 24%, entre 2008 et 2013. Ce 29 mars 2010, Ruediger Spies, vice-président des applications d'entreprise chez IDC Europe centrale, a déclaré à l'IDC SOA and Beyond Conference 2010 à Londres que la croissance sera principalement dans les Amériques, suivis par l'EMEA.

Ce qui fait que l’originalité de l’ »étude IDC, c’est l’année 2009 avait commencé par une annonce de la mort de SOA.

Mais, ce qui est vraiment Mort c’est les projets SOA de type Big-bang où la « plomberie » (outils et la technologie) est achetée avant toute étude, en espérant un retour sur investissement immédiat.

Rappelons que SOA est une approche d’intégration, privilégiant les aspects métiers et les standards.

Il ne s’agit en aucun cas d’une problématique de technologies pures. La crise financière de 2008, a stoppé les investissements dans la plomberie SOA, mais e besoin réel est toujours d’actualité « ‘aligner le SI sur le métier de l’entreprise »

Nous observons de plus en plus, l’adoption de  démarches pragmatiques de mise en place de SOA au sein des entreprises. Les principales étapes :

1) réaliser une évaluation de maturité

• un positionnement du SI dans un niveau de maturité SOA par rapport aux axes :

  • Organisation,

  • Technologies,

  • Standards

  • Gouvernance

2) Définir une feuille de route pour la montée en maturité sur les différents axes, en impliquant dés le démarrage les équipes métiers

• Plan sur plusieurs années : un projet d’architecture est par définition pluriannuel

3) réaliser un POC (proof of concept) sur certains services

• définir le cycle de vie des services, en impliquant les équipes métiers dans la phase de définition.

• valider les choix techniques

4) réaliser un projet Pilote

• ce qu’on appelle des QuickWin

• mettre en, place la gouvernance

• retenir les leçons

5) généraliser progressivement sous le contrôle des « métiers »

• définir la plateforme cible

• ajuster la feuille de route

• mettre en ouvre la gouvernance.

• renforcer l’architecture d’entreprise …

En résumé : une démarche de construction progressive basée sur une feuille de route visant un niveau de maturité et une architecture cible.

Spring Integration & EIP chez OXIA : présentation pratique par Jonas Partner à OXIA

Dans le cadre des rencontres OAW (OXIA After Work) une présentation technique par un spécialiste de Spring Integration s’est déroulée ce mercredi soir. Elle a été réalisé par Jonas Partner, un Spring Integration committer et Foundateur de OpenCredo.

Notons la présence de Tareq Abderabbou, un Spring Web service Commiter et d‘autres spécialistes Spring de SSII tunisiennes.

Le sujet

Le sujet était : Spring integration, intégration des applications d’entreprise et les design patterns EIP

Lieu de la présentation : Siège de OXIA à Tunis 

Date de la présentation: Mercredi 03/02/2010, de 18H00 à 20H0

L'exposé a permit de présenter l’approche de Spring Integration : un framework d’intégration d’application d’Entrepirse de la famille Spring.

Comme attendu de l’équipe de Spring, Spring Integration permet, très facilement, de mettre en œuvre et de tester les design patterns classiques EIP. c’est le POJO au service de l’EIP.

EP c’est Enterprise Integration Patterns, rendu célèbre par par Gregor Hohpe et Bobby Wolf dans leur fameux livre et disponible sur un site populaire http://www.enterpriseintegrationpatterns.com/

.

Le conférencier est Jonas Partner, un Spring Integration committer et Foundateur de OpenCredo ( qui une SSLL de type Professional Open Source Consultancy en Angleterre)

Présentation de Jonas Partner

Jonas Partner is a Founder at OpenCredo a UK Open Source focused consultancy and Spring Integration committer

Based in Cambridge England,  Jonas directs the technical ambitions and activities of OpenCredo; a company known for its passionate open source experts who provide unbiased consultancy, education and skilled development assistance across a wide and varied range of open source development technologies.

Before co-founding OpenCredo, Jonas amassed his experience within the hot-bed of technology start-ups and established businesses that surround Cambridge.

Jonas has an MSc in Advanced Computing, Machine Learning and Data Mining.

Quelques photos de la rencotre OXIA After Work de mars 2010:

MOM open source : ActiveMQ présente sa version 5.3 avec des nouveautés

MOM open source : ActiveMQ présente sa version 5.3.

Ce MOM (Message Oriented Middleware) open source reste l’un des MOM les plus activées et les plus populaires

ActiveMQ très utilisé par la communauté Java EE. ActiveMQ est écrit en langage java et implémente la spécification du standard JMS (Java Message Service) version 1.1 de Sun Microsystem’s.

ActiveMQ peut être déployé sur n’importe quel système OS (Windows, UNIX et Linux) compatible avec Java Virtual Machine (>= JDK 1.5).

Rappelons que les principaux composants de ActiveMQ sont :

· Client : application utilisant les services fournit par le broker. Un client peut être producteur ou consommateur de messages.

· Destination : Peut être considérée comme un canal logique permettant ainsi aux clients de communiquer entre eux. Une destination peut être queue (Point à Point) ou topic (publish & Subcribe).

· Message Broker : Responsable d’acheminer les messages vers les destinations demandées. Il permet aussi d’assurer une qualité de services adéquate liée à la persistance, intégrité, sécurité et la disponibilité.

Respect du protocole AMQP

En plus des protocoles classiques des MOM, ActiveMQ implémente, et y ajoute le protocole AMQP (Advanced Message Queuing Protocol).

AMQP est un nouveau protocole pour les systèmes de messagerie orientés Middleware à comparer au protocole SMTP (pour les gestionnaires des emails). L'objectif d'AMQP est de standardiser l'échange de messages entre serveurs de message

Les principales nouveautés de la version 5.3 d’ActiveMQ sont ;

• Une nouvelle base de données pour le stockage des messages persisant ( KahaDB)
• Une meilleur qualité de la console web
• Le support du protocole stomp sous SSL et le support de NIO
• Des améliorations de la configuration plus orienté production
• Ouverture vers d’autres le langage que java pour les demandes de statistiques par un simple envoi de message
• Le support du protocole FTP pour les messages blob

lien étroit avec Camel d’Apache

Signalons en plus, que la version 5.3 d’ActiveMQ propose un lien plus important avec le projet EIP de Apache Camel 2.0.0

Mais ceci est un autre sujet.

------------------------------------

autres sujets sur les MOM et ActiveMQ

Cloud et MOM open source : Jboss HornetQ le Middlewares Orientés Messages de Redhat vise le PaaS

Les projets d’intégration et rôle de l’ESB, dans un Système d’information

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)

Mule lance iBeans : intégration simplifiée à partir des applications web

La naissance de iBeans

Aujourd’hui 22 septembre 2009, MuleSoft vient de lancer un nouveau projet : iBeans (pour integration Beans)

Le produit a pour objectif de simplifier au minimum l’intégration d’une application web avec le reste du SI.

L’idée est de permettre d’utiliser des outils d’intégration, directement dans des applications web, en quelques minutes.

Rendre l’utilisation de la plateforme de Mule aussi simple que l’ajout d’une annotation à une classe java.

Exemple d’utilisation de iBeans

Par exemple pour ajouter l’action d’envoi d’un message à la fin de la méthode bonjour(..)

· Ajouter une annotation @Send (spécifique à iBeans)

@Send(uri = "smtp://oxia@net-progress?to=khaled.bendriss@gmail.com")

public String bonjour(String name)

{

.ou bien

· Ajouter cette ligne à la fin de la méthode

...

ibeans.send("smtp://oxia@net-progress?to=khaled.bendriss@gmail.com ")

Cibles de iBeans

iBeans est un ensemble de composants d’intégration réutilisables (l’ajout d’un nouveau composant se fait en quelques minutes).

Les Développeurs d’applications web utilisant iBeans peuvent se connecter à d’autre applications et des sources de données externes, via Web Services, flux RSS, service RESTful, événements AJAX, JMS, ..

Pour le moment, iBeans est taillé pour Tomcat 6 (et vient package avec Tcat de MuleSoft), les exemples fournit permettent déjà d’interroger son status sur twitter ou d’envoyer des photos vers flickr.

La cible est bien sûre l’intégration avec les applications SaaS et les applications de social networking, Twitter , Flickr ,Facebook, SalesForce , Jabber ,Amazon S3 , GMail client for sending and receiving email

Est-ce que c’est les prémisses d’une offre Cloud de MuleSoft ?

Pourquoi pas ?

Mais ceci est un autre sujet

Mule ESB 2.x est il un ESB?

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

Mulesource vient d’annoncer une version Tomcat packagé et optimisé pour son ESB, le fameux Mule ESB. Cette annonce vient, alors que la version 3.0 de Mule ESB est en préparation et que Spring affute ses armes pour imposer Spring Integration comme un ESB.

Mais, dans ce contexte, la question qui m’est toujours posé, est la suivante : « Mule ESB 2.x est il un ESB »

Pour répondre à cette question, en 2009, année où à son début un « génie du Buzz » a prédit la mort de SOA et de toute le quincaillerie qui va avec, il faut revenir sur la définition même de ESB : qu’est ce qu’un Enterprise Service Bus.

Ce qu’est un ESB

L’ESB (Enterprise Service Bus), un terme de plus en plus utilisé dans le monde des S.I. (Système d’information),

Selon google Trends, les recherches sur le Enterprise Service Bus est en chute libre!

ESB désigne tout et n’importe.

Un mot marketé par les grands fournisseurs pour vendre la « plomberie » nécessaire pour intégrer un S.I. (Système d’information), après les échecs successifs de dizaines de projet EAI à atteindre leurs objectifs de fluidifier le S.I. (Système d’information). Ces grands fournisseurs vendaient des EAI comme le miracle d’intégration par la souris : il suffit d’utiliser l’éditeur, le designer, le mappeur et voilà votre S.I. (Système d’information) est « Agile ».

Il fallait un autre nom, l’outil EAI est mort, vive l’ESB.

Et on continue à faire les mêmes erreurs …

L’ESB est souvent associé à SOA (Service Oriented Architecture), pas toujours pour les mêmes raisons, mais souvent d’un façon abusive.

Un projet SOA est souvent assimilé à l’acquisition d’une infrastructure d’intégration, labellisé par le fournisseur ESB.

Comment faire pour que des programmes, des applications et des systèmes séparés puissant collaborer ensemble sans les remettre à plat : l’intégration d’application d’entreprise avec des ESB

L’usage d’un EBS n’est pas nécessaire, mais facilite bien les choses

Rôle d’un ESB

L’ESB (Enterprise Service Bus) est souvent utilisé pour designer l'infrastructure informatique supportant une architecture SOA et l’intégration d’application d’entreprise (EAI), afin de réaliser, simplement, par configuration les fonctions suivantes :

· Routage

· Transformation de Message

· Enrichissement de Message

· Transformation entre Protocole de Transport

· Mapping entre services

· Traitement des Messages

· Chorégraphie entre processus

· Orchestration entre service pour créer un Processus

· Gestion de Transaction

· Sécurité

Pour simplifier, les outils EAI des années 90 avaient les mêmes objectifs, sauf qu’ils était basés sur des protococcales standards et fermé. L’ESB leurs emboitent le pas des EAI, mais en proposant des connecteurs standards et en se basant sur des normes libres.

Ceci explique la montée en puissance des ESB open sources et la presque absence d’EAI open source

L’open source prolifère, et s’impose, lorsque les protocoles sont libres d’usage, et lorsque la concurrence n’est pas biaisée.

En assurant la connexion et la médiation de l'ensemble des applications et services de l’entreprise, l’ESB facilite l’intégration au sein du SI (Systèmpe d’information) et prépare le terrain pour le suivi et le monitoring (BAM Business Activity Monitoring et SAM Service Activity Monitoring).

Dans le cas où la démarche suivi pour définir les points d’intégration est basée sur une approche SOA, le BUS d’entreprise, ESB est au service de SOA.

Mais lorsque la démarche est hasardeuse et de type Spaghetti Oriented Architectre, l’ESB est au service du principe GIGO (Gabrage In Garbage Out)

L’ESB est important dans la mise en œuvre d’une démarche SOA qu’elle soit de façade ou de fond, qu »elle soit ponctuelle ou durable.

Ce constat a fait du tord à SOA, il a été interprété au premier degré : « il faut acquérir un ESB commerciale pour faire du SOA »

NON, pas forcément

Et surtout pas au début, lors des POCs et des projets Pilotes.

Ce qui rend SOA puissant comme démarche, c’est l’implication des métiers et l’approche service (métier) et ce n’est pas l’achat d’un outil (même s’il s’appelle ESB ).

C’est de là que vient « l’intérêt » porté à un ESB open source, comme MULE ESB

Mule ESB est il un ESB

Dans la définition commune de l’ESB : on peut dire oui

Mule ESB répond à la définition communément utilisé pour ESB, son point faible (qui est celui de la majorité des outils open source) c’est la faiblesse des outils graphiques et l’omiprésence des fichiers XML.

A propos du XML de configuration, la version 2.x, a réussi l’arrimage à la config Spring et a capté beaucoup d’adepte du Ioc favori de la communauté java EE.

Mais Mule est plus qu’un ESB

Mule peut jouer pleinement son rôle indépendamment de SOA

Comme tout ESB, utiliser Mule ne garantie pas que la démarche est bien SOA.

Le point fort de Mule ESB est son architecture interne, basée sur l’approche SEDA (Staged Event-Driven Architecture). Mule peut envoyer et recevoir des messages en utilisant les modèles : asynchrone, synchrone et requête/réponse.

Mule fournit un container de services qui peuvent être routés via différents transports tels que JMS, SMTP, JDBC, TCP, http, fichier...

Ainsi, l’usage de Mule comme outil d’intégration peut être aussi envisagé, indépendamment de l’approche SOA.

Mule peut être aussi l’infrastructure de base pour la mise en place d’une approche CEP (Complexe Event Processing)

La concurrence open source

Les ESB doivent par exemple proposer des solutions pour les standards suivants :

EJB; E-mail; File; FTP; HTTP; IMAP; JDBC; JMS; POP3; Quartz; RMI; Servlet; SMTP; SOAP; SSL; Stream; TCP; UDP; WSDL; XMPP

Les ESB open Source

Les concurrents open source de Mule ESB:

· FUSE ESB acheté par Progress Software ( après son acquisition par IONA) ESB basé sur Apache ServiceMix & celtix · Apache ServiceMix : ESB implémentant le standard JBI · PEtALS ESB implemantant le standard JBI du consortium OW2 (exe ObjectWeb) · Sopera (Eclipse SOA) : le projet officeille de la foindation Eclipse. Un projet à suivre ! il s’agit d’une nouvelle initiative pour créer un écosystème SOA autour d’Eclipse : ESB, outils, registry, BAM , SAM, intégration de données ; gestion … · JBoss ESB : redHAT en réponse à Microsoft ou IBM … se doit d’avoir une ESB · Sun OpenESB ESB implémentant le standard JBI offert par (mais va t il rester en vie?) · WSO2 ESB ESB du consortium WS02, base sur Apache Synapse · ChainBuilder ESB ESB implémentant le standard JBI · Jeeesb un ESB hébergé par java.net

Autres usages possible pour Mule

Mule est souvent utilisée comme l’infrastructure de base pour la mise en place d’une approche EDA (Event Driven Architecure).

Mule peut être aussi l’infrastructure de base pour la mise en place d’une approche CEP (Complexe Event Processing)

Mais ceci est un autre sujet

Les projets d’intégration et rôle de l’ESB, dans un Système d’information

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

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

Il est communément connu que la majorité des S.I. (Système d’information) dans les entreprises soufrent d’un manque d’intégration et se trouvent souvent au stade d’ilots, dont les parties interconnectés soufrent du syndrome spaghetti (dite Spaghetti Oriented Architecture).

L’intégration coûte chère à l’entreprise : on parle de 70% du budget IT, ce qui laisse peu “de budget” pour les nouveaux projets et explique la longévité de certaines applications, bien qu’elles soient non adaptées.

Le S.I. (Système d’information) de toute entreprise a besoin d’une intégration entre ses applications et service, pour adresser les enjeux suivants :

• interopérabilité native et organisation efficace de la circulation de l'information entre des applications hétérogènes,
• communication fluide entre les différentes applications de l'entreprise, voire même celles des partenaires (clients, fournisseurs, sous-traitants, cotraitants, …) >

D’où le besoin de rationaliser le projet intégration entre ses applications et services d l’entreprise (dit EAI Enterprise Application intégration, à l’époque le mot service n’avait la notion se Service métier, on parle de EAI et non pas de SEAI, pour dire SOA aujourd’hui).

Un projet intégration entre ses applications et services d l’entreprise consiste :

• à mettre en place une architecture de communication entre les différentes applications, e services

• à développer des connecteurs et services (avec ou sans middleware, appelé avant outil EAI et ESB maintenant) permettant d'interfacer des applications utilisant des protocoles de communications différents,

• Au-delà de l'interopérabilité entre applications, l‘intégration doit, permettre de définir un Workflow entre applications (existantes et futures).

Rappelons que la finalité d’un projet d’intégration est de "fluidifier, simplifier et structurer" les échanges entre applications.

Le mot EAI (Enterprise Application Integration) souvent utilisé souvent remplacé par SOA (Service Orientéed Architecure), rappelons que …

• SOA est un concept
• Bus est une architecture logique
• ESB est un produit

Les types d’intégration

En complexité croissante, les différents types d’intégration qu’on rencontre sont :

· Intégration par les données :

• transmission de données avec des transformations éventuelles d’une source à une destination
• le scénario le plus classique est l’échange et le partage des données applicatives via base de données commune
• l’usage de XML (Extensible Markup Language) est particulièrement utile pour l'intégration applicative inter-entreprise,

· Intégration parles applications :

L’utilisation d’API métier pour transférer ou intégrer des flux de données

Basée sur des apples points à points ou sur des logiciels d’intégration (solution EAI plus complète), sans ou avec produits de middleware orientés messages (MOM)

· Intégration par les processus

• Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine

Un projet d’intégration peut combiner ces trois approches, mais le rêve de tout DSI (Directeur de Système d’information) est de mettre en place une approche d’intégration par les processus.

Intégration par les données :

Lorsque les applications n’ont pas la possibilité de lire et de traiter les données provenant d’une autre application, un ESB (Mule par exemple) résout le problème en fournissant un framework de messagerie qui lit, transforme, et envoie les données comme des messages entre les applications.

(source mule.org)

L’ESB en tant qu’outil d’intégration par les données propose :

• · des services de transformation de données,

• · la mise à disposition des données vers une ou plusieurs cibles

• · la sécurisation et la fiabilisation des échanges,

• · l’utilisation de connecteurs standards d'accès aux sources de données,

Cette approche n’a de sens que dans une phase d’urgence (certains vont se dire, c’est toujours le cas).

Notons que le principal point négatif de cette approche est que la couche métier est court-circuité et les règles de gestion (règles métiers) ne sont pas vérifiées dans les transferts ou bien doivent être réécrites dans le connecteurs .

Exemple : base de données avec données stockées incluant des règles de gestion (appartenance à un type pu une catégorie…).

L’intégration au niveau données ne tient pas compte de cette couche et se connecte directement à la base de donnée avec le risque d’atteinte d’intégrité des données (d’un point de vue métier).

Intégration par les API :

L’intégration au niveau des applications consiste à utiliser les API métier pour faire communiquer deux applications une dite consommateur et l’autre fournisseur.

Il est important que l’application fournisseur expose ses fonctionnalités sous forme d’une API. L’idéal serait que cette API soit définit d’un point de vue métier et que l’exposition soit basé sur des standards

· L’intégration au niveau des applications est un bon départ en vue d’une exposition des API métier sous forme de Web Services

· Mais l’intégration de la couche métier n'est pas toujours aisée :

• La majorité des applications ne fournissent pas des API métier, puisqu’elle ont été pensé en terme de silos ou monoblocs.

• o les applications anciennes des environnements centralisés sont souvent des blocs monolithiques sans notion de couche, leurs seules interfaces sont constituées de grilles d'écran,

• o l’exposition risque de déclencher un important travail de restructuration, en préalable à toute intégration d’applications,

· La couche de présentation gère l’interface utilisateur, cette couche peut constituer un point d'intégration potentiel (intégration au niveau «écran») en se basant sur les Mashup.

· Dans certains cas où une API métier est disponible, il n’est pas toujours possible de l’exploiter directement tel quel :

• o protocoles de communication propriétaires, nécessite la création d'une surcouche d'adaptation, c’est le principe de Proxy ou d’adapter (utilisé dans SOA de façade)

· Stabilité des API applicatifs dans le temps: approche Contract-First

• o L’API est le point d'entrée de l'intégration,

• o une modification interne dans une application ne doit, théoriquement pas, entraîner une modification de l’API métier,

Intégration par les processus

Intégrations au niveau données et applications focalisées sur aspects techniques de l'intégration,

Intégration au niveau des processus métier prône une approche fonctionnelle de l’intégration d’applications,

Ce sont les processus métier qui pilotent l’intégration.

Le Business Process Integration (dit BPI) , est le fait de concevoir des processus métier et de les relier aisément aux applications sous-jacentes,

Les produits de BPI utilise se base sur un moteur d'orchestration (moteur BPM) connaissant les étapes et les données du processus.

Le moteur BPM se charge

• · de l'aiguillage des flux de données dans le cadre des processus métier,

• · du suivi de l'état d'avancement de chaque processus,

• · d’activer des alertes en cas de déviation du fonctionnement

Le moteur BPM doit proposer :

• · un support natif de certains processus classiques (briques élémentaires prédéfinies et configurables),

• · un formalisme claire (standard de préférence, privilégier le BPMN pour les nouveaux projets) pour définir le processus métier sous forme de combinaison de plusieurs briques métier,

• · un outil de modélisation graphique,

· sur cette base, le moteur BPM se charge :

• o de générer automatiquement le code nécessaire aux interactions entre les actions élémentaires,

• o et de donner les instructions au moteur pour exécuter les processus définis.

Un ESB au service de l’intégration

En conclusion, l’ESB peut jour un rôle important dans un projet d’intégration.

Il n’est pas indispensable

Il ne doit pas être forcément cher à acquérir.

C’est une commodité.

Un ESB doit permettre de mettre en ouvre ces 3 types d’intégration, simplement, par configuration les fonctions suivantes :

· Routage

· Transformation de Message

· Enrichissement de Message

· Transformation entre Protocole de Transport

· Mapping entre services

· Traitement des Messages

· Chorégraphie entre processus

· Orchestration entre service pour créer un Processus

· Gestion de Transaction

· Sécurité

dans ce cadre Mule ESB a un rôle à jouer dans l’intégration de votre SI, notamment pour les POC et les projets Pilotes

mais ceci est un autre sujet

---------------------

autres sujets :

Fonctionnalités des ESB et offre open source : le marché n’est pas encore consolidé

Cloud computing : SQL Azure est annoncé, vers le "Cloud data management"

La réponse au BigTable de Google est là : Microsoft distille la riposte et elle est de taille

On peut résumer l’approche : «Conserver vos habitudes SQL avec SQL Azure, le « SQLServer du Cloud de Microsoft ».

Rappelons que Windows Azure est l'offre "Cloud Computing" de Microsoft. Il s’agit d’une offre "Platform as a Service" (PaaS). Une sorte de système d'exploitation pour le cloud.

Pour l’instant, la plateforme Azure comprend trois parties : Windows Azure, SQL Azure et .NET Services.

SQL Azure : c’est quoi ?

SQL Azure (anciennement SQL Data Services) correspond à une base de données relationnelle “on the cloud” de la plateforme Azure. Il parait qu’elle repose sur SQL Server.

Ce module est différent des services de stockage non-relationnels fournis par la brique Windows Azure (Tables, Blobs, Queues), conçus pour les besoins de mise à l’échelle extrêmes de certains scénarios pour le “Cloud”.

SQL Azure s’oriente, dans sa première version, vers le supporte d’un sous ensemble de TSQL langue, contrairement à SDS qui lançait un nouveau paradigme nommé ACE (Authority, Container, Entity).

Chaque ordre TSQL peut être classés dans les l’un des 3 niveaux :

• Pris en charge (supporté) : dans ce contexte signifie qu'il n'ya pas de différence dans la façon dont traite SDS une déclaration ou d'une fonction par rapport à SQL
• partiellement supporté
• non supporté signifie que la caractéristique donnée n'est pas prise en charge par la SDS (exemple l’ordre BACKUP ne sera pas disponible)

A ce stade aucun ordre SQL nouveau n’est prévu.

Selon MSDN (le blog : TSQL Support in SQL Data Services) les principales limitations sont:

• Pas de possibilité d’accéder ou de manipuler les ressources physiques.
• Certaines fonctionnalités ne seront pas accessibles comme par exemple la réplication.
• SQL Profile ne sera pas non plus disponible

Il semble que Microsoft, cherche à faciliter le portage d’applications, plus besoin de redévelopper la couche données pour une application utilisant SQL Server.

Offre de prix

Rien n’est gratuit :

Contraient à l’approche Google, qui offre un quotas gratuit, la payement commence dés le premier octet de stockage et dès la première requête.

Le modèle de facturation est basé sur l’usage, une combinaison entre le volume de donnes et les nombre de requête

-Web Edition = $9.99 / mois, limité à 1 BD de 1 Go de stockage et 10 heures d’exécution de requêtes

-Business Edition = $99.99 / mois, limité à 1 BD de 10 Go de stockage et 100 heures d’exécution de requêtes

-Bande passante = $0.10 / Go en entrée,  $0.15 / Go en sortie

Ce qui est intéressant c’est que Microsoft s’engage sur un SLA (Service Level Agreement) de 3 neufs (99.9%) pour SQL Azure..

La question qui demeure : “à ce stade, faut continuer à investir sur l’apprentissage de Azure, ou bien attendre un peu que se “tout cela “ se stabilise ?”

Mais ceci est un autre sujet

Terracotta achète Ehcache: la concentration des projets open source s’accélère

Il y a quelques jours on a vue l’acquisition de Spring par Vmware, hier, 18 août 2009, c’est autour d’ EhCache de se faire « absorber » par Terracotta.

Ehcache une API de gestion de cache de donnée, est le projet open source le plus populaire dans la spécialité. EhCache est très connue par la communauté Java EE et spécialement par les utilisateurs de Hibernate et Spring.

Terracotta est une entreprise qui propose des solutions de clustering de JVM pour adresser les problématiques de haute disponibilité et de partage d’instance d’objets entre plusieurs JVM.

En quelques sortes Terracotta offre à l’application une mémoire distribuée sur toutes les JVM connectées (concept de Network Attach Memory).

Dans le mode open source Terracotta est en concurrence directe avec RedHat (JBoss Infinispan : open source Data Grid par la JBOSS).

Mais, la véritable concurrence vient des entreprises à code fermé, Oracle (Coherence) et GigaSpaces, et GemStone Systems.

Les deux sociétés sont issues du monde open source. Bien que techniquement logique, Il est probable que cet achat ne soit le prélude d’une préparation de la société à une vente.

Rappelons, que les deux solutions, Terracotta et ehcahe, s’intègrent parfaitement à Spring. Ça pourrait donner des idées à Vmware.

Mais ceci est un autre sujet

Tomcat, Spring, Grails, Groovy : dans le giron de Vmware

10 août 2009 : Un jour d’été pas comme les autres, une montée fulgurante d’une société, crée il y a 5 ans sur la base du consulting autour d’un framework Ioc, pour devenir la référence d’une communauté java toujours en quête d’évolution.

Aujourd’hui 10 août 2009 Vmware le leader incontesté de la vritualisation a annoncé l’acquisition de springSource le leader incontesté de la voie alternative de la communauté Java, du Server Side et java Software

Rappelons les grandes dates pour Spring :

novembre 2002: Rod Johnson publie son réquisitoire contre la voie officielle de J2EE : “J2EE Design and Development”

février 2003: Lancement d’un IOC en open source ‘Spring le Framework’
Juillet 2004: Lancement de SpringSource ‘Spring l’entrerpise’

janvier 2008: Acquisition par SpringSource de Covalent Technologies ( Apache java Software Foundation projects, Tomcat, Axis …)

novembre 2008: Acquisition par SpringSource de G2One : Groovy and Grails.

mai 2009: Acquisition par SpringSource der Hyperic (monitoring de système).

Le but ultime de ce mariage, reste à mon avis, la préparation de prochaine bataille de l’IT: celle du cloud computing ( Qu’il s’agisse de Cloud privé ou public).

Rappelons que les offres cloud de Microsoft et de Google menacent directement le modèle &économique de VMware : Les deux Big Brothers offrent des infrastructures vitalisées par essence. Les offres cloud de Microsoft et de Google parlent en plus directement aux développeurs : .Net C# ou Java, conserver vos habitudes, programmez simplement et déployer facilement. Chère développeur Azure ou Google Appengine : des Vmware ou des Framework (Spring compris…) il n’y guère besoin, le cloud est là pour simplifier votre travaille. ….

Il s’agit donc, d’un autre mariage de raison, entre deux leaders préparant leurs avenirs :

Vmware est focalisée sur la simplification et l’automatisation des infrastructures pour les applications et Spring est focalisée sur la simplification et l’automatisation du développement des applications.

Pour le monde java, c’est une bonne nouvelle si ça aboutit à une vraie simplification des modèles de développement, déploiement et monitoring.

Restons vigilant sur l’ouverture du code de Tomcat, Spring, Grails et Groovy …

d’autre part, VMware, doit batailler pour s’imposer dans le monde des clouds privées ou va t’elle fusionner avec Amazon ?

Mais ceci est une autre histoire

news : http://blog.springsource.com/2009/08/10/springsource-chapter-two/

http://www.marketwatch.com/story/vmware-to-acquire-privately-held-springsource-2009-08-10

http://www.infoq.com/news/2009/08/vmware-springsource

http://www.marketwire.com/press-release/Vmware-Inc-NYSE-VMW-1028298.html

Grails, Groovy, xFire & SoapUI : créer un web service et le tester en 22 lignes de codes, 7 commandes et 5 minutes

Préambule : Avant de commencer, s’agissant de publier des services, je rappelle que je reste adepte du concept Contrat-first. Mais, ce tutoriel est destiné à montrer la puissance de l’approche Grails. Il doit être affiné pour suivre l’approche contract-first. Qu'il s'agisse d'une solution java développée 'from scratch' ou basée sur du 'java software' payé en $$ ou sur du .net basée sur Biztalk : l'essentiel c'est que le contrat soit défini dès le début

Question : comment créer un web service en exposant la liste à partir d’une base de données

Contexte : confronté, sur un nouveau projet, à une demande du client qui souhaite rapidement : apprendre à consommer des web services, dans un projet classique JSF/Spring/Hibernate . L’idée est d’utiliser Spring webservice template, mais, Il a fallu fournir des web services rapidement, pour les consommer

Réponse : le simple c’est d’utiliser Grails (yes it's a java software from Spring cretors, based on Groovy : a dynamique java software from the Spring source ...)

Des webservices en moins de 5 minutes, 6 commandes et 22 lignes de codes …

En prime : les écrans de gestion de l’entité cible dans la base de donnée

Etape 1: installer Grails

http://www.objis.com/formation-java/tutoriel-grails-installation.html

Etape 2 : créer une application

(Commande 1)>grails create-app webservice-xfire

(Commande 2)>cd webservice-xfire

(Commande 3)>grails create-domain-class com.oxia.att.grails.Role

Ajouter ce code (en somme du Plain old Groovy objects, dit POGO)

1:  package com.oxia.att.grails
2:  class Role {
3:       String name
4:       static constraints = {
5:            name(blank: false, size: 1..20)
6:       }
7:       public String toString() {
8:            return name
9:       }
10:  }

(commande 4)>grails create-controller com.oxia.att.grails.Role

Etape 2 : installer le plugin xFire

http://www.grails.org/plugin/xfire

(commande 5)> grails install-plugin xfire

Etape 3 : générer les bases du service en relation avec le POGO Role

(commande 6)> grails create-service com.oxia.att.grails.Role

Etape 4 : ajouter un peu de code Groovy pour exposer le métier

1:  class RoleService {
2:        static expose=['xfire']
3:     def serviceMethod(Role dc) {
4:          return true
5:     }
6:     Role[] getRoles(){ Role.list() as Role[] }
7:  }

Etape 5 : lancer

(commande 7)> grails run-app
http://localhost:8080/webservice-xfire/services/role?wsdl
Avant de tester le web service : ajouter au moins 1 Role (le fameux admin…) ( les écrans d’administration ont été générés aussi)

Etape 6 : tester avec SoapUI

Créer un projet avec SOAP UT à partir du WSDL

SOAPUI va créer ce projet

Lancer le teste

Le résultat n’est pas « orienté » Contrat-first

Mais … avec du XPATH on pourra se débrouiller !

Avouons qu’il faut travailler encore le CONTRAT

Etape 7: statistique

Code utile : 22 lignes de codes (les tests unitaires sont aussi utiles mains non comptabilisées dans ce cas)

 +----------------------+-------+-------+
| Name         | Files | LOC |
+----------------------+-------+-------+
| Controllers     |   1 |   4 |
| Domain Classes    |   1 |  10 |
| Services       |   1 |   8 |
| Unit Tests      |   3 |  36 |
+----------------------+-------+-------+
| Totals        |   6 |  58 |

( sans formatage de texte )

Etape 8 : consommer le service

Utiliser Spring Web service template

Mais, ceci est un autre sujet

--------------------------------------------------

autres sujets Grails

-- Groovy & Grails : L’instabilité en vue du coté JRuby, une opportunité de plus pour Groovy & Grails

-- Groovy et Grails dans le giron de SpringSource : Un bel avenir pour les langage dynamique
--------------------------------------------------

autres sujets à venir

- le concept Java 3G : Grails, Groovy et Google appengine

- les plugins Grails

Twitter, Faut il envisager la vie sans : Twitter a subit sa première cyber-attaque

Twitter touché par un déni de service attaque DDOS : la nouvelle paru dans CNN il y a à peine quelques heures (CNN.com et reteurs ) , ce jeudi 06 juillet 2009.

L’attaque, coordonnée, sur Twitter a causé la fermeture du site de réseautage social, dit de microbloging, pour au moins deux heures.

En théorie cette attaque de twitter.com devrait, perturber uniquement les twitteurs.

Le principale problème, dans cette histoire, est que la panique généralisée a touché essentiellement les faceboukeurs dépendant (remarquons qu’avec l’addiction, il faut faire attention à la coupure brutale et envisager servage lors de toute thérapie …),

Trois points sont à retenir :

1. Twitter devient le talon d’Achille du réseautage social : La panique n’a pas touché seulement, les utilisateurs directs de Twitter, mais les utilisateurs des autres sites liés et référent twitter (un nombre croissant d’applications ping Twitter pour des infos). Ce type d‘attaque est accentué par les utilisateurs de twitter eux-mêmes qui en paniquant envoient plus de

http://lonewolflibrarian.files.wordpress.com/2009/05/twitterverse.jpg

( selon Lone Wolf Librarian)

2. Un site dépendant des services de twitter, comme FaceBook, doit être conçue en envisageant la vie sans : La place que prend twitter dans le paysage du réseautage social, devient de plus en plus handicapante pour les sites liés, lorsque l’architecte n’a pas envisagé quoi faire lorsque twitter est HS (hors service)

3. les infrastructures de twitter ont montré leur fragilité, twitter gagnerait à les renforcer en attendant de trouver le bon modèle économique pour les rentabiliser ...

Cette attaque sur twitter, n’est peut être qu’un exercice militaire, la suite cette été, comme ce qu’a subi l’Estonie, été 2007

Mais ceci est un autre histoire suivre, …

pour plus d’info

http://www.stumbleupon.com/s/#2IQI48/mashable.com/2009/08/06/twitter-outage//

http://www.stumbleupon.com/s/#2IQI48/mashable.com/2009/08/06/twitter-outage//

http://edition.cnn.com/2009/TECH/08/06/twitter.attack/index.html

http://www.reuters.com/article/rbssITServicesConsulting/idUSN0612153720090806

Fonctionnalités des ESB et offre open source : le marché n’est pas encore consolidé

Besoin pour un ESB

La technologie elle-même n’apporte pas de valeur. La valeur est obtenue lorsqu’on combine la technologie avec une nouvelle façon de faire les choses : une vision métier du SI, focalisé sur les services à valeur ajoutés est à même de produire la différence dans l’utilisé Business de votre SI.

Comment faire pour que des programmes, des applications et des systèmes séparés puissant collaborer ensemble, pour supporter une vision métier du SI, sans tout remettre à plat :

• Vous souhaitez intégrer plus de 3 applications ou de 4 services
• Vous utilisez plus qu’un protocole de transport (http, jms, jdbc ..)
• Vous avez un besoin de routage en fonction du contenu
• Vous avez plusieurs applications consomment le même message

Alors, vous pouvez penser à l’intégration d’application d’entreprise avec des ESB.

Dans ce contexte, les ESB ont un rôle à jour,

L’usage d’un EBS n’est pas nécessaire, mais facilite bien les choses

Un ESB doit permettre de réaliser, simplement, par configuration les fonctions suivantes :

· Routage

· Transformation de Message

· Enrichissement de Message

· Transformation entre Protocole de Transport

· Mapping entre services

· Traitement des Messages

· Chorégraphie entre processus

· Orchestration entre service pour créer un Processus

· Gestion de Transaction

· Sécurité

Les ESb doivent par exemple proposer des solutions pour les standards suivants :

EJB; E-mail; File; FTP; HTTP; IMAP; JDBC; JMS; POP3; Quartz; RMI; Servlet; SMTP; SOAP; SSL; Stream; TCP; UDP; WSDL; XMPP

ESB open source : l’offre?

Les fournisseurs classiques des outils EAI ont re-packagés leurs solutions et renommées EBS (genre de revamping produit)

De l’autre coté, l’offre d’ESB open source est pléthorique :

· Mule l’ESB open source le plus populaire · FUSE ESB acheté par Progress Software ( après son acquisition par IONA) ESB basé sur Apache ServiceMix & celtix · Apache ServiceMix : ESB implémentant le standard JBI · PEtALS ESB implemantant le standard JBI du consortium OW2 (exe ObjectWeb) · Sopera (Eclipse SOA) : le projet officeille de la foindation Eclipse. Un projet à suivre ! il s’agit d’une nouvelle initiative pour créer un écosystème SOA autour d’Eclipse : ESB, outils, registry, BAM , SAM, intégration de données ; gestion … · JBoss ESB : redHAT en réponse à Microsoft ou IBM … se doit d’avoir une ESB · Sun OpenESB ESB implémentant le standard JBI offert par (mais va t il rester en vie?) · WSO2 ESB ESB du consortium WS02, base sur Apache Synapse · ChainBuilder ESB ESB implémentant le standard JBI · Jeeesb un ESB hébergé par java.net

Les offres assimilées à des EBS open source

· Spring Integration le premier pas de SpringSource dans le monde des ESB, la suite de la saga ESB de Spring est à suivre … · Apache Synapse ESB focalisé sur les services support ( basée sur Apache Axis2) · Apache CXF : se définit comme « un open source service framework » · Celtix: initialement lancé par objectweb, en 2006, le projet a migré vers Apache pour devenir le projet CXF, et la version entreprise n’est autre que FUSE Services Framework, de IONA (de Progress Software) faisant partie de l’offre open source FUSE de IONA. · OpenAdapter un produit EAI-qui se rapproche des fonctionnalités es ESB

Finalement, signalons un projet intéressant, presque un ESB,

· Apache Tuscany Implémentation de la spécification SCA

un conseil simple : rester indépendant de l’ESB

Ce nombre croissant d’ESB open source indique que le marché n’est pas encore stabilisé (au sens consolidation) et continue à croitre.

Il est extremement important de rester indépendant de l’ESB :

séparer votre code métier de l’application de ESB (utiliser systématiquement un Ioc, Spring de préférence).

La meilleure solution, pour aider le marché à converger, et consolider toute cette offre disparate, c’est qu’elle unissent leurs efforts autour d’Eclipse SOA (ex SOPERA).

.

L’essentiel : faire le bon choix et privilégier les standards.

Mais avec Quels critères, Quel outil? Quels risques ?

Mais ceci est un autre sujet ...

autres sujets sur Mule

Mule ESB : le routeur outbound-pass-through-router a changé de nom entre la version 2.0 et 2.1 ..

Fonctionnalités des ESB et offre open source : le marché n’est pas encore consolidé

http://net-progress.blogspot.com/2009/07/mule-version-2x-jms-comment-enlever-les.html