Thinkervine » XML

SOA explained

fays — Mon, 09 Apr 2007 19:42:00 +0000

Don’t do anything. ‘SOA’ may have meant something once but it’s just vendor bullshit now. – Tim Bray, Director of Web technologies, Sun Microsystems

La SOA (Service Oriented Architecture) représente depuis quelques années l’un des principaux maux de tête des DSI, des architectes, des éditeurs et des sociétés de conseil. Gartner prévoit que 80% des projets informatiques seront basés sur la SOA en 2008. Aujourd’hui, 40% des entreprises démarrent des projets dans ce même sens. Cependant, on trouve difficilement une définition communément admise de la SOA.
Je me propose d’être votre guide afin de mieux appréhender cette notion plus ou moins obscure. Nous vulgariserons l’ensemble des concepts au delà des aspects techniques (qui ne seront pas traités dans cet article).

Selon Gartner :

Developers will shift their focus to business processes and away from software functionality. In turn, software will become a facilitator of rapid business change, not an inhibitor. The value creation in software will shift to subscription services and away from packaged software, and to composite applications (i.e., best of breed) and away from monolith suites.
By 2006, more than 60 percent of the $527 billion market for IT professional services will be based on Web services standards and technology. By 2008, 80 percent of software development projects will be based on SOA. The distinction between software integrators and vendors will blur as packaged applications are broken apart and delivered as service-oriented business applications.

Le mot architecture peut prendre différents sens. Il peut représenter d’une part une description d’un système (image d’un environnement à un instant donné) ou représenter l’acte de conception, ce qui implique une notion de mouvement. Dans chacun des cas, on peut faire un parallèle avec les différentes notions autour de la SOA, selon que l’on parle de technologie ou de méthodologie.

L’OASIS définit la SOA comme suit :

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Si l’on suit cette définition, la SOA serait donc un paradigme. Elle n’est ni technologie ni méthodologie, mais une manière de concevoir des composants distribués réutilisables offrant un certain nombre de possibilités (exposition, découverte des services, consommation des services..).

Ainsi on en vient à la définition de la SOA comme étant une architecture applicative utilisant des composants logiciels (services) autonomes, réutilisables, faiblement couplés, exposés (par des fournisseurs) et consommés par des utilisateurs (appelés consommateurs) afin de répondre à des besoins spécifiques métier.

Le principe consiste à réutiliser un composant existant exécutant une fonctionnalité métier (eg. virement bancaire), et de le doter d’une interface de communication basée sur des standards. Ce dernier est référencé dans un annuaire ou un dépôt de services (Enterprise Services Repository) de manière à ce que l’on puisse le retrouver de manière simple à travers la phase de découverte puis d’y faire appel (consommation).

L’idée derrière ce concept est de s’éloigner des solutions orientées technologies pour pour privilégier une orientation métier centrée sur les processus. En se concentrant sur ces services, les applications sont agrégées pour répondre à des besoins opérationnels de manière plus significative et en alignement avec les objectifs de l’entreprise.

Une application ne pourra jamais répondre à elle seule à tous les besoins de l’entreprise. Il y’aura toujours des fonctionnalités manquantes, ansi une entreprise aura nécessairement besoin de plusieurs applications pour mettre en oeuvre ses processus opérationnels.

Au sein de ces différentes applications, nous identifierons les différentes fonctionnalités utilisées pour exécuter un processus et les exposerons, elles deviendront alors des services, représentant une vue logique de la part des utilisateurs. Ces services seront alignés de manière plus fidèle aux processus opérationnels éliminant ainsi les limitations des entreprises qui étaient contraintes d’adapter leur vision à la technologie. Par ailleurs, cette notion de services prend un sens plus large lorsqu’elle intègre des opérations effectuées auprès des partenaires et fournisseurs en les incluant de manière totalement transparente dans la chaîne d’opérations (et donc dans le processus), à moindres coûts.

L’étape suivante consiste à définir les interactions entre les différents services, ce que l’on appelle l’orchestration de services (à travers un BPMS*). Cette orchestration consiste à décrire la manière dont les services font appel les uns aux autres afin de respecter le déroulement et les contraintes des processus d’entreprise.

Les architectures orientées services ne sont pas une invention récente, les principaux travaux remontent aux années 90. Cependant, la maturité nécessaire à leur exploitation en terme de technologie et de méthodologie n’est atteinte que depuis 3-4 ans, grâce notamment aux standards d’interopérabilité (XML, Web services).

La SOA vise à améliorer le rapport d’alignement entre l’IT et le métier, à répondre aux besoins des entreprises en terme de TCO (Total Cost of Ownership) en réduisant les coûts de développement, déploiement, intégration et de maintenance, tout en leur offrant une grande agilité dans la définition de leur business process et leur implémentation dans le système d’information et la capacité d’élargir le champ d’application des processus métier de manière transverse à travers différents silos applicatifs.

A ce titre, on devrait voir apparaître des réorganisations au sein des DSI. De nouveaux périmètres de responsabilité apparaîtront et seront axés autour des processus, ces derniers seront supervisés par un BPX (Business Process Expert dont le rôle sera de formaliser le processus en utilisant le SI comme moteur d’innovation) et un responsable IT (chargé des applications au sein desquelles est exécuté le processus).

Afin de définir l’ensemble des périmètres, d’identfier les intervenants ainsi que les besoins en termes de ressources et des services à exposer, il convient de suivre une méthodolofie d’analyse selon une approche top-down, telle que décrite ci-dessous :

Dans cette démarche, le contexte est défini par les objectifs stratégiques énoncés par la direction. Ces derniers donnent lieu à la mise en place de différents processus métier afin de guider le travail de ses employés en conformité avec la stratégie préconisée. A ce niveau là, il faut identifier l’ensemble des fonctions auxquelles l’on a recours afin d’éxecuter un processus ainsi que les KPI (Key Performance Indicator) à observer. I faut arriver à un découpage de ce processus en étapes de manière à obtenir une granularité assez fine tout en conservant un degré de pertinence légitime. Cette étape est particulièrement sensible et doit faire l’objet de la plus grande attention. Elle nécessite un travail conjoint des experts BP et IT en concertation avec les responsables du métier et des key-users. Si à ce stade notre analyse n’est pas suffisament cohérente, cela peut avoir un impact négatif sur la suite du projet et notamment lors de la définition des services.

Une fois les fonctions identifiées, il faut se reporter au parc applicatif afin de déterminer l’ensemble des logiciels qui fournissent ces services, déterminer les flux qui transitent entre eux, les types de données ainsi que l’endroit où ces dernières sont stockées. Cette étape est aussi sensible que la précédente du fait qu’elle va nous permettre de définir le processus de ré-urbanisation, d’identifier les services et de les exposer, de créer un entrepôt unique pour les données maîtres (Master Data Management) et de mettre en place une plateforme d’intégration et un catalogue de services (UDDI) afin de pouvoir composer aisément les services au sein d’une application composite tierce de type portail ou mash-up.

L’intérêt des architectures orientées service réside dans différents facteurs:

Alignement IT et Business
Agilité de l’entreprise à travers la fluidité de ré-aménagement de ses processes métier
La réduction de la complexité du système d’information (centralisation des flux, des données)
La réutilisation des services développés au sein de l’ensemble des applications qui pourront y faire appel. De plus grâce aux principes d’interopérabilité, les applications deviennent totalement indépendantes de la technologie sous-jacente. Elles communiquent entre elles à travers des interfaces faisant appel à des protocoles standards.
L’utilisation du legacy software et de son intégration avec les nouvelles technologies mises en oeuvre. Il n’est nul besoin de renouveler totalement son parc applicatif. La SOA constitue une évolution et non une révolution.
Une amélioration de la gouvernance des systèmes d’information, une réduction du TCO et une augmentation du ROI (Return On Investment)

Ici se termine ce premier article. Nous aborderons les aspects techniques ainsi qu’une analyse plus approfondie de la business value dans de prochains articles.

* BPMS : Business Process Management Suite

Microsoft ouvre Office XML Reference Schema

fays — Wed, 30 Nov 2005 01:29:15 +0000

Alors que Google s’allie à Sun (et recrute plusieurs dizaines de développeurs pour améliorer la suite OpenOffice), Microsoft décide de contre-attaquer en rendant public le schéma XML des documents Office, autrement dit, le format des fichiers Office.

Le géant de Redmond a annoncé qu’il soumettrait bientôt son schéma de référence XML décrivant le format de fichiers Office à l’ECMA (organisme de standardisation) ainsi qu’à l’IOS (Internation Organization of Standardisation). Les schémas seraient mis publiques sous une licence qui permettrait de développer des applications qui pourront les lire et les écrire sans risque de poursuite de la part de Microsoft. Malgré certaines conditions pas tout à fait claires quant aux conditions juridiques selon lesquels Microsoft se reserverait le droit d’engager des poursuite, il est clair dans quels cas elle ne le ferait pas. Ainsi un développement d’application gérant les documents office de manière similaire ou supérieure à Microsoft Office ne risque absolument aucune représaille.
Cette initiative s’inscrit dans l’intention de Microsoft de combattre son nouvel adversaire Google (ainsi que le format ODF qui menace la suite MS Office) qui fait trembler la Silicon Valley ainsi que toutes sortes d’entreprises sur lesquelles il a empiété (Comcast, ebay, amazon…). Cette décision a surement été catalysée par la décision du Commonwealth of Massachusetts d’adopter l’ODF comme standard pour leurs documents électroniques.
Microsoft tente de racheter son image en s’ouvrant au monde du logiciel libre ou open source, même si aucune avancée n’est encore faite dans ce sens, de petits pas sont faits. On parle d’une version de Windows gratuite (sous réserve d’accepter un peu de pub), un premier pas a été fait en ouvrant C# (part de la technologie .NET)… Jusqu’où Microsoft ira-t-elle afin de se maintenir ?

Evaluation and Report Language

fays — Fri, 15 Jul 2005 17:42:02 +0000

EARL (Evaluation and Report Language) est un meta-langage permettant de rapporter les résultats des tests, des rapports de bugs ou tests de conformité d’une entité quelconque (site web, outil de publication, un navigateur…), EARL est construit de manière à être totalement flexible. Il permet à une organisation, une entité ou une personne de tester n’importe quoi et d’exprimer les résultats de manière standardisée.

Un rapport EARL contient les informations suivantes suivies du rapport de tests:

Les informations du contexte : Elles contiendront les informations à propos de qui a effectué les tests en utilisant quoi, la date d’éxecution des tests ainsi que d’autres informations jugées pertinentes
Le sujet du test : pages webs, outils, navigateur…
Le résultat : le sujet a-t-il réussi le test ou pas ? A quel pourcentage ?
Les critères de test : Selon quels critères est ce que l’on effectue ces tests (règles, normes…)

Exemple
Context
Fayçal Chraibi a effectué le test du module PEAR Text/Highlight
Test Subject
Application web visant à colorer un fichier source.
Test Result
Réussi
Test performed
Les entités ont été colorées en accord avec leur nature

         xmlns:earl="http://www.w3.org/WAI/ER/EARL/nmg-strawman#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:foaf="http://xmlns.com/foaf/0.1/"
         xmlns:owl="http://www.w3.org/2002/07/owl#">

    Confidence Level
    Level of confidence in the given result


        High Confidence
        Validity of the result is certain


        Medium Confidence
        Validity of the result is not sure


        Low Confidence
        Validity of the result is questionable

EARL utilisera les normes RDF

EARL sera un grand apport dans le domaine du développement logiciel dès lors que les résultats des tests seront standardisés, ainsi l’on pourra identifier de manière aisée les différents problèmes dans un rapport de bug ou suite à une batterie de tests .
Jusqu’ici, les rapports d’erreurs contenaient des formats aussi divers que l’imagination des développeurs pouvaient s’étendre, il était difficile de mettre en place des outils d’analyse performants qui nous donneraient ces informations et encore moins de manière standardisée. Nous voici donc enfin en phase de passer à une nouvelle phase dès lors que le schéma E
ARL sera validé par le W3C