Retour d'expérience sur les Architectures d'Entreprise

Á quoi sert un référentiel d'entreprise ?

2012-01-30T17:27:00.000+01:00

Contexte

Les différents départements d'une entreprise ont chacun un fonctionnement basé sur leurs propres processus. Ces derniers se basent sur plusieurs référentiels de données (sources authentiques) qui sont propres à chaque département puisqu'ils sont liés à leurs outils spécifiques, à leur métier. Concrètement un département d'Exploitation a son fonctionnement basé sur les différents processus ITIL qui est lui-même basé sur les référentiels de gestion de la configuration (CMDB). Un département Développement est basé quant à lui sur PMI (ou Prince2) qui utilise, entre autres, un outil de la planification des projets. Un département de comptabilité doit appliquer par exemple la législation nationale sur les budgets qui imposent un fonctionnement basé sur un référentiel comptable (par ex. SAP). D'autres processus comme d'autres référentiels existent, cette liste n'étant pas exhaustive.

On s'aperçoit à un niveau transversal que ces processus sont fortement liés entre eux puisqu'ils vont tous dans le même sens : l'intérêt de l'Entreprise et de ses clients.

Par exemple l'architecture d'entreprise lors de ses analyses doit aborder des problématiques en tenant compte des processus Métier (qui gère les SI, comment et pourquoi), des systèmes d'information (quel domaine d'applications est concerné par le changement ? Quel est le planning de l'application ? Quelles données transversales sont utilisées ? ...) et enfin des technologies (sur quel serveur fonctionne l'application ? Quel réseau est utilisé ? ...). D'autres problématiques existent : le département Exploitation aimerait savoir précisément quel utilisateur (personne) est impacté lorsqu'un réseau informatique est tombé. Le département Service Achats aimerait aussi planifier la charge de ses équipes en connaissant à l'avance les projets qui vont être lancés ou les machines qui seront achetées suite à un problème de capacité.

Ces dépendances entre les processus peuvent être vues comme étant des liens entre les différents référentiels des départements. En effet chacun de ces référentiels contient une partie de la réponse. Il faut donc trouver un lieu commun pour rendre accessible tous ces liens. Cet endroit est appelé « référentiel applicatif » ou « référentiel d'entreprise » ou en anglais « enterprise architecture management system » (EAMS).

(Pourquoi applicatif ? Parce que dans une entreprise spécialisée en informatique, le point commun est les différents systèmes d'information gérés. Et un système d'information étant un ensemble d'applications, il semblait logique d'appeler en français ce système « référentiel applicatif » afin de ne pas trop « l'étiqueter » architecture puisqu'il est dédié à être utilisé par presque l'ensemble des disciplines.)

Son rôle

Le référentiel applicatif doit pouvoir être utilisé dans les situations suivantes (liste non exhaustive) :

Aider à documenter le SI existant (vue as-is)
Aider à documenter le SI futur (vue to-be)
Aider à analyser l'impact du changement du as-is vers le to-be
Exporter ses informations à d'autres référentiels
Aider à planifier et à suivre l'évolution du as-is vers le to-be
Aider à documenter les standards techniques
Représenter et maintenir les relations entre les éléments organisationnels, logiques, techniques et technologiques de notre SI
…

Enjeux

L'enjeu de posséder un référentiel applicatif est grand puisqu'il a l'ambition d'amplifier la synergie entre les processus des départements ainsi que d’accélérer la communication de l'information.

Un architecte d'entreprise ? à quoi çà sert ?

2012-01-28T10:10:00.007+01:00

Pour répondre à une demande croissante et en perpétuelle évolution, l'entreprise mène de front de nombreux projets informatiques. L'architecte d'entreprise veille à la cohérence de l'ensemble dans le cadre de la vision stratégique de la société. Transversal par excellence, ce rôle implique la participation de l'architecte dès le départ et à chaque étape d'un projet. Il doit prendre en compte trois grands aspects de l’évolution de l’entreprise : les métiers (processus et ressources), les systèmes d'information (applications et données) et les technologies sous-jacentes (infrastructure)

Tout au long de son existence -traitement de la demande, analyse, réalisation et exploitation- chaque projet est suivi pas à pas en termes d'objectifs, de délais, de moyens et de risques. L'évaluation du risque est une démarche indispensable ! . Elle consiste à mesurer l'impact du changement à tous les niveaux. D'un point de vue informatique, cet impact s'exprime en termes de puissance de traitement, de capacités de stockage et de transmission de l'information. Quel que soit le changement, il faut en mesurer les retombées sur l'ensemble des systèmes existants. Un projet stratégique implique de nombreux acteurs, de nombreuses applications et une grande quantité de données. Mais un projet d'apparence plus modeste peut aussi avoir des répercussions sur des centaines, voire des milliers d'utilisateurs. La question de l'origine des données (concept de la source authentique), par exemple, est cruciale. La vérification de la qualité des données est l’un des facteurs essentiels dans la réduction des risques. »

Pour remplir son rôle, l'architecture d'entreprise peut s’appuyer sur différents outils dont un référentiel d’entreprise qui permet d’établir des liens entre les différents éléments intervenant dans l’architecture des SI. Ce référentiel permet de révéler automatiquement l’impact d’un changement : bases de données, capacités, processus, besoins en formations, etc.
L'architecte d'entreprise avec un référentiel clarifie la vue globale des activités de l’entreprise. Il génère des gains de temps. Il minimise les coûts de développement, de déploiement et de maintenance. Il rejoint les objectifs de qualité des solutions en termes d’interopérabilité, de compatibilité, de flexibilité, de stabilité, de disponibilité et de sécurité. Enfin, il permet de prendre en compte les orientations futures prévues dans les plans stratégiques et opérationnels.

Ingénierie des processus métiers

2010-01-05T09:18:00.002+01:00

Voici deux documents très intéressants en téléchargement libre.

Le premier concerne le document "Ingénierie des processus métiers":
Disponible ici.

Le deuxième donne un complément open-source dans le domaine des moteurs de règle:
Disponible ici (à condition de devenir membre. Inscription gratuit :-) ).

Bonné année 2010

2010-01-05T09:16:00.001+01:00

Bonne année 2010 !

Voici ma bonne résolution de l'année : mieux maintenir ce blog que j'ai malheureusement négligé ces derniers mois.

Á bientôt.

Lilian.

Le blog change de nom

2009-03-11T18:28:00.006+01:00

Suite à ma nouvelle fonction dans ma société, je ré-oriente le blog sur les architectures d'entreprise et leurs problématiques.

Ma nouvelle fonction explique le fait du peu de message sur le blog ces derniers temps. J'espère que je pourrai trouver le temps pour vous faire profiter de mes études.

websequencediagrams.com

2008-12-30T11:11:00.002+01:00

Voici un outil très intéressant pour une petite documentation utilisateur "non orienté informatique" où le style est plus important que le formalisme.

Il ne sert qu'à réaliser de petit diagramme de séquence. Son avantage est (pour moi) sa génération de diagramme sous plusieurs styles. Là justement où nos outils de modélisation (rose, bouml, eclipse, visualp...) sont fort limités.

lien: http://websequencediagrams.com/

YAXE beta 1.1 - Yet Another XML Editor

2008-12-14T12:46:00.011+01:00

Qui a la responsabilité des webservices à valeur ajoutée ?
Le donneur d'ordre.

Qui est capable de les comprendre et de les tester ?
Un informaticien.

Quand le donneur d'ordre n'est pas informaticien, que faire ? YAXE répond à cette problématique.

En résumé voici le contexte de départ de YAXE :
Réaliser un outil qui permet de tester des webservices sans connaître le XML, SOAP, ws-addressing, ws-security ... Pour cela YAXE construit un formulaire SWING sur base d'un XML Schema. Ainsi si vous fournissez le xml schema d'un webservice vous pourrez le tester sans toucher une seule fois au xml.

Biensûr un informaticien peut réaliser pour son donneur d'ordre une application SWING pour répondre à ce besoin de test. Mais à chaque webservice réalisé et à chaque modification du message il faut réaliser une nouvelle application. Avec YAXE c'est fini. Tout est fait automatiquement. Il suffit d'envoyer au donneur d'ordre le XML Schema (XSD) avec la nouvelle configuration de YAXE.

Voici l'url où télécharger YAXE: http://forge.etnic.be/yaxe/

Cimero devient EID ...

2008-03-27T21:10:00.004+01:00

En août 2006 j'avais publié un article sur Cimero car je croyais beaucoup en cet outil graphique pour servicemix.

Un an après je changeai complètement d'avis car je voyais que ce projet se cherchait sans évoluer. Bull comptait le mettre dans les mains du projet STP mais je ne voyais rien venir. J'étais toujours bloqué sur cette page.

Il y a quelques jours j'ai eu le plaisir de voir que je me suis trompé: ce projet évolue et en bien. Il porte le nom de Enterprise Integration Designer (EID) dans le sous-projet Eclipse: SOA TOOLS PLATFORM. Cliquer ici pour y accèder.

Je viens de voir que lors d'EclipseCon 2008, un stand a été spécialement dédié à Camel. Dans cet article j'ai eu la bonne surprise de lire qu'EID et Camel sont compatibles. J'utilise déjà Camel dans mes projets et je trouve ce framework trés puissant et stable.

N'hésiter pas à me donner votre retour d'expérience sur cette nouvelle version de Cimero: EID.

Bonne année 2008 !

2008-01-01T11:59:00.000+01:00

Bonne année 2008 à tout le monde et beaucoup de projets à réaliser dans la refonte SOA :-)

Livre blanc: Comprendre et savoir utiliser un ESB dans une SOA

2007-12-22T14:46:00.000+01:00

Voici un livre blanc intéressant pour tous ceux qui se demande comment utiliser un ESB dans une architecture d'entreprise. Ce livre blanc est un bon résumé pour connaître les différents contextes d'utilisation d'un ESB.

Cliquer sur ce lien pour accèder au livre blanc
(ce livre blanc a été écrit par Xebia et est disponible sur leur blog)

Attention, choisir une architecture avec un ESB doit toujours se justifier par rapport à un besoin d'entreprise, non parce que c'est une mode.

Remerciement aux auteurs du livre "Le système d'information durable"

2007-12-20T12:10:00.000+01:00

Je tiens à remercier les auteurs (Pierre Bonnet, Jean-Michel Detavernier, Dominique Vauquier) du livre "Le système d'information durable" pour leurs nombreux conseils et transferts de connaissances dans la refonte d'un système d'information.

Grâce à eux j'ai gagner beaucoup de temps de recherche et d'analyse d'impact car dans ce livre, j'en enfin pu découvrir des pistes de solutions pour résoudre des défauts / problèmes (cfr article précédent) que j'avais pu constater lors de la réalisation de notre ESB.

Future architecture ...

2007-12-20T11:51:00.000+01:00

Voici l'architecture à laquelle je pense pour 2008:

Cette architecture va permettre de découpler (au niveau de la perturbation de charge) les différents domaine métier de l'entreprise. Tout en leur laissant la possibilité de découvrir et d'accèder de manière transparente à des services d'un autre domaine. Chaque domaine est composé de plusieurs back-ends.

Cette architecture sera réalisée morceau par morceau sur base de l'actuelle. Nous commencerons par l'ajout d'un MDM construit sur base d'un moteur de règle. Car nous constatons évidement que de nombreux doublons de SE (service engine) vont apparaître avec pour seules différences le contexte métier. Donc ce seront toujours les mêmes SE (au sens technique) qui seront déployés sur chacun des ESB mais la manière de s'exécuter dépendra du contexte métier du message. Ce contexte sera découvert grâce au MDM.

Le MDM+Moteur de règle devient la clé de cette architecture sinon elle sera trés/trop compliquée à gérer avec énormément de doublons de SE. Sans MDM une solution serait de profiter de la communication distribuée entre les ESB. Seulement ici il risque d'apparaître une dépendance entre domaines métier qui n'ont pas les mêmes exigence de disponibilité et de ce fait les mêmes SLA.

... (à suivre) ...

Architecture avec un ESB

2007-12-17T11:30:00.000+01:00

Certains ne comprenaient pas le schéma d'infrastructure dans un article paru au mois de novembre 2007, car ils ne voyaient pas où se situait l'ESB.

En voici une autre vue plus "architecturale" de l'ESB réalisé.

Le SMX-CAS est placé comme "Binding Component" et le SMX-WORK est notre ESB.

Pour plus d'explications, cliquer sur ce lien: http://forge.etnic.be et sélectionner le projet ESB-JANUS.

Forge.etnic.be

2007-12-14T13:04:00.001+01:00

La forge est enfin opérationnelle !!!

Vous pourrez accèder à l'ensemble de notre travail à cette http://forge.etnic.be .

Surtout n'hésiter pas à laisser vos commentaires ou à poser vos questions sur le site.

=-=-=-=-=-=-=-=-=-=-=-=-=

The Forge is online now !!!

You will be able to see our whole work on this address http://forge.etnic.be .

Don't hesitate to let your comments or your questions online.

Améliorations de l'architecture

2007-11-10T09:37:00.000+01:00

Après quelques semaines d'utilisation, voici les critiques que nous faisons de notre architecture:

L'idée du CAS est bonne mais la maintenance des services (exposés sous forme de BC HTTP) n'est pas simple puisque la valeur ajoutée du BC HTTP n'est uniquement que sur l'exposition du WSDL.
La redirection dans le CAS se fait par un SE Orchestration qui sur base de l'appelant (BC HTTP par exemple) va rediriger vers une queue ou un autre BC HTTP. Si on respecte (ou profite) la spec WS-Addressing, les balises "wsa:Action" et "wsa:To" doivent être la référence pour définir le service suivant à atteindre.
L'élément Polling doit être un service dans l'ESB et non un élément à part.

L'objectif de toutes ces modifications est d'avoir une forte amélioration de la maintenance au niveau du CAS et surtout d'avoir une cohérence sur la technique d'appel à nos webservices.

La solution pour répondre aux points ci-dessus a été de mettre en place un BC HTTP unique quelque soit le webservice SOAP par instance de CAS. Ce binding component fera ensuite suivre à des services de contrôle d'accès puis au SE Orchestration. Ce dernier appellera un générateur d'ID pour "estampiller" l'appel, déléguera l'enrichissement de droits fins et décidera sur base des balises "wsa:addresing" à qui déléguer la suite des traitements.

Trois avantages apparaissent avec cette solution:

Simplification non négligeable de la maintenance ainsi aucune modification du CAS ne sera nécessaire lors de la création de nouveau service. Aucun SE ne sera modifié, pas même le SE d'Orchestration.
Par le respect du "wsa:addressing" nous augmentons la flexibilité de l'architecture.
Les puristes du SLA et de la notion de service au sein d'une SOA doivent attraper des boutons à la lecture de ces améliorations :-) . Il est vrai que le SLA ne pourra plus être attaché à un service propement dit (sur base d'une URL, comme c'est souvent le cas), donc le contrôle Q&A sera plus difficile à mesurer en entrée et surtout d'en différencier les services. Nous devrons en cas de SLA différents trouver une solution pour faciliter les mesures. Du côté du suivi des appels et de l'assistance en cas de problème, dés le début nous avons pris la décision de nous baser sur les ID. De ce fait notre système d'audit reste inchangé.

Avec cette solution nous ne pouvons plus attacher un wsdl à l'url. Mais puisque nous comptons installer un référentiel de type UDDI pour documenter nos webservices, tout semble résolu. Lorsqu'une personne fera un ?wsdl, il sera automatiquement dirigé sur le référentiel.

Que pensez-vous de nos améliorations? N'hésiter pas à m'envoyer vos remarques?

Quel référentiel open-source conseilleriez-vous?

Mise en open source de notre solution ESB

2007-10-27T11:46:00.000+02:00

Je suis fier de vous annoncer que notre solution sera mise en open source prochainement.

Nous sommes en train de travailler sur une dernière amélioration de l'ESB pour pouvoir publier une solution bien packagée.

Prochainement je publierai l'adresse du site...

Liste des projets Open Source de la solution ESB

2007-08-17T09:28:00.001+02:00

Notre ESB a été construit autour de plusieurs projets Open Source.
En voici liste :

De la communauté Apache

SERVICEMIX (ESB)

ODE-PXE (BPEL engine)
ODE-DESIGNER (Designer BPEL pour ODE)

ACTIVEMQ (Message broker)

De la communauté Eclipse

CIMERO (Designer JBI)

De la commuanuté OO2 (anciennement ObjectWeb)

SPAGIC (Monitoring et Audit sur Servicemix)

De la communauté SourceForge.net

OPENNMS (Monitoring de l'infrastructure ESB)

De la communauté SafeHaus

JUG-ASL (ID generator)

Projet Open Source indépendant:

MySQL (pour l'ensemble des DB de l'infrastructure)*
OpenLDAP (LDAP pour l'authentification et les autorisations)

* Remarque: nous étudions la possibilité de migrer de MySQL vers PostgreSQL pour des raisons de volume bien mieux gérés dans ce DBMS.

Présentation de la solution ESB

2007-08-03T13:49:00.000+02:00

Voici une présentation de notre architecture SOA développée sur base d'un ESB Open Source, ServiceMix.

Contraintes techniques:

2500 applications Client dans un premier temps puis à terme 3500 vont appeler nos services web. En moyenne 1000 applications Client accèderont en simultané à nos services web à valeurs ajoutées.
Taux de charge: environ 1,5 millions d'appels de 30-50ko de données en in-out dans un premier temps à traiter en 3-5 jours.
les services web à valeurs ajoutées exposées sur Internet (on-line) doivent pour certains être fortement sécurisés avec non-répudiation.
certains services web à valeurs ajoutées retournent un nombre de données important.
les applications métiers seront accessibles via des services web sur l'intranet.
certains services web à valeurs ajoutées fourniront la réponse en synchrone d'autre en asynchrone suivant les besoins.
tous les services doivent être impérativement disponibles en 24/7.
certains back-end - 80 applications back-end aujourd'hui puis 120 à terme - sont peu performants en terme de capacité et donc l'ESB devra être capable de "réguler" la charge sur les back-end.
dans le cadre de la sécurité, la validité des certificats qui ont permis de signer les messages devra être vérifiée.
les applications Client sont soit des applications serveurs (application standalone de type "Batch" ou alors des applications web) soit des applications Client lourd ou léger installées sur des postes clients (personal computer).

Architecture générale:

L’ESB est composé de trois entités principales.

(SMX-CAS) La première a la responsabilité de gérer les aspects de sécurité, de génération d'ID (estampillage les messages) et d'enrichissement pour récupérer les données permettant le contrôle d'accès aux données. Elle est capable de fonctionner en synchrone ou en asynchrone. En asynchrone elle dépose les messages dans une queue et en synchrone elle fait appelle directement à la deuxiéme entité principale.
(SMX-WORK) La deuxième entité s’occupe de la partie traitement proprement dite : validation du schéma XSD, appels aux différents WS back-end, gestion des erreurs... Les concepts SOA seront implémentés dés cette entité - jusqu'au back-end évidement ;-) .
(SMX-POLLING) La troisième entité est utilisée par les applications Client pour récupérer les réponses lors des appels asynchrone.

Les deux entités SMX-CAS et SMX-WORK sont connectées via un broker JMS qui permet d'assurer la persistance des messages ainsi que la régulation (notion de bassin d'orage) de la deuxième entité. Remarque: la régulation "joue" sur le nombre de listeners JMS qui démarrent les processus dans SMX-WORK pour régler la charge de manière indirecte sur les back-end.

Remarque: SSL acc = SSL accelerator

Gestion de la charge dans l'infrastructure:

Les load-balancer (LB) en entrée permettent d'assurer la disponibilité des services en répartissant le nombre des appels sur deux SMX-CAS. En cas de dépassement d'un seuil (prédéfini) une ou deux instances SMX-CAS sont automatiquement démarrées pour fournir en tout 4 SMX-CAS au LB.

Le Broker JMS en cluster réceptionne les messages du SMX-CAS et les met à disposition de SMX-WORK. Si cet élément est surchargé alors toute l'infrastructure perdra en performance. D'où en cas de détection d'un temps de réponse trop élevé, une instance du broker JMS sera démarré automatiquement et entrera comme acteur dans le cluster.

Pour avoir une infrastructure performante, il faut que les messages en attente dans le broker JMS doivent rester le moins longtemps possible. De ce fait il est prévu que lorsqu'un nombre de messages en attente dans le broker JMS est dépassé une instance supplémentaire de SMX-WORK est démarrée.

Biensûr toutes les instances en stand-by peuvent être démarrées manuellement dans l'hypothèse d'une anticipation de charge.

Gestion de la disponibilité de l'infrastructure:

En plus d'une architecture redondante nous utilisons les fonctions de disponibilité du logiciel de virtualisation VMWare. Il permet de déplacer des instances d'un serveur physique à un autre (par exemple si une carte réseau est défaillante) avec un léger temps de latence.

Boite à outils:

L’ESB dispose d'outils annexes :

deux outils de développement graphique : Cimero et Intalio Designer

une console d’administration, de monitoring et d'audit

Bientôt la fin ...

2007-04-15T09:25:00.000+02:00

Bonjour à tous,
L'idée d'origine de ce blog était de mettre mes retours d'expérience d'un projet de longue haleine: la réalisation d'un ESB "from scratch" dans une institution qui prenait un tournant "new technologies" (webservice, exposition de services à valeurs ajoutées à plus de 3000 autres organisations, refonte d'une partie du back-end ... )

Si l'idée est pleine de bonnes intentions, trouver le temps libre est autre chose. D'où le peu d'articles ces derniers temps ;-)

Mais c'est bientôt fini ... le projet est en dernière ligne droite. Les premiers résultats (bon ou mauvais) commencent à sortir, je vais enfin pouvoir écrire mes impressions sur ce projet de grand impact sur l'organisation d'une entreprise (pas les résultats du projet, vous pourrez peut-être les déduire)

à bientôt ...

SUN et le projet PRESTO

2007-02-08T08:30:00.000+01:00

Pour rappel, le projet PRESTO a pour objectif de réaliser un framework d'intéropérabilité sur base des WS-*.

La société SUN publie une explication sur son prototype.

Cliquez ici pour y accèder.

Il s'appuie sur le framework WSIT du projet Tango basé sur JAX-WS et JAXB.

Grande nouvelle pour Objectweb: accord entre Bull et Redhat

2006-11-22T21:35:00.000+01:00

Grande nouvelle annoncée hier pour Objectweb: les sociétés Bull et Redhat deviennent partenaires et donnent leurs accords pour une alliance entre les communautés JBoss et Objectweb.

(extrait LMI) Objectif : assurer la plus grande interopérabilité entre les travaux des communautés JBoss et ObjectWeb.

Ceci est un avantage non négligeable pour le consortium Objectweb spécialisé dans le middleware qui voit deux géants rejoindre sa communauté avec tous leurs moyens et puissance en marketing.

Cliquer ici pour accèder à l'article du magazine "lemondeinformatique".

Le projet CXF

2006-11-19T17:25:00.000+01:00

Guillaume Nodet de LogicBlaze m'a signalé un projet trés prometteur, il s'agit de l'alliance de XFire de Codehaus et Celtix d'Objectweb autour du projet CXF (CeltiXFire) d'Apache.

Ce projet, aujourd'hui au stade incubateur, a l'ambition de réaliser un framework complet pour implémenter des services du monde SOA basés sur les standards.

Extrait du site:
Apache Incubator CXF simplifies the construction, integration, and flexible reuse of technical and business components using a standards-based, service-oriented architecture (SOA).

Les services CXF pourront être déployés sur les différentes plateformes et containers suivants:

Lightweight containers: deploy services in Tomcat or Spring-based containers
JBI integration: deploy as a service engine in a JBI container such as ServiceMix, OpenESB or Petals
SCA integration: deploy in an SCA container such as Tuscany
J2EE integration: deploy services in J2EE application servers such as Geronimo, JOnAS, JBoss, WebLogic, and WebSphere
Standalone Java client/server

Cliquez ici pour accéder au site.

Je trouve trés intéressant le support par ce framework des standards WS-Security et WS-RM. Le fait d'être prochainement compatible avec ServiceMix, Petals et OpenESB permettra de combler cette lacune au sein de ces containers JBI.

Le rôle d'un ESB ?

2006-10-30T11:14:00.000+01:00

Voici une excellente présentation sur les ESB (durée > 1h) de Mark Richards sur leurs rôles dans les entreprises. Au delà de la performance du présentateur et du contenu de la présentation, je vois une volonté de défendre les concepts de JBI au sein des entreprises.

Cliquer ici pour y accéder (attention: en anglais)

Emergence de nouveaux protocoles basés sur WS-*

2006-09-19T21:33:00.000+02:00

Deux nouveaux protocoles basés sur les standards WS-* naissent en France et en Belgique à quelques semaines d'intervalle.

En France il s'agit de PRESTO destiné aux échanges de messages et de documents binaires entre les administrations françaises.

En Belgique il s'agit d'un protocole destiné aux échanges de messages entre les institutions de la communauté française de Belgique (CFWB). ETNIC est l'OIP (Organisme d'Intérêt Public) pour la CFWB qui est chargé de la réalisation du protocole et de son support.

Ces deux protocoles ont été étudiés en parallèle pour arriver au même résultat sur les bases. D'ailleurs la dernière version du protocole de la CFWB a été revue en fonction des publications de PRESTO début septembre.

Presto est plus complet et va beaucoup plus loin puisqu'il prévoit le contrôle du niveau de qualité de service.

Voici quelques liens:

ETNIC - spécifications techniques d'appel aux webservices

CIMERO: Configuration Interface for MEssage ROuting

2006-08-14T12:13:00.000+02:00

Bonne nouvelle pour ServiceMix qui vient de recevoir pour son projet un outil de configuration graphique. Il est offert par la société française Bull pour contribution et participation au projet.
Cliquer ici pour voir l'annonce.

CIMERO est en version beta, il comprend :
- Un binding component pour se connecter à un fichier RSS
- Un binding component pour se connecter à un WebService (sm-http)
- Un binding component pour se connecter à un serveur Mail
- Un binding component pour se connecter à un serveur FTP
- Un service engine pour transformer un message (content transformer)
- Un service engine pour l'enrichissement d'un message (message enricher)
- Un service engine pour un message (sur base des propriétés ou sur base du contenu)

Bull annonce prochainement:
- Un binding component pour se connecter à un JMS server (sm-jms)
- Un binding component pour envoyer un message en entrée (timer)
- Un service engine pour décomposer un message (eip-splitter)
- Un service engine pour recomposer a message (eip-aggregator)
- Un service engine pour tracer un message (eip-wire-tap)
- Un service engine pour envoyer un message à l'écran

Vivement les nouveautés pour avoir une version complète et faciliter les développements.
Ceci est une bonne initiative de Bull car c'est ce qu'il manquait à Servicemix pour être concurrentiel avec les produits dits "propriétaire"propriétaire".

Cliquer ici pour accéder à une documentation.

Décision étonnante de Bull qui offre un bel outil à l'ESB d'Apache alors que Celtix et Petals sont en manque de ce côté là.

Que vont penser les membres de l'ESBi de cette décision? A suivre ... Je pense surtout aux projets Celtix et Petals.
Pour rappel ESBi est l'initiative d'Objectweb pour avoir une solution complète ESB/SOA afin d'avoir une offre - sur base de logiciels libres - concurrentielle sur le marché SOA. Bull est l'un des plus gros moteur de ce projet en venant avec son offre BSOA (Bull SOA) mais aussi au niveau d'Objectweb avec les projets JOnAS, Joram et bien d'autres ... ESBi intervient également dans les projets Eclipse SOA Tools Platform (STP) et Eclipse Web Tools Platform (WTP).

Suite ... Sécurité: Gestion des rôles

2006-05-14T12:18:00.000+02:00

Merci à ceux qui m'ont fourni l'info.

Sans le savoir, le modèle s'approche de celui du RBAC (Role Based Access Control) étendu à une entreprise intitulé EDAC (Enterprise Dynamic Access Control). Je pense après avoir parcouru la littérature que nous sommes avec ce modèle à la frontière du RBAC hiérarchique et du EDAC.

Voici les références qui m'ont été envoyées:

Cliquer ici pour ouvrir le document sur un case study avec EDAC.
Cliquer ici pour avoir un aperçu (fichier PDF).
Cliquer ici pour une présentation du projet IS@ de France Telecom.

Voici le site qui traite du sujet RBAC et ses variantes:

Cliquer ici pour ouvrir le lien du Centre de Recherche du NIST (National Institute of Standards of Technology)

Voici un modèle plus récent qui est utilisé dans le monde de la Santé et du Social:

Il s'agit du modèle Or-BAC. En recherchant sur internet, je n'ai pas trouvé de produit qui l'implémente.

Cliquer ici pour ouvrir le lien du site Orbac.org.

Sécurité: Gestion des rôles

2006-05-13T18:58:00.000+02:00

Ce document décrit les besoins fonctionnels d'un "role manager" intégré dans un IAM (Identity Access Management).

Cliquer ici pour l'ouvrir.

Ce document présente un modèle hiérarchique qui s'intègrerait facilement dans une solution technique autour d'un LDAP pour la gestion de services dans un ESB.

La particularité du modèle de données présenté est de proposer une solution de délégation de droit autour de rôles et de profils. Il répond à la lourdeur de gestion de la sécurité dans certaines sociétés qui doivent fournir des autorisations pour plusieurs dizaines de milliers d'utilisateurs.

Recommandations XML Schema

2006-03-21T08:56:00.000+01:00

Voici une recommandation sur la rédaction de fichiers XML Schema (XSD) que j'ai publiée pour le Belgif.

Cliquer ici pour y accéder directement sur Belgif.
Cliquer ici pour ouvrir la version PDF du 22.02.2006 .

Théorie sur les composants JBI

2006-03-20T11:31:00.000+01:00

Voici un lien sur un article écrit par Ron Ten-Hove (Sun Microsystems)
L'auteur a participé à la JSR-208 et maintenant il participe au projet OPENESB sur 'java.net'.

Cliquer ici pour ouvrir le document.

Architecture SOA

2006-03-10T10:10:00.000+01:00

Voici un document trés intéressant - écrit par Pierre Bonet d'Orchestra Networks - sur les concepts des architectures SOA.

Cliquer ici pour ouvrir le document "Cadre de référence Architecture SOA".
Cliquer ici pour ouvrir la partie 2 du document.

Suite à l'article "standards en vigueurs"

2006-01-09T15:43:00.000+01:00

Suite à l'article 'Les standards en vigueur', j'ai reçu deux liens trés intéressants.
Il s'agit :

du projet S2LOW : cliquer ici pour y accèder
de l'association ADULLACT : cliquer ici pour y accèder

Ces sites ont pour objectifs de définir les standards pour les institutions publiques et de proposer des alternatives 'libres'.

Merci encore pour les informations.

Les standards en vigueurs

2006-01-04T15:48:00.001+01:00

L'intéropabilité est le mot d'ordre pour celui qui développe sur un ESB. Mais voilà, quels standards appliquer? WS-I? OASIS? W3C? pas simple ...

Dans le domaine de l'e-gouvernement, l'interopabilité est également trés présente et c'est pourquoi un cadre d'intéropabilité a été défini entre différents pays. Il est donc une base tout à fait intéressante pour identifier les standards incontournables.

Cliquer ici : pour l'Europe (accessible via belgif)
(Cliquer ici pour le lien correct pour UK)

Cliquer ici : pour la nouvelle-zélande.
Cliquer ici : pour l'Australie

Dans les gouvernements belges et français, deux agences travaillent pour définir les standards des gouvernements français et belge. Il s'agit de :
FedICT (référence: portail fédéral belge)
ADAE (référence: adèle)

Sécurité des SOA

2005-12-13T09:23:00.000+01:00

La sécurité est un sujet trés important pour les systèmes d'intégration puisqu'ils peuvent ouvrir des portes sur le monde internet via des web services. Pour mieux appréhender la sécurité d'un tel système, Ahmed Alami présente en quelques pages une vue d'ensemble des différents points à considérer lors de la sécurisation des web services.
Lien vers Livre Blanc de la sécurité d'une SOA

Patterns d'intégration en entreprise

2005-11-28T15:58:00.000+01:00

Voici un lien des plus intéressants pour réaliser des architectures d'intégration:
Cliquer ici pour accéder à la page principale du site.
Cliquer ici pour accéder à la liste des composants patterns.
Cliquer ici pour voir un exemple complet d'architecture ainsi que sa réalisation.

Ces différentes pages sont basées sur un livre à mettre entre toutes les mains des architectes d'intégration. Il s'agit du 'Enterprise Integration Patterns' de Gregor Hohpe.

SOA vs JBI

2005-11-19T13:40:00.000+01:00

Voici comment une SOA peut-être implémentée sur une plateforme JBI:
Présentation de PaulCheung lors de la Java China 2005. Pour l'afficher cliquez ici
(attention le fichier est long à charger)

Présentation de la JSR 208 intitulée 'Java Business Integration' (JBI)

2005-11-17T02:41:00.000+01:00

Bibliographie

'Java Business Integration (JBI) Gains Industry Support' de Patricia Seybold Group

JSR-208 du Java Community Process(SM) Group

Article

Ci-dessous l'architecture 'high level' d'un environnement JBI telle qu'elle est décrite dans la JSR-208.

Vu d'un aspect de trés haut niveau, l'architecture JBI est basée sur deux concepts: les composants enfichables et la médiation de messages normalisés.

Les composants enfichables (pluggable components)

La plupart des scénarios aujourd'hui tournent autour de la transformation de protocoles et/ou de données ainsi que de leurs routages. Cependant les types de protocoles et les formats de données à traduire varient grandement. Le modèle JBI, et donc son architecture, a besoin de supporter une liste infinie de protocole et de service d'intégration. La solution de JBI est de proposer les composants enfichables. Ils sont de deux types: les services engines (composants utilitaires de transformation, de routages, d'enrichissemenents, d'orchestration, ...) et les binding components (composants qui relient l'environnement JBI et des composants externes).

Le médiateur de JBI (JBI mediator)

Les binding components et les services engines n'interagissent pas directement entre eux. Comme pour toutes les architectures stables, il y a un médiateur qui gèrera les intéractions entre les différents composants. Le médiateur est le routeur de messages normalisés (normalized message router: NMR). Ce dernier accepte les messages XML normalisés des binding components (déposés dans le normalized delivery channel) et invoque les services engines sur base de leurs WSDL (Web service description language). Voici un exemple présenté dans la JSR-208:
L'illustration ci-dessus montre un scénario d'envoi d'un datagramme (simple one-way message request). Ici le NMR reçoit un message d'un service engine qui l'a déposé sur son delivery channel. Il l'a redirige ensuite vers le delivery channel d'un binding component.

Conclusion

Les bases de l'environnement JBI, le framework de composants, le normalized message router, le WS-I binding, les outils de déploiement et les fonctions de gestion du bus correspondent fortement aux bases d'un ESB. Il est tout à fait normal de ce fait que les ESB commerciaux dans quelques semaines voire même dans quelques mois deviennent JBI compliant. Tous les ESB open source référencés dans le menu à droite de ce site sont déjà ou seront implémentés avec JBI.

Pourquoi un ESB?

2005-11-10T21:06:00.000+01:00

Dans les faits l'architecture ESB se verra utiliser pour exposer des webservices.
Mais ce n'est pas parcequ'on expose des webservices qu'il faut obligatoirement un ESB ...

Mais pourquoi alors faut-il un ESB?

Internet aujourd'hui est accessible par tout le monde, il est donc le support de communication idéal quand des entreprises veulent s'échanger des données. Cet avantage est aussi son inconvénient en terme de sécurité et de choix de protocoles. Les plus grands organismes (W3C et OASIS) dans le monde Internet nous conseillent les webservices (HTTP/SOAP) pour que les applications sur internet puissent se comprendre entre elles sans se soucier des types de plateforme et du langage utilisé. HTTP/SOAP est le couple idéal pour l'interopabilité mais l'expérience montre qu'il ne suffit pas. D'où l'utilisation du XML ... mais ne nous égarons pas ...
Les webservices sont donc juste un moyen (une façade) de communication. Ils vont permettre la communication entre une application demandeuse (consumer) d'information et une autre fournisseuse d'information (provider). L'entreprise qui implémentera le provider devra toutefois organiser ses applications en interne pour bien gérer sa maintenance, les versions, ses règles métiers, ses applications, sa sécurité ... Par exemple la difficulté d'une telle architecture est de minimiser l'impact des changements sinon une modification d'un web services nécessite une modification chez ceux qui l'utilisent. Pour faire court, un consortium des plus grands acteurs du marché de l'intégration ont réuni leurs idées et ont proposé l'"architecture orientée services" (SOA). OASIS a suivi le pas en proposant un modèle de référence comme standard SOA. L'implémentation technique d'une SOA signifie d'implémenter un "bus d'entreprise" (ESB).
Cette référence va permettre aux entreprises de profiter de l'expérience des autres en terme d'intégration de services pour bien implémenter leurs "architectures orientées services".

En résumé, parce que nous sommes sur internet, il faut des webservices pour communiquer. Les webservices seuls désorganisent et fragilisent les applications de l'entreprise. Il faut donc un ESB pour permettre un découplage trés fort entre les webservices et les applications en interne.

Wikipédia sur Enterprise Service Bus

2005-11-10T20:35:00.000+01:00

Cliquer sur les liens:
ESB sur le wiki en anglais
ESB sur le wiki en français

Voici un extrait: In computing, an enterprise service bus refers to a category of middleware infrastructure products or technologies, based on Web services standards, that enable a service-oriented architecture via an event-driven and XML-based¹ messaging engine (the bus). An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code.

Précision sur "based on Web services standards"

L'auteur a voulu signaler que les ESB se basent sur les standards des webservices pour leurs fonctionnements propres. Car ils sont capable de communiquer avec d'autres technologies que les webservices (http/soap).

PETALS: Article sur xmlfr.org

2005-11-10T15:53:00.000+01:00

Voici un article paru ce mercredi 09/11/2005 sur xmlfr.org.

Retrouvez cet article en ligne
(http://xmlfr.org/actualites/decid/051109-0001).

Donnez votre avis !

Objectif d'un ESB

2005-11-10T12:46:00.000+01:00

L'objectif principal d'un ESB est de permettre un couplage lâche (découplage fort) entre les différentes couches d'une architecture. La tendance actuelle est d'augmenter encore plus le découplage en utilisant un ESB pour découpler les différents composants métiers hostés dans différents containers. Le projet Petals services platform en a même fait un objectif à atteindre. Un article sur NewsForge intitulé ObjectWeb's Enterprise service bus initiative's le souligne par le paragraphe suivant:

Built on top of Celtix, the project adopts a highly distributed integration approach, in which many JBI containers running on different Java Virtual Machines (JVMs) achieve location transparency via a JMS based transport layer. In a next step, the platform is expected to provide specialized B2B bindings enabling organizations to expand their information systems beyond their physical and business boundaries.

L'ESB sera le bus d'échange entre les différents systèmes qui hostent les composants métiers des entreprises. Il va de soi qu'il est le mieux placer pour la communication entre les entreprises pour des échanges eBusiness.