WebServices

Un article de Agora2ia.


{{#subpages:}}


  • Ainsi, après avoir présenté les enjeux des Web Services, le fonctionnement de ses principaux composants sera expliqué, puis les atouts mais également les défauts des Web Services seront abordés.


Sommaire

Voir aussi

Présentation

Avec la popularité toujours plus croissante du langage XML, les Web Services apparaissent de plus en plus présents dans l'actualité. Le but de cet article est d'éclairer votre lanterne sur le sujet en expliquant et en commentant le fonctionnementdes différents composants de cette architecture. Tout d'abord qu'entend-t-on par Web Services ?

Il s'agit d'une technologie qui, utilisant intensivement le XML, permet à des applications de dialoguer à distance via Internet, indépendamment des plates-formes et des langages. Pour ce faire, les Services Web s'appuient sur un ensemble de protocoles standardisant les invocations de composants applicatifs.

Tout d'abord, le protocole SOAP (Simple Object Access Protocol), reposant sur XML, définit la structure des messages échangés via Internet par les applications offrant ou utilisant des Services Web.

Ensuite WSDL (Web Service Description Language) fournit un format de description des composants permettant d'invoquer leurs fonctions à distance par l'échange de messages au format SOAP.

Enfin, UDDI (Universal Description, Discovery and Integration) est une spécification définissant un annuaire d'entreprises basé sur le Web dont l'objectif est d'automatiser toute la procédure de recherche et de découverte des Services Web mis en ligne.

Les Web Services ont donc été conçus pour faciliter les échanges de données, mais aussi l'accès aux applications et devraient trouver de nombreux champs d'applications.


SOAP vs. RESTful

Sources :


SOAP

  • Simple Object Access Protocol
  • Developed at Microsoft in 1998
  • To be a platform and language-neutral alternative to previous middleware techologies like CORBA and DCOM
  • Versions : SOAP 1.0 (1999), SOAP 1.1 (2000), SOAP 1.2 (2005)
  • WSDL, XML Schema
  • XML (enveloppe, encoding rules and layouts of calls and responses)
  • Enveloppe sent on HTTP/HTTPS, puis RCP, enfin XML
  • Generic transport : HTTP/HTTPS mais aussi SMTP, JMS (alors que REST ne supporte que HTTP/HTTPS)
  • SOAP by itself is not that complex; it can get complex, however, when it is used with its numerous extensions (guilt by association).


Envelope

  • Header (optional)
  • Body (mandatory) : messages, fault
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Header>
      <!-- Header information here -->
  </env:Header>
  <env:Body>
     <!-- Body or "Payload" here, a Fault if error happened -->
  </env:Body>
 </env:Envelope>


Exemple

The request:

GET /StockPrice HTTP/1.1
Host: example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
    xmlns:s="http://www.example.org/stock-service">
    <env:Body>
      <s:GetStockQuote>
           <s:TickerSymbol>IBM</s:TickerSymbol>
      </s:GetStockQuote>
    </env:Body>
 </env:Envelope>

The response:

HTTP/1.1 200 OK
 Content-Type: application/soap+xml; charset=utf-8
 Content-Length: nnn
 
 <?xml version="1.0"?>
 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
    xmlns:s="http://www.example.org/stock-service">
    <env:Body>
      <s:GetStockQuoteResponse>
           <s:StockPrice>45.25</s:StockPrice>
      </s:GetStockQuoteResponse>
    </env:Body>
 </env:Envelope>


Avantages

  • Language, platform, and transport agnostic
  • Designed to handle distributed computing environments
  • Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
  • Built-in error handling (faults)
  • Extensibility

Inconvénients

  • Conceptually more difficult, more "heavy-weight" than REST
  • More verbose
  • Harder to develop, requires tools

Préconnisations

  • Asynchronous processing and invocation
  • Formal contracts
  • Stateful operations

RESTful

  • Representative State Transfer
  • From the famous thesis from Roy Fielding (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
  • Resources oriented (via URI)
  • REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1)
  • RESTful web services are much closer in design and philosophy to the Web itself.


HTTP     CRUD Equivalent
==============================
GET      read
POST     create,update,delete
PUT      create,update
DELETE   delete


Exemple

The request:

GET /StockPrice/IBM HTTP/1.1
Host: example.org
Accept: text/xml
Accept-Charset: utf-8

The response:

HTTP/1.1 200 OK
 Content-Type: text/xml; charset=utf-8
 Content-Length: nnn
 
 <?xml version="1.0"?>
 <s:Quote xmlns:s="http://example.org/stock-service">
      <s:TickerSymbol>IBM</s:TickerSymbol>
      <s:StockPrice>45.25</s:StockPrice>
 </s:Quote>


Avantages

  • Language and platform agnostic
  • Much simpler to develop than SOAP
  • Small learning curve, less reliance on tools
  • Concise, no need for additional messaging layer
  • Closer in design and philosophy to the Web

Inconvénients

  • Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
  • Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
  • Tied to the HTTP transport model

Préconnisations

  • Limited bandwidth and resources
  • Totally stateless operations
  • Caching situations


Conclusion

Traditionally, the big drawback of REST vis-a-vis SOAP was the lack of any way of specifying a description/contract for the web service. This, however, has changed since WSDL 2.0 defines a full compliment of non-SOAP bindings (all the HTTP methods, not just GET and POST) and the emergence of WADL as an alternative to WSDL. This will be discussed in more detail in coming articles.

But the untold story is that both technologies can be mixed and matched. REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.

Conclusion

Les Bénéfices techniques

L'architecture des Web Services est donc composée de différentes normes apportant de nombreuses fonctionnalités. Ainsi, sur le plan technique, les Web Services présentent certains atouts non négligeables.

Tout d'abord, leur intérêt, comme pour toutes les architectures à base de composant, est la flexibilité et la modularité, qui permettent une meilleure tolérance aux changements.

Ensuite, les Web Services utilisant les protocoles Internet pour le routage inter-applicatif, leur l'intégration apparaît moins "lourde" en terme d'infrastructure.

En ce qui concerne l'interopérabilité, celle-ci est largement facilité puisque les standards sont basés sur XML, donc sur des fichiers textes, ce qui facilite une grande indépendance par rapport à l'architecture machine, au système d'exploitation et au langage utilisé.

Ces 2 derniers points en font des atouts considérables par rapport aux autres architectures logicielle surtout que l'intégration basée sur les Web Services a l'avantage d'être complémentaire d'une intégration basée sur un modèle objet.

Enfin, les standards des Web Services ont été conçus pour être indépendants les uns des autres ce qui peut faciliter leur adoption progressive.

Les problèmes à résoudre

Les Web Services formant une technologie jeune, ils présentent les principaux défauts de la jeunsess.

Tout d'abord, le premier problème réside dans la gestion de la sécurité des échanges. En effet, même si SOAP a été conçu pour pouvoir être encapsulé dans des protocoles comme SSL, les systèmes de login/password, de signature numérique ou de clé publique/clé privée doivent être fait au niveau applicatif même si de nouveaux standards tels que AuthXML, XML Digital Signature ou encore XKMS sont en train d'émerger et seront bientôt susceptibles de combler ces lacunes.

Ensuite, rien n'a encore été prévu pour ce qui concerne la qualité de service même si certaines entreprises comme par exemple IBM avec WSEL (Web Service Endpoint Language), s'attachent à définir de nouveaux langages prenant en compte les aspects externes du comportement d'un Web Service tels que le coût, la disponibilité, la sécurité, ...

La gestion des transactions, quant à elle, ne repose actuellement que sur les couches sous-jacentes. Cependant, des initiatives comme BTP (Business Transaction Protocol) du consortium pour les standards e-business OASIS (Organisation for the Advancement of Structured Information Standards) ou encore XLANG de Microsoft et toujours WSEL de IBM sont assez avancées et devraient résoudre ce problème à l'avenir.

Enfin, un des problèmes majeurs concernant les Web Services se situe au niveau des débits Internet actuels qui ne permettent pas encore aux entreprises d'envisager une banalisation de l'utilisation des Web Services. Mais ce problème devrait progressivement s'estomper avec la généralisation du haut débit.

En résumé

Les Web Services représentent une technologie ayant pour enjeux et domaines d'applications, entre autres, le renforcement de la collaboration entre les entreprises, l'apport de nouvelles sources de revenus et l'optimisation des processus de gestion. L'architecture sous-jacente, permettant une interopérabilité entre des applications, est basée principalement sur SOAP, WSDL et UDDI. Mais il y a également de nombreux autres standards (qui sont autant de dialectes XML) en cours de réalisation afin de compléter cette architecture notamment au niveau de l'authentification, de la définition de processus métier, ...

Comme nous avons pu le voir, tant au niveau des concepts qu'au niveau des outils techniques, il n'y a rien de nouveau avec les Web Services. En effet, l'un des composants principaux, SOAP, permet d'établir un protocole de communication basé sur XML et principalement HTTP. Ensuite, WSDL n'est qu'un langage de description d'interfaces basé toujours sur XML et qui permet au client de connaître des informations suffisantes afin d'utiliser un service. Enfin, le principe d'annuaire (avec UDDI), qui permet d'accéder à des services, n'est pas nouveau non plus. Les Web Services rejoignent de ce fait des technologies existantes telles que CORBA ou COM/DCOM par exemple. Malgré tout, le principal atout de cette architecture par rapport aux autres se situe au niveau de l'utilisation des protocoles Internet existants qui implique, notamment, une simplicité d'intégration et une base commune pour tout type d'échanges inter-entreprises que le manque de maturité actuel de la technologie des Web Services ne ralentira sans doute pas.



Programez ! n° 69 (Septembre 2008)

WS : Entre éxistant et architecture

  • La mise en place de Web Services (WS) implique d'utiliser une couche d'abstraction, ce qui prépare les évolutions.
  • Les WS impliquent donc de repenser l'architceture complète de l'application, avec éventuellement une SOA.
  • Les WS sont orientés services métier.

Cela permet de centrer l'application sur les besoins fontctionnels et non techniques.

L'Architecture Orientée Service (SOA) :

  • n'est pas un concept nouveau,
  • tout au plus le nom est nouveau.
  • La logique métier priviliégiée
  • et les fonctions sont découpées en services (dits "métiers").
  • Apparait alors la notion de consommation de service (par un tiers).
  • Pour l'orchéstration, la SOA s'appuie sur des standars (les WS par exemple).
  • Il existe une couche d'abstraction.
    • Les inconvénients :
      • Peut nuire aux performances.
    • Les avantages :
      • Mais offre une grande souplesse, car décorélation entre le front et le back
      • Couche de communication homogène, standard, ouverte.

Mais cela nécéssite une analyse rigoureuse préalable de la logique métier :

  • Contenu des messages,
  • Flux des données,
  • Quoi exposer ?

Les outils :

  • WebLogic 8/9 - Beehive,
  • IBM Websphere 6, - Atlantic,
  • Microsoft Net,
  • Autres (Borland , Compuware, WebMethod).

Hélas, WS est actuellement un service technique, et non métier.


WS et Legacy

Le couplage mou des WS permet de reprendre tout ou partie (à définir en fonction du besoin) de l'existant en back et d'utiliser des technologies récentes (standards...) pour linterface.


WS et EAI

WS est un standard (XML) ouvert et uniforme (Soap), à l'exposition contrôlée (WSDL) face aux EAI, souvent propriétaires et lourds (nombre de connecteurs...).


Limite des WS

En contexte lourd et complexe, les WS :

  • Sont des standards peu ou pas matures,
  • Possèdent des faiblesses pour l'orchéstration et les transactions
  • Impliquent de ne pas négliger les performances.

Abréviations

BTC Business Transactions Committee
COM/DCOM (Distributed) Component Object Model
CORBA Common Object Request Broker Architecture
ERP Enterprise Resource Planning
HTTP HyperText Transfer Protocol
J2EE Java 2 Platform Enterprise Edition
OASIS Organization for the Advancement of Structured Information Standards
JWS Java Web Service
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SunONE Sun Open Net Environment
UDDI Universal Description, Discovery and Integration
WS Web Services
WSDD Web Service Deployment Descriptor
WSDL Web Service Description Language
WSEL Web Services Endpoint Language
WSTK Web Services Tool Kit
XKMS XML Key Management Specification
XML eXtensible Markup Language

Ressources

Web

Livres