L’émergence des services web pose plusieurs problématiques dont celle de la sécurité des échanges de messages entre partenaires. Dans une architecture Orientée Services, les services web peuvent exposer des processus métier sensibles qui nécessitent un traitement particulier en terme de sécurité aux deux bouts du canal de communication. En plus, les services web sont des technologies récentes, ceci implique de nouvelles vulnérabilités et attaques ou menaces.

Les solutions de sécurité des services web doivent prendre en charge les concepts suivants :

• L’authentification
• L’autorisation
• La confidentialité
• L’intégrité
• La non-répudiation

Les utilisateurs des services web doivent être identifiés soit via un nom d’utilisateur combiné à un mot de passe soit via un certificat digital. Une fois l’utilisateur identifiés, il doit posséder l’autorisation ou l’habilitation nécessaire afin d’effectuer le traitement qu’il a demandé. Toutes informations ou messages sensibles mis en jeu par le traitement doivent être confidentiels et ne doivent pas subir d’altération qui touche à son intégrité d’origine. Une fois le traitement exécuté, des mesures de non-répudiation doivent être mises en place afin d’éviter tout dénis des deux parts (consommateurs/fournisseur).

La définition d’une application Web repose sur la description du flot de données et du flot de contrôle unissant les Web Services auxquels elle fait appel. Comme dans le modèle des objets ou des composants logiciels, une application Web est « assemblée » à partir de Web Services techniques et métier. Dans le cas du Web, on parle de « composition », d’« orchestration » ou même de « chorégraphie » de services.

Plusieurs initiatives ont vu le jour qui visent à spécifier ces compositions sous forme de documents XML dont l’interprétation pilote alors directement l’exécution de l’application Web elle-même. Ces documents XML s’appuient sur WSDL pour la description des services mis en jeu dans l’application et détaillent la succession d’appels aux opérations qui y figurent en fonction des besoins de l’application. Trois DTD comparables ont été proposées pour les applications orientées workflow : XLANG par Microsoft, WSFL (Web Services Flow Language) par IBM et WSCL (Web Services Conversation Language) par Hewlett-Packard. Pour les applications Web transactionnelles, à caractère multi participant, BPMI.org met en avant BPML (Business Process Modelling Language), dont l’objectif est plutôt complémentaire, dont la déclinaison de juillet 2002, WSCI (Web Services Choreography Interface), s’applique à cette question.

WSFL, XLANG, WSCI et WSCL incarnent une vision des processus métier relativement statique, inspirée du domaine du workflow. De la même façon que dans une procédure de langage de programmation, un processus métier est considéré comme une succession d’appels à des opérations de Web Services. La définition du processus indique comment les données circulent d’un appel à l’autre, comment les arguments et les valeurs de retour d’une procédure transportent les données d’un appel à l’autre. Enfin, comme dans les langages de programmation, on trouve dans WSFL et dans XLANG des primitives de contrôles (boucles, tests, etc.). Ces DTD sont ainsi utilisées pour spécifier les relations contractuelles entre Web Services en mettant en œuvre des structures de contrôle et des flots de données explicites.

Lancée en juillet 2000 par la start-up Intalio, l’initiative BPMI (Business Process Modelling Initiative) est dédiée à la formalisation des processus métier des entreprises. Regroupant plus de cent cinquante sociétés dont Hewlett Packard, Sun, Nortel Networks, Avis, DHL, Intel, Siemens et SAP, ce consortium a publié la spécification BPML (Business Process Modelling Language). Les participants BPML sont les parties prenantes à un processus métier. Ce sont, pourrait-on dire, toutes les ressources disponibles de l’entreprise, humaines autant que matérielles et logicielles. Peuvent ainsi être considérés comme participants éventuels à un processus BPML aussi bien les utilisateurs du système d’information que les services, les bases de données et les applications du système d’information.

Cette spécification, plus générale que WSFL, WSCL et XLANG, s’intéresse à la représentation et à la gestion des processus métier intra- et interentreprises. Elle prend en compte, en particulier, des notions de transaction et de contrôle implicite de la succession des activités au moyen des données. Là encore, l’idée n’est pas nouvelle, mais elle acquiert une force toute renouvelée en raison du succès même du Web.
La représentation des processus métier des entreprises est depuis longtemps au cœur des évolutions des progiciels de type ERP (Enterprise Resource Planning) ou SCM (Supply Chain Management), souvent dans le contexte du système d’information clos de l’entreprise ou de celui, local, constitué par les partenaires les plus proches de l’entreprise. Un niveau d’abstraction supplémentaire est néanmoins requis pour capturer les complexités engendrées par le passage d’un contexte d’interactions locales à celui de relations au travers du Web. La spécification BPML répond à ces difficultés supplémentaires.

Ayant précédé et inspiré les efforts de recherche autour de WSFL et de XLANG, BPML s’appuie sur des notions métier comparables à certains des éléments que ces spécifications emploient. On y retrouve évidemment une conception du processus comme coordination d’un certain nombre de tâches, elles-mêmes exécutées par des acteurs échangeant des messages selon des protocoles de communication explicites. Mais alors que dans WSFL et dans XLANG l’accent est mis sur une conception de l’échange de messages finalement proche de l’appel distant (RPC ou invocation), BPML formalise les aspects plus complexes de la gestion et de la coordination de processus en abordant, au passage, des sujets comme les transactions (simples et emboîtées), la sécurité, la liaison dynamique avec les Web Services en cours d’exécution, etc. De plus, BPML marque une avancée importante dans la gestion du cycle de vie des processus métier de l’entreprise. Nommés, annotés, classés, contrôlés, dotés d’une gestion de configuration et de version, les processus BPML constituent véritablement le référentiel métier de l’entreprise, exploitable tant pour des solutions d’intégration d’applications d’entreprise que pour la publication de Web Services ou pour la participation à des applications Web réparties.
Le message BPML est «l’unité d’interaction» entre processus métier. Le processus métier BPML orchestre les échanges entre divers participants par la coordination de l’envoi et de la réception de message selon un jeu de règles explicites. Dans BPML, comme dans les protocoles de coopération (WSFL et XLANG), la communication entre les différents participants est véhiculée par des messages contenant des informations sous forme de documents XML. La réception des messages déclenche des opérations comme dans le modèle RPC d’utilisation de SOAP.

D’un point de vue technique, l’échange de messages est délégué à une couche de transport située hors du domaine de spécification de la norme elle-même. Ainsi, les messages BPML peuvent tout à fait être véhiculés par des Web Services de communication comme SOAP et BizTalk, par les protocoles standards du Web comme SMTP, MIME et HTTP, et par des middlewares traditionnels comme CORBA, DCOM et RMI.

La définition en BPML d’un processus commence donc par la description des messages échangés entre participants. Si ces messages sont propres à un participant donné, on trouvera ces descriptions dans l’élément XML des participants concernés ; sinon, dans celui du processus lui-même.

Les participants BPML sont les parties prenantes à un processus métier. Ce sont, pourrait-on dire, toutes les ressources disponibles de l’entreprise, humaines autant que matérielles et logicielles. Peuvent ainsi être considérés comme participants éventuels à un processus BPML aussi bien les utilisateurs du système d’information que les services, les bases de données et les applications du système d’information.

Les participants sont dits statiques si leur identité et leur comportement sont connus à l’avance et figés dans la description BPML du processus ; sinon, ils sont dits dynamiques. Les participants dynamiques permettent la prise en compte d’acteurs postérieurement à la phase de modélisation, dynamiquement découverts et mis en jeu au moment de l’exécution. Si, par exemple, de nouveaux Web Services se développent, ils peuvent s’intégrer comme participants dynamiques à des processus déjà modélisés et mis en place dans les entreprises sans causer de bouleversement important. Plus généralement, des participants identifiés seulement au moment de l’exécution peuvent se joindre dynamiquement à l’échange de messages sans qu’il soit nécessaire de revenir à une phase de modélisation.

Les activités, ou tâches, sont les « unités d’exécution », les opérations élémentaires d’un processus. Participants et processus sont représentés en BPML comme des activités productrices et consommatrices de messages. BPML fournit un langage de commande pour ordonnancer les activités (boucles, branchements conditionnels, etc.), ce qui le rapproche en cela des représentations en diagrammes d’états ou de workflow des méthodologies classiques.

BPML introduit une distinction entre trois classes d’activités :

Les tâches dites simples, soit une communication (synchrone ou asynchrone) avec un participant telle que la consommation ou la production d’un message (opération ou exception) ;

Les tâches dites complexes, composées à partir de tâches simples dont les messages sont visibles par tous les participants auxquels ils s’adressent ;

Les tâches dites de processus, affectant l’ordonnancement des autres tâches sans mettre réellement en jeu de participant. Ces tâches de processus peuvent, par exemple, déclencher l’exécution en série ou en parallèle d’autres tâches, des boucles et des branchements.

L’exécution parallèle des tâches autorisées par BPML est, en particulier, parfaitement adaptée au contexte transactionnel du commerce électronique.
Le régime de consommation et de production des messages, le choix des tâches de processus, la conduite à tenir en réponse à des erreurs ou des défaillances, est gouverné par les règles du processus. Les règles BPML suivent le format classique :

Si { conditions } Alors { actions }

Celles-ci sont exprimées en BPML sous la forme de conditions portant sur les données échangées entre participants (véhiculées par les messages) et celles éventuellement attachées au processus lui-même (comme des variables locales au processus). La partie « actions » des règles BPML déclenche d’autres tâches BPML. Un moteur de règles est chargé de choisir les règles candidates à exécution en fonction des données disponibles et de déclencher les tâches associées à la partie action des règles retenues – ce cycle s’appelle le recognize-act cycle. BPML définit un système de gestion des exceptions d’inspiration classique ajoutant un dispositif de récupération d’erreur au moteur de processus (balise onFault).

Toutes les activités de processus de BPML peuvent porter des attributs supplémentaires décrivant leur comportement dans un contexte transactionnel. Ces attributs spécifient si une nouvelle tâche est exécutée hors ou dans un contexte transactionnel et comment la nouvelle transaction éventuelle se rattache à la transaction tout aussi éventuelle de la tâche BPML précédente. Comme dans les services de transaction objet, les transactions BPML peuvent être emboîtées.

Une abstraction de processus est la description « non instanciée » des interactions entre un processus et ses participants. Dans une abstraction BPML, participants, activités et messages sont définis généralement, comme une classe dans un langage de programmation orienté objet définit une catégorie d’objets. Une exécution en est une instanciation, correctement paramétrée pour permettre l’exécution du processus. Les participants et les processus y sont uniquement identifiés et les messages transportent un contenu effectif. C’est, en quelque sorte, un cliché de l’image mémoire de l’exécution des processus décrits dans l’abstraction correspondante.

La distinction entre abstraction et exécution est identique à celle marquée dans WSFL entre processus (flow model) et contrat (global model). Elle permet de traiter, dans le même formalisme BPML, les processus individuels aussi bien que les classes de processus métier.

BPML est décliné en une norme spécifique restreinte au workflow : WSCI (Web Services Choreography Interface).

DSML est une spécification élaborée conjointement par IBM, Microsoft, Oracle, Novell et Sun, pilotée par la start-up Bow-Street, hébergée par OASIS, et dont la première livraison a été publiée en décembre 1999. DSML vise à donner dans un document XML une représentation standard de la structure des annuaires, indépendamment du protocole choisi pour extraire ces données de l’implémentation des annuaires. Les concepteurs de la norme réunissent les promoteurs des différents protocoles aujourd’hui disponibles : le standard LDAP, mais également les protocoles propriétaires antérieurs comme NDAP de Novell et l’API ADSI de Microsoft.

La spécification DSML permet de capturer dans un document XML de façon simple toute la structure d’un annuaire et éventuellement de son contenu. Cette description peut alors circuler sur le Web (via SMTP ou HTTP) et être échangée entre applications et Web Services pour faciliter la publication générale des ressources cataloguées à l’un des nœuds du réseau. Ces échanges peuvent employer SOAP ; une description BizTalk complète des schémas DSML est déjà fournie dans la version courante de la norme DSML simplifiant sa prise en compte sur BizTalk Server de Microsoft. Les scénarios d’usage que l’on peut évoquer sont, par exemple, celui d’un utilisateur de téléphone cellulaire ou de PDA (assistant numérique personnel) ayant besoin d’accéder aux coordonnées internes d’un collaborateur de l’entreprise sans client LDAP installé, ou encore celui de l’accès à un annuaire au travers d’un pare-feu ne laissant pas passer le trafic LDAP.

La gestion de l’accès, en aval, aux services et aux applications Web fait à son tour l’objet d’un effort de standardisation. Aujourd’hui regroupées sous l’égide du comité technique WSIA (Web Services Interactive Applications), animé par IBM, Epicentric, Netegrity/DataChannel au sein de l’OASIS, les premières contributions à des standards de services techniques furent livrées indépendamment mi-2001 par Epicentric, avec WSUI (Web Services User Interface), et par IBM, avec WSXL (Web Services Experience Language). L’accès en aval aux applications et aux Web Services regroupe, dans ces différents standards, tant l’accès direct par l’utilisateur aux services via un navigateur Web que la gestion de la syndication et de l’assemblage de services par différents intermédiaires avant l’interaction avec l’utilisateur final. Les deux scénarios ayant servi de base à l’élaboration de ces spécifications sont, d’une part, l’accès multicanal des utilisateurs aux Web Services (PC, PDA, téléphones cellulaires, etc.) et d’autre part, l’agrégation de Web Services sous une mise en page unique par un intermédiaire du canal de distribution – scénario du portail.

Considérons par exemple un éditeur de logiciels, spécialisé dans la représentation graphique de données financières, qui souhaiterait augmenter ses ventes directes en recourant à un nouveau modèle ASP de paiement via un hébergeur : le problème à résoudre est bien ici de ne pas multiplier les développements pour se trouver avec deux lignes de produits, chacune, de plus, risquant de « cannibaliser » l’autre. Idéalement, l’architecture de Web Services devrait, en effet, permettre de livrer le même service quel que soit le mode d’accès – direct ou indirect. De même, si notre éditeur souhaitait se doter de nouveaux canaux de distribution, en revendant, par exemple, son logiciel aux différents portails d’information boursière à un coût supplémentaire minimal, faudrait-il encore que son logiciel pût être facilement assemblé avec les autres constituants du portail en question. Cette problématique est d’ailleurs identique dans le cas du portail d’entreprise présentant sous une mise en page unique des fragments d’information extraits de sources diverses dans l’entreprise. Web et d’autre part, de présenter des informations à l’utilisateur et de réagir à ses commandes.

Les spécifications WSUI et WSXL cherchent à donner une représentation neutre, en XML, de la présentation des Web Services et des interactions avec leurs utilisateurs pour en simplifier l’agrégation et la syndication et en rendre aisée – voire automatique – leur adaptation à tel ou tel mode d’accès.

Principe :

UDDI (Universal Description, Discovery and Integration) est un standard qui a été proposé en septembre 2000 à l’instigation des sociétés Ariba, IBM et Microsoft, visant à établir un format d’annuaire des Web Services. C’est une architecture répartie qui permet aux fournisseurs de Web Services (Business providers), d’enregistrer leurs services, et aux applications de rechercher les services correspondant à leurs besoins, de façon normalisée.

Donc UDDI est un annuaire distribué de Web Services et d’entreprises (Business/Service Registry). Ces services d’annuaires stipulent comment rendre public les Web Services fournis par une entreprise, comment interroger ces annuaires pour découvrir les services demandés et, une fois découverts, comment les utiliser.

L’annuaire est logiquement centralisé mais physiquement réparti, il recueille les inscriptions des fournisseurs de Web Services et permet à un chacun d’effectuer des recherches pour y trouver les services particuliers dont il a besoin. Ces inscriptions et ces recherches peuvent être automatisées, par exemple en tant que fonctionnalités d’un moteur de recherches, ou manuelles. Dans ce dernier cas, inscriptions et recherches peuvent se réaliser au travers de sites UDDI gérés sous la responsabilité d’opérateurs UDDI. Ces sites opérateurs sont synchronisés entre eux selon un mécanisme de réplication pour former un unique annuaire logique. Les mécanismes internes de propagation et de réplication assurent la synchronisation des informations publiées entre sites opérateurs – ce même type de dispositif est employé, par exemple, pour remettre à jour les DNS (noms de domaine) d’Internet.

L’annuaire se comporte comme un Web Service, dont les méthodes sont appelées via le protocole SOAP. UDDI se compose de deux parties :

• L’UDDI Business Registry : annuaire d’entreprises et de Web Services;
  
• Les interfaces d’accès à ces annuaires, et les modèles de données.
  

Le noyau du projet UDDI est l’UDDI Business Registry, annuaire contenant des informations de trois types, décrites au format XML :

• Pages blanches : Noms, adresses, contacts, identifiants,… des entreprises enregistrées. Ces informations sont décrites dans des entités de type Business Entity. Cette description inclut des informations de catégorisation permettant de faire des recherches spécifiques dépendant du métier de l’entreprise;


• Pages jaunes : Détails sur le métier de l’entreprise, les services qu’elle propose. Ces informations sont décrites dans des entités de type Business Service


• Pages vertes : Informations techniques sur les services proposés. Les pages vertes incluent des références vers les spécifications des Web Services, et les détails nécessaires à l’utilisation de ces services : interfaces implémentées, information sur les contacts pour un processus particulier, description du processus en plusieurs langages, catégorisation des processus, pointeurs vers les spécifications décrivant chaque API. Ces informations sont décrites dans deux documents : un Binding Template, et un Technology Model (tModel).

Le fonctionnement est le suivant:
1. Les fournisseurs de Web Services s’enregistrent auprès de l’UDDI Business Registry (sur les pages blanches et jaunes) et ajoutent leurs services (en complétant les pages jaunes et en renseignant les détails techniques sur ces services dans les pages vertes). En principe, un seul enregistrement d’un service sur un référentiel est nécessaire. UDDI étant un service distribué sur Internet, toutes les actions sont automatiquement répercutées sur les autres référentiels.
2. Un utilisateur recherche une entreprise fournissant un service donné, et obtient une description de l’entreprise qui le fournit par le biais des pages blanches et jaunes, et des détails de l’invocation du service offert par le biais des pages vertes ;
3. L’utilisateur peut alors invoquer le Web Service distant en utilisant SOAP.

Introduction

WSDL (Web Service Description Language) pour les Web Services est l’équivalent de IDL (Interface Definition Language) pour la programmation distribuée (CORBA, DCOM). Ce langage permet de décrire de façon précise les Web Services, en incluant des détails tels que les protocoles, les serveurs, les ports utilisés, les opérations pouvant être effectuées, les formats des messages d’entrée et de sortie, et les exceptions pouvant être renvoyées. Il y eut d’autres tentatives de langages pour résoudre le problème de la définition des Web Services. Microsoft a d’abord proposé SDL (Service Definition Language) avec une implémentation fournie dans leur Toolkit SOAP, puis IBM a proposé NASSL (Network Accessible Service Specification Language), dont une implémentation est fournie dans SOAP4J. Microsoft modifia sa première spécification et proposa SCL (SOAP Contract Language), puis les différents acteurs s’accordèrent sur WSDL.

WSDL est vu comme une interface qui est le point d’entrée de n’importe quel Web Service: on y trouve la localisation du service, et les opérations qu’il est possible d’invoquer en utilisant SOAP.

Les Web Services servent surtout à l’intégration d’applications. Ils permettent d’exporter des applications existantes et de les rendre accessibles par le Web ou encore de créer de nouveaux composants que l’on peut appeler à partir d’autres applications.

Structure d’un document WSDL

Un document WSDL contient une ou plusieurs définitions de Web Services reprenant, pour chacun d’entre eux, les différents composants (types de données, messages, types de port, liaisons et ports). Il est également possible d’utiliser la balise pour fragmenter et rassembler les documents WSDL. Comme pour SOAP, la définition de WSDL mentionne des Namespaces de référence où se trouvent les définitions XML Schema des balises WSDL elles-mêmes.
Le squelette général d’un document WSDL est illustré par le schéma suivant :

On utilise un ensemble de balises pour définir un service, et ces différents paramètres (entrée et de sortie).

• definitions : C’est la racine de tout document WSDL. Cet élément contient la définition du service. Cette balise peut contenir les attributs précisant le nom du service, et les Namespaces. Elle contient trois types d’éléments :


• message et portType : Ces éléments définissent les opérations offertes par le service, leurs paramètres d’entrée et de sortie, etc. En particulier, un correspond à un paramètre d’entrée ou de sortie d’une . Un définit un ensemble d’opérations. Une définit un couple message entrée / message sortie. Par exemple, dans le monde Java, une opération est une méthode et un portType une interface.


• binding : Cet élément associe les à un protocole particulier. Les bindings possibles sont SOAP, CORBA ou DCOM. Actuellement seul SOAP est utilisé. Il est possible de définir un binding pour chaque protocole supporté.


• service : Cet élément précise les informations complémentaires nécessaires pour invoquer le service, et en particulier l’URI du destinataire. Un est modélisé comme une collection de ports, un étant l’association d’un à un URI.
  

Chaque élément WSDL peut être documenté à l’aide de l'élément . Cet élément contient des informations liées à la compréhension du document par les utilisateurs humains du service. Il est aussi possible de définir des types de données complexes dans une balise juste avant la balise .

Le Web Service est une fonction du Web qui prends des paramètres en entrée, communique et renvois un résultat.

Le « Web Service » repose sur deux entités fondamentales :

le Web et ses protocoles,

le format de donnée XML.

Il utilise l'architecture Web et les interfaces http, smtp, MIME, TCP/IP. Par dessus se grèfe les protocoles de bases tel SOAP qui gère la communication, WSDL qui lui gère la partie description du « Web Service ».

Introduction

Les Web Services sont des composants logiciels encapsulant des fonctionnalités métier de l’entreprise et accessibles via des protocoles standards du Web.
Un Web Service est décrit dans un document WSDL (Web Service Description Language), précisant les méthodes pouvant être invoquées, leur signature, et les points d’accès du service (URL, port, etc.). Ces méthodes sont accessibles via SOAP : la requête et la réponse sont des messages XML transportés par HTTP.
Un Web Service est accessible depuis n’importe quelle plate-forme ou langage de programmation.
On peut utiliser un Web Service pour exporter des fonctionnalités d’une application et les rendre accessibles via des protocoles standards. Le Web Service sert alors d’interface d’accès à l’application, et dialoguer avec elle au moyen de middleware (Corba, RMI, DCOM, EJB, etc.).

Les Web Services sont aujourd’hui associés à trois spécifications XML :

• SOAP : pour le transport des données et l’infrastructure de communication ;
  
• WSDL : pour la description des services offerts ;
  
• UDDI : annuaire pour le référencement des services par les fournisseurs et leur découverte par les utilisateurs.
  

Utilisation du Web Service

Les Web Services sont une nouvelle voie dans le développement des logiciels. En d’autre termes, les Web Services sont des composants logiciels qui peuvent cohabiter dans une application dans un réseau local ou Internet, et sont accessible par des applications tiers qui sont connectées à ces derniers. Les trois composants essentiels pour le fonction et l’interopérabilité de ces Web services sont les suivants :

Description des Web Service

Un Web Service a besoin d’être décrit pour autoriser des organisations de l’utiliser. WSDL est utilsé dans ce cas pour décrire un Web service. La description du Web Service indique les fonctions de ce service, comme les paramètres entrée/sortie et le protocole de transport.

Publication et découvert des Web Service

Une organisation a besoin de publier les Web Services qu’elle possède, pour les autres organisations pour qu’elles puissent les découvrir. Universal Description, Discovery and Integration (UDDI) sont utilisés pour publier les Web Services sur un dépôt central UDDI. D’autre organisations peuvent exécuter les opérations UDDI pour accéder au dépôt UDDI, et découvrir les Web Services qui les intéresse.

Web Service Invocation

Une fois l’organisation a découvert le Web Service via l’interface UDDI, et elle a prit la décision d’utiliser ce service dans son application, elle a besoin d’invoquer le Web Service. L’invocation d’un Web Service est faite via le protocole SOAP qui est implémenté au dessus du protocole HTTP.