Ross Altman, Sun : ‘Les ESB concurrents? Trop vieux, ou trop jeunes !’

De passage à Paris, le ‘CTO’, ou directeur technique de l’activité SOA &
Business Integration de Sun Microsystems nous explique le concept d’ESB
[enterprise service bus]. Pas de concurrents?

Quels sont les besoins applicatifs des entreprises, en priorité ?

La demande actuelle des entreprises s’inscrit sur 2 axes :

1- le développement d’applications composites (utilisant des services et programmes existants pour les combiner ou pour créer d’autres applications),

2- la mise en place d’une architecture SOA pour permettre de concevoir et de gérer ces applications.

Un premier objectif de ces développements consiste à consolider et rendre cohérentes et pertinentes les informations des divers systèmes informatiques de l’entreprise : éviter ou gérer au mieux les doublons, effectuer des contrôles, etc. La deuxième famille d’applications composites vise à gérer les processus, avec les solutions de type BPM [business process management]. Et cela ne peut pas se faire à partir de rien, car l’existant informatique (de l’entreprise et de ses partenaires) détient une grande partie de la logique métier indispensable à cette démarche.

Avec Sun Java Composite Application Platform Suite [CAPS, suite issue notamment de SeeBeyond], notre approche consiste à répondre à l’intégralité du besoin. D’une part, un ESB (Enterprise service bus) complet doit accéder à tout l?existant ; d’autre part, l’éditeur doit fournir une solution pour décrire les nouveaux processus et développer les applications composites.

Qu’entendez-vous par ‘un ESB complet’ ?

Pour gérer son activité, l’entreprise accède à des systèmes informatiques et applications internes et externes. Toutefois, ces applications communiquent peu entre elles, et souvent de manière très spécifique et complexe.

Au premier niveau, un ESB doit proposer un maximum d’adaptateurs et connecteurs performants. Dans CAPS, nous proposons 85 adaptateurs pour communiquer avec les bases de données, les applications, les moniteurs transactionnels, les systèmes de messages applicatifs, etc.

Au dessus de ces adaptateurs, une transformation des données permet d’assurer la cohérence de l’information et la qualité des données (gérer des livres et des kilos, ou des kilomètres et des miles, ou homogénéiser les formats de date?).

Pour cela, trois standards existent :

-XSLT (Extensible Stylesheet Language Transformation),

-Java

-SQL (Structured Query Language).

Nous avons implémenté les trois. Ainsi, une même application composite utilisera en même temps, et avec le même code, des données d’un datawarehouse(avec SQL) et les fonctions d’une application de gestion (avec Java).

Pour les interfaces avec les applications, nous utilisons JMS (Java Message Service) et les services Web, mais aussi les méthodes d’invocation Java ou encore les technologies Microsoft Com, DCom ou Com+.

Pour coordonner tous ces processus et interfaces un module d’orchestration s’appuyant sur un référentiel de règles unique s’avère indispensable. Pour ce module, nous respectons les standards existants (bien qu’encore limités pour gérer le workflow par exemple) : BPML (Business Process Modeling Language) et BPEL (Business Process Execution Language for Web Services). Enfin, nous proposons, éventuellement indépendamment, une solution de développement et de modélisation des processus et des applications composites.

Selon vous, quelle est votre spécificité sur ce métier ?

Elle tient en deux mots : les ESB concurrents sont soit trop vieux, soit trop jeunes. Les grands éditeurs ont racheté des sociétés très spécialisées pour compléter leurs offres et disposer d’un ESB complets. Néanmoins, l’assemblage technologique donne rarement les meilleurs résultats. Ces solutions ont été rachetées il y a trois à quatre ans et reposent sur des technologies de cette époque.

Sur CAPS, nous avons tout développé en interne, et effectué nous-mêmes le portage sur Java. Nous maîtrisons donc totalement le code de nos solutions 100 % maison et l’intégration entre les modules.

D’autres concurrents émergent actuellement avec de toutes nouvelles offres respectant les standards. Celles-ci manquent de maturité et sont encore fonctionnellement assez pauvres.

La tarification de ces offres ne les réserve-t-elle pas aux PME/PMI?

Il est vrai que nos clients sont plutôt de grandes entreprises. Nous leur proposons soit une licence illimitée, soit des licences limitées en nombre d’utilisateurs.

Toutefois, notre offre reste accessible aux PME/PMI, puisque nous proposons également la solution complète pour 100 dollars par utilisateur et par an, support inclus. Mais, pour être réellement efficace auprès de ces entreprises, il faut également disposer d’un réseau de revendeurs et d’intégrateurs de proximité. Cela ne cadre pas avec notre stratégie actuelle. Un acteur comme Microsoft avec ses milliers de revendeurs semble le mieux placé pour adresser ces entreprises.

Combien faut-il ajouter au prix de licence pour l’intégration ?

L’investissement varie selon les projets. On constate en moyenne que le prix des prestations correspond à quatre ou cinq fois le prix des licences. Néanmoins, cela dépend fortement de l’existant et des projets envisagés. Quoi qu’il en soit, notre ambition n’est pas de développer du service Sun, mais bien de nous reposer sur nos partenaires.