[Cloud PaaS] SpringSource continue à consolider son offre pour le cloud avec Spring GemFire

Spring source vient d’annoncer la release de la version 1.0.0M1 de Spring GemFire. Cette offre permet de mettre à la disposition des utilisateurs de GemFire (de GemStone qui fait partie du groupe Vmware ) les concepts et le model de programmation de SpringFramework.

GemFire s’inscrit dans le domaine de cache distribué (Distributed Cache) pour les données applicatives. Un cache distribué offre un système de cache de données permettant d’accélérer les performances des applications web de grandes tailles.

L’offre Spring GemFire cible essentiellement les applications déployées dans un cloud. Elle présente cette offre comme «Spring GemFire : Elastic Data Management for Enterprise & Cloud Applications ».

Cette offre vient quelques semaines après l’acquisition par SpringSource de RabbitMQ (Open Source Messaging Optimized for the Cloud) . RabbitMQ une implémentation open source du protocole AMQP et montre que SpringSource est entrain de dérouler une feuille de route pour son offre Cloud/PaaS.

Rappelons qu’en plus de Gemstone Gemfire, les autres offres de cache distribué pour le Cloud computing (Distributed Cache for cloud coumputing) sont :

• ehcache (open source, propriété de Terracotta)
• Infinispan (open source, propriété de RedHat – Jboss)
• memcached (open source, utilisé par Google App Engine, Facebook, twitter, YouTube, Flickr…)
• Terracotta for Web Sessions
• Gigaspaces
• IBM Webpshere eXtreme Scale
• Oracle Coherence

autres sujets

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

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

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:

Séminaire Spring à Tunis : Adopting Spring Framework

Une nouvelle fois, l’ATUGE innove : Son Club techno organise un séminaire de haut niveau : avec trois Expert de SpringFramework : Arjen Poutsma , Russel Miles  et Tareq Abderoabbo.

Lieu : Ecole Esprit – La Charguia II (Tunis)

Date : Vendredi 22 janvier 2010, de 18h30 à 20h30

Sujet :

Le sujet sera axé sur deux aspects :

• 1) Actualités : Les nouveautés de la version 3.0 de SpringFramework par Arjen Poutsma

• 2) Réponse aux besoins de l’entreprise : Spring Integration, l’un des modules les plus prometteurs de Spring par Russel Miles. Spring Integration a pour but de faciliter l'implémentation des solutions d'intégrations dans les applications d'entreprise

Rappelons que Spring 3 est une évolution majeure du framework contenant un grand nombre de nouveautés tel que le support des Web Services REST et Spring Expression Language.

D’autre part, Spring Integration pourra être utilisé pour implémenter un grand nombre des patterns de messaging dans vos applications ; je la qualifie pour le moment d’un ESB Like (dans ses première version je l’appelais pseudo ES) .

Intervenants

Arjen Poutsma : Ingénieur à SpringSource. Fondateur et project lead de Spring Web Services. Spécialiste de SOA et de Spring.

Arjen Poutsma is a senior enterprise application architect with fifteen years' experience in commercial software environments. During this time he has worked with both J2EE and Microsoft .NET.

Arjen is the founder and the project lead for the Spring Web Services. This Spring project aims at facilitating development of document-driven web services. Recently, Arjen worked on the REST support in Spring 3.0. Arjen has also contributed to various other open source projects, including XFire, NEO and others.

Since early 2005, Arjen has been a consultant for SpringSource in The Netherlands.

Russel Miles : Consultant et directeur à OpenCredo, auteur de plusieurs livres à O'Reilly dont des best sellers. Spécialiste des applications entreprise et du cloud computing.

Russ is a consultant and Managing Director of Open Credo.

Russ Miles is an authority on Enterprise, large-scale software development practices. Specialising in Cloud and Event Based software. Russ has also written 3 best-selling books ("AspectJ Cookbook", "Learning UML 2.0", "Head First Software Development") also commits to a number of open source projects.

Le modérateur : Tareq Abderabbo

Le modérateur du séminaire est lui-même un expert de Spring, il s’agit de Tareq Abderabbo : Consultant, Expert en Spring et SOA

Le Club techno de l’ATUGE (Association des Tunisiens des Grandes Ecoles)

Atuge Technologies est un club professionnel affilié à l'Atuge et a pour vocation de fédérer la population atugéenne ayant attrait au domaine des nouvelles technologies.

Les objectifs du club se résument en deux points clés :

• Un enrichissement mutuel, grâce au partage et aux échanges.
• Contribuer à une dynamique d'évolution, à la fois individuelle et collective.

Rappelons que le Club Technologies, dont le responsable actuel est Boujemaa Khaldi, nous a habitués avec des sujets d’actualités et d’un niveau très haut niveau des débats.

Lien http://digitalsyndrom.net/atuge/mailing15/

Lien ATUGE : http://www.atuge.org

Spring 3.0: la version 3 de Spring enterre java 1.4

Pour ceux qui ne sont pas encore sûre, java 1.4 est mort. L’acte de décès est signé Spring 3.0

La célébration des annotations

Les adeptes de Spring, ne pourront plus utiliser java 1.4, avec Spring 3.0, les annotations et les generics sont utilisés dans le cœur Ioc (Spring core). De plus Spring 3.0 offre plusieurs fonctionnalités pour exploiter au maximum le concept d’annotation en général.

Spring 3.0 requiert Java 5 et supporte Java 6. (JPA 2.0, …).

Autre nouvelles importantes, le support de REST dans Spring MVC..

Spring 3.0 renforce le support de la JSR 303 pour la définition et l’expression des contraintes et de validation basée sur les annotations..

Un nouveau langage d’expression

Reste un questionnement sur l’intérêt d’un nouveau langage d’expression Spring Expression Language (SpEL) ? pour Spring peut être integration ?

Mais ceci est un autre sujet

Tutorial Mule ESB : pas à pas

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

1 les projets d’intégration avec ESB.

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

1.2 Les types d’intégration.

1.3 Intégration par les données :.

1.4 Intégration par les API :.

1.5 Intégration par les processus.

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

2 Mule ESB 2.x est il un ESB.

2.1 Ce qu’est un ESB.

2.2 Rôle d’un ESB.

2.3 Mule ESB est il un ESB.

2.4 La concurrence open source.

2.5 Autres usages possible pour Mule.

3 Tutorial Mule ESB : une introduction.

3.1 C’est quoi Mule.

3.2 qu’est ce qu’un service Mule.

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

4 Tutorial Mule ESB : les principales composantes.

4.1 Présentation.

4.2 Installer Mule et son IDE.

4.2.1 Installer Mule.

4.3 Installer l’IDE de Mule.

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

5.1 Créer un projet Mule.

5.2 Créer une configuration Mule.

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

5.4 Sélectionner la configuration Mule.

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

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

6.2 Exécuter le projet.

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

7.1 Introduction.

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

7.3 Construction pas à pas d’un exemple simple :

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

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

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

10.1 Description :.

10.2 Le sujet :

10.3 Pour commencer :

10.4 Configuration de Mule.

10.5 Définir les transformateurs.

10.6 Définir le modèle.

10.7 Définir un service.

10.8 Définir les entrées du service.

10.9 Définir le composant du service.

10.10 Définir la sortie du composant.

10.11 Finaliser le projet.

10.12 Exécuter le projet.

10.13 Retour sur les transformations.

Tutorial Mule ESB : illustration des capacités de Mule

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

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

Description :

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

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

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

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

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

Le sujet :

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

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

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

Pour commencer :

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

Les Pojo en relation avec le projet sont :

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

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

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

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

Le projet se présente sous cette forme :

Configuration de Mule

Le prologue :

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

Fixer les namspaces à utiliser

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

Définir les transformateurs

Définir les transformateurs à utiliser

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

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

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

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

Une classe de Transformation

· hérite de la classe AbstractTransformer

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

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

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

1:  Etudiant etudiant = (Etudiant) src;

Définir le modèle

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

Définir un service

Rappelons, que dans un service il ya 4 parties

<component />	Le composant
<outbound> </outbound>	Le point de sortie
<default-service-exception-strategy> </default-service-exception-strategy>	La gestion des exceptions
</service>

Définir les entrées du service

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

· Un point d’entrée http

· Un point d’entrée vm

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

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

http://localhost:8888?nom=Khalil

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

MuleClient client = new MuleClient();

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

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

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

Définir le composant du service

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

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

Définir la sortie du composant

Nous illustrons dans cette partie l’usage des filtres :

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

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

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

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

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

Et

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

Finaliser le projet

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

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

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

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

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

Exécuter le projet

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

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

La réponse est alors la suivante

Le serveur indique que tout s’est bien passé

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

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

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

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

<><><><><>

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

Tutorial 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 :

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.

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

Formation : Architecture SOA et intégration d’application d’entreprise, rôles des ESB et des MOM (Middleware Orienté Messages), quel programme et quels sujet traités dans un séminaire de 2 jours

J’anime le 21-22 octobre prochain un séminaire formation, à Tunis, sur le SOA (Architecture orienté messagerie), l’intégration des applications d’entreprise dans un système d’information, rôles des ESB et des MOM (Middleware Orienté Massages).

et pour la nième fois, je me pose la même question « quels thèmes aborder en 2 jours » quel programme?, quels messages ?

la réponse doit tenir compte qu’on est le 09/09/09, presque la fin de la première décennie du 2iemme siècle.

Pour répondre à cette question, même recette, fixer d’abords :

· Les objectifs

· les compétences cibles à acquérir par les participants

· A qui s’adresse

· Le niveau requis

Fixons d’abord les Objectifs

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.

Ainsi, on passe d'une informatique essentiellement composée d'applications à une informatique orientée services afin d'améliorer la réactivité et l’interopérabilité du système d'information.

Ce workshop apporte un retour d’expérience des meilleures pratiques pour la définition d'une architecture SOA ainsi que le choix d’un MOM autre technologies.

L’objectif de ce workshop est de former les participants aux choix des MOM (Middleware Orienté Messagerie) et à la compréhension des concepts EAI et SOA.

Il fournir des clés pour mieux appréhender la démarche d’intégration d’application dans un Systèmes d’Information :

· Objectifs,

· Enjeux,

· Approches,

· Bénéfices,

· Champs d’application

Quelles Compétences à acquérir

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

· Comprendre les problèmes d’intégration d’applications en SI

· Comprendre les fondements des architectures orientées services SOA

· Comprendre les bases des MOM

· Apprendre la démarche de choix d’un MOM

· Evaluer les enjeux du choix d’un MOM dans un contexte SOA

A qui s'adresse ce séminaire?

· IT manager

· Architectes d'applications

· chefs de projet

· Analyste métier

· Assistant à la maîtrise d’ouvrage

· Urbaniste.

Niveau requis

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

· Une Connaissance générale en informatique.

· Une compréhension des enjeux des SI dans l’entreprise

Ainsi, en cette fin 2009, le programme du séminaire :

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

Architecture des systèmes distribués, interopérabilité et standards

Présenter l'évolution des architectures de système d’information et définir les architectures n-tiers et le besoin d’interopérabilité

o Evolution des architectures informatiques

o Comparaison de l’architecture centralisée, client/serveur et n-tiers

o Applications distribuées : contraintes de Conception

o Applications distribuées :  l’Interopérabilité

o Cadre Commun d’interopérabilité :  préconisations

o Architectures d’interopérabilité

o Présentation de XML

-- XML les objectifs de conception

-- Notion de base : balise et attributs

-- Pourquoi XML?

-- La notion de Schéma XML

o Formats d’échange, Interopérabilité et portabilité des données

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

o Problématique de l’intégration en entreprise et intra-entreprises 

o SOA : initialement un  simple besoin d‘intégration

o SOA, différents points de vue

o Présentation du concept SOA

o La notion de service (au sens SOA)

o Exemple de tendance du marché : Adoption de SOA dans le domaine des ERP

o SOA s’applique à tous les niveaux de l’EAI

o Principes fondamentaux de l’architecture SOA

o Cycle de vie d’un service

o Zoom sur la phase d’identification des services : quelle approche

MOM : Middleware Orienté Messagerie

Présenter les fonctions d'un MOM

o - 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 processus.

o - L'opportunité de désolidariser les applications pour assurer la flexibilité d'une solution EAI. Acteurs et enjeux : IBM, BEA, TIBCO.

o La norme JMS de Java EE

o Les offres du marché de l'EAI

-- Un marché très mouvant

-- - L'évolution des acteurs.

-- Typologie des offres existantes.

-- Les bénéfices escomptés et constatés.

-- - Les applications Extranet inter-entreprises : quels usages, quel cadre technique, quelles performances ?

-- Panorama du marché : offre commerciales et open source

SOA entre les concepts, la technique et les standards

Présenter les aspects techniques, les standards qui soutiennent le concept SOA

o Quels sont les éléments clé d’une architecture orientée services ?

o Services Web  : les spécifications XML de base

-- SOAP

-- WSDL

-- UDDI

-- BPEL

o Besoins d'interopérabilités : WS-I et Basic Profiles

o SOA : quelles infrastructures?

o EDA : Event Driven Architeucre

o ESB : un bus au service de SOA

o La relation entre SOA & EDA

o Notion de SLA et les besoins non fonctionnels

o Le besoin de supervision dans une architecture SOA

o La notion de maturité SOA

Choix et mise en œuvre

o Les critères de choix d’un MOM

o Une démarche spécifique et globale

o - L'organisation de l'équipe, le profil des différents intervenants.

o Ce qui change et ce qui reste par rapport à une approche classique.

o Le rôle de l'utilisateur. Les nouveautés de la phase de conception.

o La gestion des flux et des informations.

o L'administration de données.

o La migration des applications existantes pour les connecter au système EAI.

Synthèse

o - Enjeux, projection du marché et des acteurs.

o Principaux pièges à éviter et recommandations.

---------

NB

Pour s’inscrire au séminaire une adresse : info@oxia-group.com

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

Grails, groovy & Google Appengine (3G): créer et déployer votre première application dans le cloud en 10 commandes

Introduction

Après 3,5 mois de test de la version java de Googgle Appengine, j’arrive à la conclusion suivante : dans la version actuelle (Googgle Appengine SDK installé : la version 1.2.2), il est utopique de penser à migrer sans efforts des applications javaEE actuelles. La migration reste possible, n’est pas triviale.
L’approche PaaS proposé par Google, dans son offre Googgle Appengine, ne privilégie pas la réutilisation des applications existantes pour trois raisons (contrairement à l'approche - à tester- de Spring sur son CloudFoundary).


- Une limitation des API java disponible et du ClassLoader (ce lien pour les classes du JRE et ce lien will-it-play-in-app-engine ?)

• - Une limitation des actions possibles (pas de gestion de thread, pas d’écriture dans des fichiers, …)
• - Un changement dans l’utilisation des bases de schémas possibles de bases de données
• Il est préférable que la première application déployée soit réécrite spécialement pour le Googgle Appengine. Cela permet de comprendre le modèle de programmation et le modèle de facturation, les performances … avant même de penser à la connecter aux autres applications Google.

Pour une première exploration, je conseille d”adopter une approche RAD en utilisant l’un sur des frameworks “nouvelle approche du monde Java EE basé sur le concept de “Convention Over Configuration”.

Graisl & Groovy

Depuis sa version 1.1.1, Grails, est devenu le framework le plus prometteur de cette mouvance. Grails encapsule un condensé de Best practices, des meilleurs framewors (Spring, …) open source, des plugins spécifiques …
Ce tutorial vous permet de saisir la faciliter de création et déploiement d’une application

Créer et déployer votre première application dans le cloud en10 commandes

Alors si vous souhaiter vous lancer dans le cloud en quelques minutes : adopter l’approche 3 G : Grails, groovy & Google Appengine.

Les prérequis

1. Java JDK installé (de préférence la dernière version )
2. Grails installé : la version Grails 1.1.1
3. Goggle Appenigne SDK installé : la version 1.2.2
4. Avoir un compte Googgle Appenigne

Les étapes simplement (commades …)

1. grails create-app my_First_3G_app
2. cd my_First_3G_app
3. grails uninstall-plugin hibernate
4. grails install-plugin gorm-jpa
5. grails install-plugin app-engine
6. grails create-domain-class com.oxia.att.test.Message (ajouter un attribute message et faire le mapping JPA avec les annotations )
7. grails generate-all com.oxia.att.test.Message (ajouter le code Groovy et GSP pour personaliser les écrans selon vos besoins)
8. add to grails-app\conf\Config.groovy - google.appengine.application=" app3g "
9. grails set-version 1
10. grails app-engine deploy

Pour visualiser le résultat, allez au http://app3g.appspot.com
Exemple de cette approche : http://np-grails.appspot.com/twitting/list

Pour tester localement l’application :

• grails app-engine
• go to http://localhost:8080 and test the app locally

Les étapes avec explications

Les étapes de 1 à 5 permettent de créer la structure de l’application

Ce qu’il faut retenir :

Ce qu’il faut retenir, Google appengine n’est pas compatible Hibernate, et que grâce au plugin Gorm-JPA de Grails, l’utilisation des annotations JPA est possible.
Les étapes 8 à 10 : concernent le déploiement
Les étapes 6 et 7 concernent l’application Grails et le code métier, affichage …
L’application doit répondre, bien sûre, à vos besoins métiers, et correspondre à la charte graphique de votre entreprise.
Tous ses aspects peuvent être réalisés avec Grails / Groovy en respectant les limitations de Google app engine.
Espèrerons que la même application soit compatible avec l'offre de Spring sur son CloudFoundary.
Signalons, en fin, que la principale limitation qui va rencontrer votre projet : la définition de votre schéma de persistance (pour ne pas dire schéma SQL) compatible avec BigTable (ce n’est pas du SQL bien qu’on y accède en JPA ou JDO, dison GQL)
Mais ceci est un autre sujet
autres entrés sur le même sujet

Cloud Computing : Créer votre première application avec GoogleApp Engine et java

Quel crédit donner aux résultats affichés par le DashBoard de GoogleApp Engine (GAE) ?

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

La dernière nouvelle est tombée le 10 août, une surprise générale en plein période estivale, Vmaware, éditeur commerciale à code fermé, acquiert la totalité de SpringeSource, un éditeur commercial basé sur un modèle open source et code ouvert.

est ce que c’est la tendance : prise de contrôle par les grands fournisseurs des éditeurs open source :

d’après le Gartner : c’est une lame de fond !

à vraie dire les exemples le montrent bien :

Exemples d’acquittions

Mais, ce n’est pas la seule information de ce type (ordre non chronologique..) :

1) Novell a fait l'acquisition de SUSE Linux (en 2004)

2) Cisco, a acheté en 2008, Jabber, l’éditeur de la solution de messagerie instantanée open source Jbber et fondateur du protocole de messagerie instantané XMPP (Extensible Messaging and Presence Protocol). XMPP est adopté par Google, Micorsoft,

3) Nokia, en 2008 a acheté Symbian Ltd, éditeur du système d'exploitation du même nom

4) SUN a mis la main sur MySQL

5) Oracle a mis la main sur Sun, et tout son actif de codes sources libres (Java, MySQL, …). Rappelons que Sun se targe souvent d’être l’entreprise, qui contribue le plus à l’open source. SUN a déjà mis en open source tout son

6) Citrix a acheté l'hyperviseur open source Xen,

7) IBM, a acheté , en 2005, la société Gluecode Software, une société spécialisée dans les logiciels libres issus de la fondation Apache, notamment le serveur d’applications Geronimo et le SGBD Derby.

8) Oracle a acheté en 2006 société Innobase, connu de la communauté open source par InnoDB, utilisé, comme de gestionnaire de tables pour MySQL (une des alternatives)

9) Oracle a acheté en 2006, Sleepycat Software, qui développe la base, open source, Berkeley DB, embarquée dans Linux et open office

10) Progress a racheté, en 2008, Iona Technologies, ce qui a permit à Progress Software de mettre le pied dans l’open source, à tyravers FUSE et serviceMix

11) Serena Software acquiert Projity éditeur d’OpenProj, logiciel de gestion de projet open source, et de Project-ON-Demand, logiciel de gestion de projet en mode SaaS

12) Nokia a acheté Trolltech, éditeur de Qt, un environnement de développement open source basé sur C++ pour Windows, Mac et Linux. Trolltech a développée aussi Qtopia Phone Edition, version mobile de Linux.

13) Yahoo a mis la mais sur Zimbra, une suite collaborative open source de type Outlook Exchange qui en plus de fonctionnalités collaboratives traditionnelles, intègre plusieurs nouvelles technologies du Web telles que l’Ajax, les tags et la VOIP

(aujourd’hui le 13 aout 2008, je m’arrête à ce chiffre, …)

Exemples de financement massive

Ce type de prise de contrôle par l’acquisition et absorption, n’est pas la seule façon de contrôler le projet open source…

En effet, si c’est ce n’est pas une prise de contrôle par les grands fournisseurs achat directe, c’est un financement massive et directe (peut être pour créer une dépendance forte et peser sur les décisions!)

IBM : a crée Eclipse et reste le principal soutien à Eclipse Fondation

Google : principale bailleurs de fonds pour FireFox

IBM : est un soutien à Prosgresql

IBM : a crée Eclipse et reste le principal soutien à Eclipse Fondation

IBM et SUN: principaux souteneurs à OpenOffice (et on devine pourquoi)

SUN est principale soutien à Glassfish, serveur d’application Open source

IBM est principale soutien à Geronimo, serveur d’application Open source

Et Microsft commence à soutenir des projets Open source (plateforme codeplex.com) et fondation Linux.

Rappelons que Microsoft, Google et Yahoo au sont des sponsors Platinium d'Apache

Exemples de consortium

Autres situations à inclure dans l’observation et l’analyse: le poids important des consortiums financés par les gouvernements.

L’exemple qui me vient à l’esprit est le consortium OW2, financé par la communauté européenne et des grandes entreprises (FranceTélécom, Thalès, BULL, IRIA, CNRS …) a soutenu plusieurs : Fondé en 2007 suite à la fusion d'ObjectWeb et d'Orientware, le consortium OW2 regroupe des acteurs industriels et académiques mondiaux qui conjuguent leurs efforts pour créer en open-source du logiciel middleware de nouvelle génération.

on le sait : la communauté européenne considère que l’open source est un axe stratégique pour l’IT et la compétitivité européenne..

la tendance de fond : un seul fournisseur contrôle le projet (directement ou indirectement)

D’autres part,

Le Gartner, pointe de l’index, une nouvelle tendance de fond : des logiciels open source sans communauté, avec le soutien d’un seul fournisseur.

D’après le Garner, d'ici 2012, la moitié au moins du CA généré par les logiciels open source et les services associés proviendra de projets "sponsorisés" par un seul fournisseur

Est-ce raisonnable ? Sachant que la force du modèle économique de l’open source puise sa force, justement, dans cette communauté.

Est-ce qu’une stratégie de phagocytage ou dynamitage, ou est ce que la démonstration que le modèle marche ?

Est-ce que le les prochaines versions du code source resteront « disponible et gratuit », ou est ce que la dernière version, vraiment libre sera celle avant l’achat.

Une analyse montre que le slogan « Open Source for Sale » va s’accélérer et de plus en plus sa forme, peut être grâce à al crise ou à cause de la crise!

De toutes les façons, le monde d’après la crise sera différent,

Mais ceci est un autre sujet …

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

sur le même sujet

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

Oracle a acheté SUN : Que va-t-il se passer ?

Oracle & SUN : Quel avenir pour l’unique solution MDM open source, SUN MDM Suite?

Si IBM achèterait SUN : Quelle conséquence pour le monde Java ?

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