Approches technologiques pour la construction des ... - Microsoft

farmacridInternet και Εφαρμογές Web

2 Φεβ 2013 (πριν από 4 χρόνια και 9 μήνες)

135 εμφανίσεις









Approches technologiques pour la
construction des systèmes connectés

Version
1.
0
1

Publication :
Juillet

200
8

Auteur

: Philippe Beraud


Copyright

© 2008
Microsoft Corporation
.
Tous droits réservés.

Résumé

Ce livre blanc permet de mieux appréhender

les différentes approches en termes de
construction des systèmes connectés
.

Dans ce cadre, le document revient
sur les

d
ifférentes
initiatives,
et

standards
et
met en
évidence les
axes d’interopérabilité
.
La
construction des systèmes connectés

repose
aujourd’hui très largement sur les standards de la pile protocolaire WS
-
* adoptée
majoritairement par les différent
s acteurs. Ces standards sont par ailleurs complétés par des
profils d’interopérabilité
.




© 2008 Microsoft Corporation. Tous droits réservés.

Les informations

contenues dans ce document représentent le point de vue
actuel de Microsoft Corporation sur les sujets traités à la date de publication.
Etant donné que Microsoft doit s’adapter aux conditions changeantes du
marché, ces informations ne doivent pas être in
terprétées comme un
engagement de la part de Microsoft, et Microsoft n’est pas en mesure de
garantir l’exactitude de toute information présentée après la date de publication.

MICROSOFT NE DONNE AUCUNE GARANTIE EXPRESSE OU IMPLICITE
DANS CE DOCUMENT.

Les au
tres noms de produits ou de sociétés cités dans ce document peuvent
être des marques de leurs propriétaires respectifs.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052
-
6399 • Etats
-
Unis


Approches technologiques pour la construction des systèmes connectés


i

Sommaire


1

CONSTRUIRE LES SYSTE
MES CONNECTES

................................
................................
.......
1

2

ARCHITECTURE ORIENTE
E SERVICES

................................
................................
.................
3

3

UN BREF RAPPEL DES F
ONDEMENTS DES SERVIC
ES WEB

................................
............
4

3.1

P
ROTOCOLE DE COMMUNIC
ATION STANDARD

................................
................................
......
4

3.2

F
ORMAT DE REPRESENTAT
ION DE DONNEES STAND
ARD

................................
.......................
4

3.3

L
ANGAGE DE DESCRIPTIO
N STANDARD
WSDL

................................
................................
.....
4

3.4

M
ECANISME DE DECOUVER
TE STANDARD

................................
................................
............
5

4

ARCHITECTURE DES SER
VICES WEB

................................
................................
..................
6

4.1

E
LEMENTS FONDATEURS

................................
................................
................................
....
6

4.2

P
R
OCESSUS D

ELABORATION DES SPEC
IFICATIONS

................................
..............................
8

4.3

N
IVEAU D

ADOPTION PAR L

INDUSTRIE

................................
................................
..............

13

5

POUR EN SAVOIR PLUS…

................................
................................
................................
...

16




Approches technologiques pour la construction des systèmes connectés


1

1

Construire les systèmes connectés

La construction de systèmes connectés ne constitue pas une nouveauté en soi. Durant les 25
dernières années, de nombreuses méthodes et technologies ont été utilisé
e
s pour résoudre les
problèmes d’interopérabilité au sein d’une organisation et pour connecte
r cette organisation à ses
partenaires.
L’interopérabilité

se définit simplement comme la possibilité pour des
systèmes, des composants et des services d’échanger des données et de l’information

: en
d’autres termes de «

se parler

».

Fort de cette définit
ion
simple
de l’interopérabilité

(nous ne rentrerons pas ici car tel n’est pas le
propos dans une définition plus approfondi
e

de l’interopérabilité)
, 2 systèmes techniques ou
économiques sont
interopérables

s’ils peuvent collaborer sans se connaître intime
ment :



Utilisation uniquement d’
échanges par messages,
au moyen d’un

transport partagé,
suivant une
«

écriture

»

(schéma) partagée,



Sans préjuger lors de l’échange

: du contexte, de l’interlocuteur, de l’implémentation du
service demandé.

Diverses tentat
ives ont été menées dans le domaine de l’échange de documents.

Ainsi,

la
technologie EDI
(
Electronic Documents Interchange

en anglais)
, technologie mise en
œuvre par certaines grandes entreprises (en tant qu’acheteur ou fournisseur), visait à remplacer
des millions d’échanges de documents papier par des transactions électroniques.

Cependant, les promesses de l’EDI n’ont pas été complète
ment tenues dans la mesure où les
solutions EDI résultantes ne sont pas extensibles, pas assez flexibles et ne peuvent donc pas être
généralisées à toutes les communications inter entreprises

: elles s’adressent avant tout à des
scénarios B2B
(
Business to
Business

en anglais
)
de type faible

volume et messages volumineux.

L’intégration des applications internes (
Enterprise Application
Integration

en anglais
ou
EAI

en
abrégé
), la communication entre
machines

ou
homologue à homologue

(
«

Peer to Peer

»

en
angla
is
), etc. constituent autant de périmètres non couverts.

Par ailleurs, les applications n’ont pas totalement éliminé le travail manuel nécessaire au traitement
complet des documents. En fait, au lieu de réduire leurs ressources, certaines entreprises ont é

contraintes de recruter des équipes pour traiter les documents reçus dans le cadre d’un processus
manuel. Par ailleurs, les faibles améliorations de productivité et le coût additionnel induit par
l’utilisation de réseaux spécialisés et de solutions EDI
particulières ont empêché les entreprises de
petite et moyenne
taille d’utiliser l’EDI pour connecter leur entreprise.

Cette incapacité à couvrir toute la chaîne de valeur, le manque de

flexibilité et le coût de mise
en
œuvre et de fonctionnement ont empê
ché l’EDI de devenir la méthode de connexion entre tout
type d’entreprise, sur tout type d’industrie et sur tout type d’interaction.

Sur la fondation

XML (
Extensible Markup Language
), recommandation du W3C (
World Wide Web
Consortium
) et langage universel d
e représentation de données, plusieurs modèles d’intégration
ont émergé. XML permet à des systèmes hétérogènes de s’échanger des données
indépendamment des systèmes d’exploitation, langages de programmation, base de données ou
serveurs d’application utilis
és et a donc fait rapidement son chemin comme standard de
représentation de données pour l’entreprise.

Ainsi,
ebXML

(
electronic business XML

en anglais)
, projet commun entre UN/CEFACT (
United
Nations Centre for Trade Facilitation and Electronic Business

en

anglais
)
et l’OASIS (
Organization
for the Advancement of Structural Information Standards

en anglais
)

avait pour objectif de délivrer
une série de spécifications destinées à faire évoluer l’EDI vers une infrastructure basée sur XML.
Remplissant son cahier

des charges initial, ebXML a effectivement délivré un socle suffisamment
solide (exception faite de la sécurité) pour utiliser XML dans les scénarios B2B de type faible
volume et messages volumineux.

Cantonné
cependant
au seul support des scénarios type E
DI, ebXML échoue dans la réponse au
besoin de généralisation des échanges par messages

; ceci constitue aujourd’hui la principale
barrière à son adoption en dehors des marchés de niche de l’EDI.


2

Approches technologiques pour la construction des systèmes connectés


En effet, le

protocole
ebXML Messaging Services

(ebMS

en abr
égé
)
dans ces versions
successives 1 et 2
n
’est
pas conçu pour embrasser la diversité des scénarios à prendre en compte
comme le soulign
e le Gartner dans son
rapport
D
IFFERENT
G
OALS
M
EAN EB
XM
L

I
S
N
OT A
R
IVAL TO
W
EB
S
ERVICES
1

:

«

All organizations should emphasize development and implementation of Web services as a
primary vehicle for IT transformation. Organizations and vendors that engage in business
-
to
-
business collaborative commerce should not view ebXML as a substitute for Web

services, but
as a work
-
in
-
progress with limited focus and international implementations that are currently
limited.

»

Partageant apparemment ce constat, l’UN/CEFACT a terminé ces travaux sur ebXML et se
concentre à présent sur les services Web.


L’
article
UN/CEFACT

A
NNOUNCES
C
OMPLETION OF EB
XML

T
ECHNICAL
S
TANDARDS
W
ORK
P
ROGRAM
WITH
OASIS
2

rapporte ainsi les propos de Klaus
-
Dieter
Naujok
, précédemment
P
résident du projet
ebXML

:

«


Going forward we expect to make use of much of our ebXML technical work ...We hope to
use the newly established liaisons with the OASIS Business Process Execution

Language
(BPEL) Technical Committee (TC), plus the Web Services Interoperability Organization (WS
-
I)
and our UN/CEFACT Techniques and Methodologies Business Process Working Group to
align our efforts, and eliminate duplication of work.

»

Toutes ces tentat
ives n’ont finalement intégré que la première dimension d’une autre approche
pour atteindre l’interopérabilité
, à savoir l’échange par messages, par un moyen de transport
partagé, suivant une écriture (schéma) partagée. La seconde dimension qui ne préjuge
en rien de
l’échange et du modèle de communication entre les systèmes a été occultée (partiellement ou
totalement).

Ceci nous amène à imaginer de créer l’interopérabilité entre l’existant et le futur à travers
une approche orientée services (
Service Orient
ed Architecture

en anglais
ou SOA

en
abrégé
) en visant l’utilisation d’interfaces orientées messages, sans état. On rentre ainsi
pleinement dans
un «

monde de

protocole

».




1

Rapport
D
IFFERENT
G
OALS
M
EAN EB
XML

I
S
N
OT A
R
IVAL TO
W
EB
S
ERVICES

:

http://www.gartner.com/DisplayDocument?id=408059

2

Article

UN/CEFACT

A
NNOUNCES
C
OMPLETION OF EB
XML

T
ECHNICAL
S
TANDARDS
W
ORK
P
ROGRAM WITH
OASIS

:
http://www.webservices.org/categories/technology/ebxml/un_cefact_announces_completion_of_ebxml_technical_standa
rds
_work_program_with_oasis/(go)/Articles


Approches technologiques pour la construction des systèmes connectés


3

2

Architecture Orientée Services

Le principe fondateur d’une architecture orientée services réside dans l'idée que des
systèmes, logiciels, périphériques mobiles et services «

dialoguent

» ensemble
-

même si
ces derniers n’ont jamais été spécifiquement conçus en premier lieu les uns pour
les autres
et
s’articule autour de 4 piliers

:

1.

Autonomie



L’autonomie se définit comme la « liberté de gouverner par ses propres lois,
indépendance, possibilité de disposer librement de soi ». Les services sont autonomes
dans leur finalité et leur exécuti
on. Un service ne doit pas avoir de dépendance forte vis
-
à
-
vis d’autres services, sinon on aboutit à un système fortement couplé qui est fragile et
complexe.

Un service est conçu, développé, déployé et géré comme isolé, indépendant des autres et
interchangeable. Il fournit des fonctionnalités directement utilisables, indépendamment
d’autres systèmes. Les services doivent maintenir toute l’information nécessaire

pour
opérer de manière isolée, de telle façon que si l’on a des services dont on dépend
éventuellement, le service que l’on implémente n’en sera pas affecté :
il doit pouvoir
fonctionner en dehors d’une connexion
.

2.

Frontières explicites



Les services étan
t autonomes, les frontières entre ceux
-
ci doivent
être clairement définies. Les services peuvent être déployés sur des systèmes différents,
dans des lieux différents, avec des technologies différentes, vis
-
à
-
vis de domaines de
confiance différents. Il y a

donc un prix à payer en termes de complexité et de
performance pour traverser ces frontières.

La gouvernance des frontières est reconnue explicitement en utilisant une technique
d’échange explicite de messages entre les services. Les services sont exprim
és à leur
frontière et il n’y a qu’une seule façon d’accéder à l’information et/ou à la fonctionnalité au
sein d’un service. Cette emphase mise sur les frontières de services permet de réduire la
complexité de l’interaction entre les services et de formali
ser les interactions entre les
services indépendamment de leur implémentation (
plateforme
, langages, middleware,
etc.). L’invocation d’une méthode est ici considérée comme une technique privée
d’implémentation et non comme un moyen d’interaction entre serv
ices. Cette approche
permet de réduire le nombre et la complexité des abstractions qui doivent être partagées
par les services.

3.

Partage de schémas et de contrats



Les services sont autonomes, les frontières de
communication sont explicites, les service
s masquent l’implémentation et communiquent
par message avec l’extérieur. Les services doivent exposer leurs interfaces et les
structures permettant l’échange d’informations
au

travers de schémas correctement
construits, plutôt que sous la représentation d
’une classe ou d’un type tel qu’imposé par un
langage ou une
plateforme
.

En adoptant des schémas fondés sur des standards ouverts, on peut réellement
espérer


peut
-
être pour la première fois de l’histoire de l’informatique


créer des
systèmes pleinemen
t interopérables.

4.

Politiques



Les services
négocient

en utilisant des «

politiques

». C’est peut
-
être
l’une des caractéristiques les plus fondamentales des architectures orientées
services
. Les services doivent adhérer à la politique du tiers avec lequel

ils désirent
interagir pour interopérer. Si l’on offre un service fiable et transactionnel, on doit aussi
supporter les protocoles sous
-
jacents, etc. La négociation protocolaire est alors effectuée
dynamiquement et ceci permet aux concepteurs de services
d’abstraire très largement les
mécanismes d’encrage entre les systèmes et de se concentrer sur la sémantique
fonctionnelle de leur service.

Les architectures orientées services conduisent à une réflexion générale d’urbanisation des
systèmes d'information a
vec la disparition des applications monolithiques au profit d’une
collection de services déployés indépendamment

; l’orchestration et la coordination
(chorégraphie) des services étant l’un des points clé de la réussite de l’approche.


4

Approches technologiques pour la construction des systèmes connectés


3

Un bref rappel des fon
dements des services Web

Les services Web fondent leur promesse d’interopérabilité sur l’approche orientée services
précédente.

Pour cela, ils ont été conçus dès le début pour constituer un protocole de transmission de
messages à même de répondre à tout s
cénario d’usage sans restriction aucune. Un grand soin a
donc été pris pour s'assurer que leurs spécifications prennent en considération le plus large
éventail de scénarios possibles et conditions de transmission de messages.

Ces mêmes services Web ont été

conçus de façon à être modulaires et lâchement couplés avec
un niveau élevé de qualité et d'uniformité techniques à travers l’ensemble des spécifications. Ils
représentent en cela une révolution des technologies distribuées, révolution basée sur XML.

Pour

ce faire, ils proposent une couche d’abstraction pour la découverte et l’invocation de services
applicatifs. Ces services exposent des interfaces pour l’échange de documents. Ces interfaces
peuvent être publiées et retrouv
ées

dans un annuaire. Un client

de
c
e service doit simplement
composer un message et l’envoyer à l’adresse du service.

Ils ne sont liés à aucune plateforme ou architecture mais sont basés simplement sur des
protocoles et des formats. Ce qui permet de se connecter avec virtuellement tous

les systèmes
existants et d’utiliser toute infrastructure existante. Pour cela,
les services Web trouvent
naturellement leurs racines dans les standards ouverts

et notamment dans ceux de
l'Internet et de
l’
eBusiness

avec le W3C et l’OASIS
.

3.1

Protocole de
communication standard

Exposé potentiellement sur Internet, le canal de communication de choix pour un service Web est
tout naturellement le
protocole HTTP (
Hypertext Transfer Protocol

en anglais
)
3
, recommandati
on
du
W3C
.

3.2

Format de représentation de données standard

L’échange de messages impose la capacité de représenter toute donnée. Cette représentation
s’appuie sur

le

langage XML (
Extensible Markup Language

en anglais)
4
, l
angage universel (
l
ingua
franca
) de représentation de donnée et recommandation du W3C.


L’échange de messages suppose, au
-
delà de la capacité même de représenter les données
afférentes, la définition de schémas et c’est tout naturellement le langage XML
Schema
5

du W3C
qui est utilisé.

L’échange de messages nécessite enfin de disposer d’une voie indépendante des plateformes
pour permettre aux applications de communiquer les
unes
avec les autres au
-
dessus de l'Internet.
C’est l’objet du
protocole SOAP (
Simple Object Access Protocol


en anglais)
6
, recommandation du
W3C.

3.3

Langage de description standard WSDL

L’invocation d’un service suppose, à la base, la capacité de le décrire d’une façon compréhensible
et exploitabl
e de tous. C’est l’objet du
langage WSDL (
Web Services Description Language

en



3

Protocole HTTP

:
http://www.w3.org/Protocols

4

Langage XML :
http://www.w3.org/XML

5

Langage XML Schema

:
http://www.w3.org/XML/Schema

6

Protocole SOAP

:
http://www.w3.org/TR/soap


Approches technologiques pour la construction des systèmes connectés


5

anglais
)
7
, langage formaté XML de description des possibilités d'un service Web. La description
WSDL d’un service Web est obtenue dynam
iquement.

3.4

Mécanisme de découverte standard

UDDI (
Universal Description, Discovery and Integration

en anglais
)
8
,

crée une plateforme
interopérable standard qui permet à des sociétés et à des applications de rechercher et d’utiliser
rapidement, facilement, et dynamiquement des services Web au niveau de l'Internet.

UDDI constitue un effort inter
-
industries piloté par

les principaux éditeurs de logiciels, mais
également par des acteurs majeurs de l’industrie présents au sein du consortium OASIS. Microsoft
a contribué à l’initialisation de ce projet.

HTTP, SOAP, WSDL et UDDI constituent les fondements des services Web.

Ces qualités et le potentiel d’interopérabilité qui en fait un modèle universel unique pour
l’ensemble des interactions font que les services Web reçoivent aujourd’hui une très large
adoption de l’ensemble de l’industrie informatique et des clients.

En ef
fet, la demande des clients vis
-
à
-
vis d'une plateforme de connexion commune conduit une
large «

palette

» d’éditeurs
-

menée par Microsoft, IBM, BEA, SAP,
Siebel, Sun, Iona
, Oracle, etc.


à investir des milliards de dollars dans des produits et des soluti
ons basés sur les services Web
XML. Ce support universellement rencontré au niveau de chaque éditeur majeur couvrant des
domaines allant des téléphones aux mainframes amène à la création d'un large éventail de
produits qui supportent la pile des services W
eb XML. Ceci signifie que, virtuellement,
pratiquement chaque nœud sur le réseau


chaque client, chaque serveur, et chaque service
-

peut envoyer et recevoir des messages services Web XML.




7

Langage WSDL

:
http://www.w3.org/TR/wsdl

8

UDDI

:
http://www.uddi.org/about.html


6

Approches technologiques pour la construction des systèmes connectés


4

Architecture des Services Web

Sur la base de ces fondements, Micro
soft et IBM ont lancé une initiative visant à étendre les
standards ouverts du W3C comme
SOAP et
WSDL de façon à offrir des solutions à des problèmes
génériques communs à un vaste ensemble d’applications.

4.1

Eléments fondateurs

Les spécifications (protocoles
) résultantes WS
-
* (STAR pour
Secured, Transacted, Asynchronous
& Reliable
) définissent l’Architecture des Services Web (
Web Services Architecture

ou WSA) de
seconde génération (interopérables)
sécurisés, transactionnels, asynchrones et fiables

ou
plus sim
plement les services Web avancés.

Le livre blanc
I
NTRODUCTION A L

ARCHITECTURE DE SERV
ICES
W
EB ET SES SPECIFICAT
IONS
WS
-
*
9

donne une vue d’ensemble de ces spécifications
. La figure suivante donne

la vision graphique
d’ensemble

:


Figure
1
. Pile protocolaire WS
-
*

Leur conception et la mise en œuvre associée est régi par différents principes fondamentaux
particulièrement adapté
s

à la définition
d’un protocole d‘échange
comme notamment l’orientation
message et la compo
sition.

L’orientation message qui conduit à une utilisation exclusive de messages pour communiquer entre
services, tout en sachant que les messages ont souvent une durée de vie plus longue que leur
temps de transmission. Les services Web supposent que SOAP

est employé dans les couches
basses de la pile des protocoles afin d’isoler le transfert des messages des détails de la couche
transport. Ils ne s’appuient ni sur la syntaxe, ni sur la sémantique d’HTTP.

Les protocoles WS
-
* comme SOAP sont bâtis au niveau

du message SOAP
indépendamment du protocole de transport utilisé

; une dépendance stricte vis
-
à
-
vis
d’HTTP pourrait, en effet, en limiter le cadre d’utilisation (pare
-
feu, passerelle, NAT, etc.).




9

L
ivre blanc
I
NTRODUCTION A L

ARCHITECTURE DE SERV
ICES
W
EB ET SES SPECIFICAT
IONS
WS
-
*

:
http://msdn2.microsoft.com/fr
-
fr/library/887bf053
-
f951
-
4ede
-
bb68
-
6920c4304133.aspx


Approches technologiques pour la construction des systèmes connectés


7

L
es services Web peuvent répartir le traitement d’un messag
e donné sur plusieurs nœuds du
réseau, chacun contribuant à une fonctionnalité comme la vérification des accès, le routage en
fonction du contenu du message ou une validation spécifique à une application. Ce modèle de
traitement réparti implique qu'un mess
age peut passer par deux ou plusieurs transports avant
d'arriver à sa destination finale.

Pour cette raison, la plupart des premiers travaux sur les protocoles des services Web se sont
concentrés sur la livraison fiable, sécurisée et de bout en bout de mes
sages via des transports
quelconques.

SOAP est défini indépendamment du mécanisme sous
-
jacent de transport des messages. Il
autorise l’emploi de différents moyens de transport pour l’échange de messages, et permet
à la fois des transferts et des traitement
s synchrones ou asynchrones.

Les
spécifications/
protocoles WS
-
* sont construits au niveau du message SOAP et sont
conçus pour être complètement indépendants de la couche de transport sous
-
jacente et
donc du protocole de transport utilisé, la sélection du m
écanisme approprié peut être
retardée jusqu’au moment de l’exécution. Ainsi, les applications du service Web
déterminent le transport approprié au moment de l’envoi du message. En outre, le transport
sous
-
jacent peut changer pendant que le message passe de

nœud en nœud
indépendamment du protocole de transport utilisé.

Par ailleurs,

plutôt que d’essayer de résoudre tous les problèmes possibles et imaginables,
les spécifications individuelles de la pile WS
-
* essaient d’être courtes, concises et
d’apporter une

solution pertinente à un problème bien précis. Cette spécialisation des
différentes spécifications permet à WS
-
* d’être utilisé comme un jeu de briques de
standards pouvant être composées et assemblées orthogonalement pour composer un
message SOAP avec le

bon niveau de fonctionnalités (sécurité, routage, transactions, etc.).
Il ne s’agit pas ici de définir un monolithe, mais bien des blocs pour construire les
protocoles, blocs pouvant être utilisés dans pratiquement toutes les combinaisons.

Certaines spéci
fications peuvent être le cas échéant des compléments d’autres spécifications.

L
a présence du
moniker

WS
-

ne signifie pas forcément l’appartenance à la pile WS
-
*.


Ainsi,
WS
-
ResourceFramework

ne fait pas partie de la pile de la pile WS
-
* même si ces
spéci
fications s’appuient sur la spécification WS
-
Addressing qui elle fait partie de la pile WS
-
*.

De même,
dans une évolution ineluctable vers les services Web, la spécification
WS
-
Reliability

(WS
-
R)

a été créée à partir du support de
la livraison fiable des
messages

dans ebMS V2, afin de
rendre ce dernier utilisable avec SOAP, sans pour autant nécessiter d’autres portions d’ebXML.

Ainsi,
le moniker WS
-

pourrait laisser penser qu’ebMS

équivaut aux services Web bien que ne
supportant pas WSDL et transgressant nombre des spécifi
cations relatives à
XML Schema
.

Une telle spécification

ne répond clairement pas au même cahier des charges comme la
composition et l’assemblage orthogonal et ne
suit pas le même processus d’élaboration.
En
effet, ebMS/WS
-
R, au
-
delà d’une forte adhérence au transport HTTP (alors que les
spécifications
/protocoles

de la pile WS
-
* sont agnostiques par rapport au transport), ne peut être
composé avec d’autres spécifica
tions de la pile WS
-
*.

De plus, la «

charge utile » des messages (le contenu métier) est systématiquement exprimée
sous forme d’un attachement et s’appuie pour cela sur
la note
SwA

(
SOAP
with Attachments
) du
W3C
; ceci a pour conséquence que des messages s
imples ne peuvent être transmis dans le corps
SOAP et que le message métier en tant tel ne peut être sécurisé. Par ailleurs, seul le message
précédent peut être référencé

; ce qui limite grandement le cadre d’une réelle conversation.

Au sein de la pile WS
-
*, WS
-
ReliableMessaging (WS
-
RM) fournit l’ensemble des mécanismes
nécessaires pour assurer la livraison fiable des messages, et ce, même lorsqu'un ou plusieurs
services dans la chaîne sont indisponibles.


8

Approches technologiques pour la construction des systèmes connectés


La récente publication de la version 3 d’ebMS par l
e
comité OASIS ebXML Messaging Services
TC
10

(confirme cette évolution vers les services Web avancés. Comme précisé dans la
F
oire
A
ux
Q
uestions
11

:

«

Since ebMS V2 was published as a standard (2002), the technology environment has
evolved. New versions of underlying specifications (e.g. SOAP 1.2) are gaining support, and
Web Service
-
based platforms are now natively supporting features that had to be specified
from scratch in ebMS V2 (reliability, security)… Backward compatibility from V3 to V2 could
not be preserved mostly because of compliance with a new technology base.

»

Cette ver
sion 3 réutilise
des standards de la pile WS
-
* au niveau protocolaire pour la sécurité avec
le standard OASIS WS
-
Security et pour la fiabilité avec le standard OASIS WS
-
ReliableMessaging
(au même titre que
WS
-
Reliability
).

4.2

Processus d’élaboration des spéci
fications

Le travail de définition d
es spécifications/protocoles des services Web avancés
initié il y a
presque
7

ans arrive à son terme
,

avec à ce jour
,

l’ensemble des
principaux éléments
constituant de la pile WS
-
* publié en tant que recommandations du
W3C ou standards de
l’OASIS
.

La liste des spécifications de la pile WS
-
* est précisée, par exemple sur le
site Microsoft
12

qui
donne accès à chaque spécification ainsi qu’à son statut
, ou

encore sur le
site IBM
13
.

L
es spécifications
/protocoles des services Web avancés sont

ouvertes, publiques et libres
d’implémentation.

A ce titre, Microsoft a clairement indiqué qu’il
s’engageait de manière irrévocable à ne pas faire
valoir sa propriété intellectuelle sur ces standards ainsi que précisé dans
l’
OSP (
Open
Specification

Promise
en anglais)
14
, qui perme
t à tout le monde d’utiliser certaines technologies
brevetées Microsoft de façon perpétuelle, à titre gratuit et sans devoir signer de contrat.

L’OSP s’applique aux développeurs et aux utilisateurs des logiciels propriétaires et Open Source,
partout dans le monde.
A
u
-
delà des services Web (avancé
s) objet de ce livre blanc, u
ne vaste
gamme de technologies, portan
t notamment sur
la virtualisation, l
a sécurité et les formats de
fichier, ont déjà été mises à disposition dans le cadre de l’OSP.




10

Comité
OASIS ebX
ML Messaging Services TC

:
http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=ebxml
-
msg

11

FAQ ebMS3

:
http://www.oasis
-
open.org/committees/download.php/24881/ebMS3
-
FAQ
-
20070803.pdf

12

Spécifications Services Web sur le site Microsoft

:
http://msdn.m
icrosoft.com/en
-
us/library/ms951274.aspx

13

Spécifications Services Web sur le site Microsoft

:
http://www.ibm.com/developerworks/webservices/standards

14

Open
Specification

Promise
:
http://www.microsoft.com/france/interop/osp/default.mspx


Approches technologiques pour la construction des systèmes connectés


9

Cette couverture par l’OSP de ces spécifications a suscité de nombreuses réactions positives

;
pour n’en citer que
quelques unes

:



Mark Webbink
, Conseiller gé
néral,
Red Hat

:

«

Red Hat estime que le texte de l'OSP est
suffisamment souple pour permettre l'implémentation des spécifications indiquées dans les
logiciels fournis sous les licences Open Source et gratuites. Nous félicitons Microsoft pour
ses efforts v
isant à atteindre les représentants de la communauté Open Source et à
recueillir leurs commentaires concernant ce texte, et nous apprécions le fait que Microsoft
accepte d'apporter des modifications en réponse à nos commentaires.

»

;



Lawrence Rosen
,
Rosenl
aw & Einschlag
, cabinet juridique spécialisé dans le domaine
technologique

:
«

Je considère la mise en place de l'OSP par Microsoft comme une
démarche positive de Microsoft pour renforcer la collaboration entre les éditeurs de
logiciels et la communauté Op
en Source. Cet OSP permet à la communauté Open Source
d'implémenter ces spécifications standard sans avoir à verser des droits d'auteur à
Microsoft ou à signer un contrat de licence. Je suis ravi que cet OSP soit compatible avec
les licences gratuites et O
pen Source.

»

;



RL "Bob" Morgan
,

Architecte technologique senior,
University of Washington

:

«

L'Open
Specification Promise

de Microsoft constitue une évolution très positive. Dans les
communautés Open Source et universitaires, nous devons avoir la garantie que nous
pouvons implémenter des spécifications gratuitement. Grâce à cet engagement, il nous
sera plus facile d'implémen
ter des protocoles de services Web et des cartes d’informations
qui pourront être utilisés dans nos communautés.

»
.

IBM a adopté une approche similaire avec une intégration de ces standards dans l’
ISP
(
Interoperability Specifications Pledge

en anglais
)
15
.

C
es spécifications
/protocoles

font également l’objet d’une adoption croissante par
l’industrie et d’un nombre d’implémentations

clients en évolution constante
.

Co
mpte
-
tenu de ces éléments, nous inclinons à penser que les spécifications
/protocoles de
la pile

WS
-
* sont arrivées aujourd’hui à maturité. Ce point de vue est conforté par l’adoption
de ces spécifications comme infrastructure de communication par de très
nombreux
organismes de standardisation verticaux. On peut ainsi citer l’UN/CEFACT.

Par ailleurs,
ainsi que précisé plus bas, le niveau de fourniture d’implémentation opérationnelle des
services Web avancés est, d’ores et déjà, extrêmement substantiel.

Rev
enons un instant sur le processus d’élaboration.

4.2.1

Vue d’ensemble

La participation à la définition des spécifications et à leurs revues
a été

ouverte et publique de
façon à

:

1.

D
isposer des meilleures spécifications possibles
,


2.

P
rivilégier l’interopérabilité entre des implémentations de divers fournisseurs.

Pour cela, la stratégie de définition suivie
a
consist
é

à travailler en étroite collaboration avec les
éditeurs, et d’une façon générale, avec les experts en la matière.

Un te
l

processus passe tout naturellement par la définition initiale d’une spécification qui réponde
au problème particulier posé (sécurité, transaction, routage, etc.). Il s’agit, à ce stade, d’une
spécification préliminaire, base de travail. Cette dernière es
t publiée comme proposition pour revue
par ses auteurs (éditeurs et experts qui ont participé à son élaboration). L’objectif de cette première
publication est d’informer les autres acteurs du marché susceptibles d’utiliser cette spécification
dans leur pro
duit et de recueillir leurs remarques éventuelles.

Pour cela, sont organisés, suite à cette publication, un ou plusieurs ateliers (
feedback workshop
)
destinés au recueil de commentaires émanant de ceux qui travaillent sur une implémentation de la
spécifica
tion proposée ou, d’une façon plus générale, de toute partie intéressée. Ces ateliers sont



15

Interoperability Specifications Pledge

:
http://www
-
03.ibm.com/linux/opensource/ispinfo.shtml?S_TACT=105AGX04&S_CMP=LP


10

Approches technologiques pour la construction des systèmes connectés


ouverts à tous, la seule

condition de participation étan
t de renoncer à tout droit de propriété
intellectuelle.

Comme précédemment mentionné, l
es spécifications WS
-
* sont ouvertes, publiques, libres
d’implémentation. La prise en compte des retours permet de raffiner la spécification et de proposer
pour revue la version résultante. D’autres ateliers de ce type sont alors, le cas échéant, à nouveau
organisés jusqu’à ce

que la spécification considérée satisfasse l’ensemble des parties qui se sont
impliqués dans ce processus.

L’étape suivante consiste pour les parties qui le souhaitent à développer une implémentation de la
spécification. Les différentes implémentations ré
sultantes sont alors utilisées dans le cadre
d’ateliers d’interopérabilité (
interop
erability

workshop

en anglais
). Ces ateliers visent à valider, sur
la base des implémentations proposées et vis
-
à
-
vis de scénarios établis à l’avance, la capacité
d’écrire d
es applications interopérables avec la spécification considérée.

Passé ce stade, des ateliers dits de composition sont organisés. Ils visent à s’assurer que la
spécification considérée peut être composée et assemblée orthogonalement avec d’autres
spécifica
tions de la pile WS
-
* (fonction des fonctionnalités attendues).

L
’article
W
EB
S
ERVICES
P
ROTOCOL
W
ORKSHOPS
P
ROCESS
O
VERVIEW
16

précise le déroulé et
l
’ensemble des ateliers passé et à venir
.

Arrivés à ce stade, et avec le support d’autres acteurs du marché supportant cette
démarche, les auteurs de la spécification considérée décident alors de soumettre la
spécification candidate au standard à un organisme de normalisation qui peut être en
fo
nction de son domaine de compétence l’OASIS, le W3C ou l’IETF.

Dans le même temps, et de façon à accélérer une large adoption de la spécification, les
participants
ont
fourni

aux développeurs des kits de développement avant que ces technologies ne
soient i
ntégrées de manière native
dans
les offres des différents éditeurs

(Cf. section suivante)
.

Cette démarche a
vait

été initiée avec succès pour le développement de SOAP. Une première
version de la spécification (0.9
draft
) a
vait

été publiée par Microsoft et D
evelopMentor

; s’en
était

suivi la publication de la version 1.1 avec IBM. SOAP a
vait

ensuite été co
-
soumis avec IBM, Lotus,
Userland Software et DevelopMentor, au W3C comme note

; note qui est désormais une
recommandation. De façon à ce que cette
technologie puisse être mise en œuvre, Microsoft a
vait

proposé très rapidement le
SOAP Toolkit
ainsi que l’
Office Web Service Toolkit
. Cette technologie
a ensuite été intégrée nativement dans le .Net Framework, ce dernier étant à son tour intégré dans
Wind
ows Server 2003.

Les
différentes
extensions SOAP proposées dans le cadre des spécifications
/protocoles

WS
-
*
ont
donc
suiv
ies

ce chemin.

Ainsi
, au niveau

des fonctionnalités élémentaires des messages, pour ce qui est

de l’adressage et
du routage,
la spécif
ication
WS
-
Addressing a été soumis
e

au W3C par BEA Systems, IBM,
Microsoft, SAP AG et Sun Microsystems.
WS
-
Addressing
17

est
aujourd’hui
une
recommandation du
W3C
.

De même, pour les attachements
, l
a

spécification MTOM (
SOAP Message Transmission
Optimization Mechanism

en anglais)
18

constitue
également aujourd’hui une

recommandation du
W3C
.

Au niveau de la définition des politiques pour un message, les spécificati
ons
WS
-
Policy
19

et
WS
-
PolicyAttachment
20

constitue
également aujourd’hui des

recommandation
s

du W3C
.




16

W
EB
S
ERVICES
P
ROTOCOL
W
ORKSHOPS
P
ROCESS
O
VERVIEW

:
http://msdn.microsoft.com/en
-
us/library/ms996518.aspx

17

Standard
WS
-
A
DDRESSING

:
htt
p://www.w3.org/TR/ws
-
addr
-
core

18

Standard
MTOM

:
http://www.w3.org/TR/soap12
-
mtom

19

Standard
WS
-
P
OLICY

:
http://www.w3.org/TR/ws
-
policy

20

Standard
WS
-
P
OLICY
A
TTACHMENT

:
http://www.w3.org/TR/ws
-
policy
-
attach


Approches technologiques pour la construction des systèmes connectés


11

Vis
-
à
-
vis des trois piliers fonctionnels de la pile WS
-
*
, pour ce qui est du pilier Sécurité, le
comité
OASIS

W
EB
S
ERVICES
S
ECURITY
(WSS)

TC
21

a notamment produit les standards OASIS suivants

:



W
EB
S
ERVICES
S
ECURITY
:

SOAP

M
ESSAGE
S
ECURITY
(WS
-
S
ECURITY
)

V
1.0
22
,



WS
-
S
ECURITY
C
ORE
S
PECIFICATION
V
1.1
23
.

Toujours pour ce même pilier, l
e
comité
OASIS

W
EB
S
ERVICES
S
ECURE
E
XCHANGE
(WS
-
SX)

TC
24

a
produit les standards OASIS suivants

:



W
EB
S
ERVICES
S
ECURITY
P
OLICY
L
ANGUAGE
(WS
-
S
ECURITY
P
OLICY
)

V
1.2
25
,



W
EB
S
ERVICES
S
ECURE
C
ONVERSATION

L
ANGUAGE

(WS
-
S
ECURE
C
ONVERSATION
)

V
1.3
26
,



W
EB
S
ERVICES
T
RUST
L
ANGUAGE
(WS
-
T
RUST
)

V
1.3
27
.

Enfin, l
e
comité OASIS Web Services
Federation

(WSFED) TC
28

s’intéresse à la
standardisation

de
la spécification WS
-
Federation
.

Pour le pilier Fiabilité ou plus e
xactement
l’échange de messages fiables,
le
comité
OASIS

W
EB
S
ERVICES
R
ELIABLE

E
XCHANGE
(WS
-
RX)

TC
29

a standardisé les spécifications

:



W
EB
S
ERVICES
R
ELIABLE
M
ESSAGING
(WS
-
RM)

V
1.1
30
,



W
EB
S
ERVICES
R
ELIABLE
M
ESSAGING
P
OLICY
A
SSERTION V
1.1
31
,




W
EB
S
ERVICES
M
AKE
C
ONNECTION V
1.0
32
.

Enfin, pour le pilier Transactions, le
comité
OASIS

W
EB
S
ERVICES
T
RANSACTION
(WS
-
TX)

TC
33

a
produit les standa
rds OASIS suivants

:



W
EB
S
ERVICES
C
OORDINATION
(WS
-
C
OORDINATION
)

V
1.1
34
,



W
EB
S
ERVICES
A
TOMIC
T
RANSACTION
(WS
-
A
TOMIC
T
RANSACTION
)

V
1.1
35
,



W
EB
S
ERVICES
B
USINESS
A
CTIVITY
(WS
-
B
USINESS
A
CTIVITY
)

V
1.1
36
.

Comme ill
u
s
tré ci
-
avant
,

l
es principales spécifications de la pile WS
-
* sont soit d’ores et
déjà des standards de l’OASIS ou du

W3C
soit

en

passe

de le devenir eu égard au
pr
ocessus d’élaboration précédent
.




21

C
omité OASIS Web Services Security (WSS) TC

:

22

Standard
WS
-
S
ECURITY
1.0

:
http://docs.oasis
-
open.org/wss/2004/01/oasis
-
200401
-
wss
-
soap
-
message
-
security
-
1.0.pdf

23

Standard
WS
-
S
ECURITY
1.1

:
http://www.oasis
-
open.org/committees/download.php/16790/wss
-
v1.1
-
spec
-
os
-
SOAPMessageSecurity.pdf

24

C
omité OASIS
Web Services Secure Exchange (WS
-
SX) TC
:
http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=ws
-
sx

25

Standard
WS
-
S
ECURITY
P
OLICY

:
http://www.oasis
-
open.org/specs/index.php#wssecpolv1.2

26

Standard
WS
-
S
ECURE
C
ONVERSATION

:
http://www.oasis
-
open.org/spe
cs/index.php#wssecconv1.3

27

Standard
WS
-
T
RUST

:
http://www.oasis
-
open.org/specs/index.php#wstrustv1.3

28

C
omité
OASIS

W
EB
S
ERVICES
F
EDERATION

(WSFED)

TC

:
http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=wsfed

29

C
omité
OASIS

W
EB
S
ERVICES
R
ELIABLE

E
XCHANGE
(WS
-
RX)

TC

:
http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=ws
-
rx

30

Standard
WS
-
RM

:
http://docs.oasis
-
open.org/ws
-
rx/wsrm/200702

31

Standard
WS
-
RM

P
OLICY

:
http://docs.oasis
-
open.org/ws
-
rx/wsrmp/200702

32

Standard
WS
-
MC
:
http://docs.oasis
-
open.org/ws
-
rx/wsmc/200702

33

C
omité
OASIS

W
EB
S
ERVICES
T
RANSACTION
(WS
-
TX)

TC

:
http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=ws
-
tx

34

Standard
WS
-
C
OORDINATION

:
http://docs.oasis
-
open.org/ws
-
tx/wscoor/2006/06

35

Standard
WS
-
A
T
OMIC
T
RANSACTION

:
http://docs.oasis
-
open.org/ws
-
tx/wsat/2006/06

36

Standard
WS
-
B
USINESS
A
CTIVITY

:
http://docs.oasis
-
open.org/ws
-
tx/wsba/2006/06


12

Approches technologiques pour la construction des systèmes connectés


L’étape ultime réside, en termes d’amélioration du potentiel d’interopérabilité, dans la
définition de profils d’interopérabilité par l’organisation WS
-
I pour ces
mêmes
spécifi
cations
/protocoles
.

4.2.2

WS
-
I, l’ultime étape

Dans le principe, deux parties souhaitant communiquer via des services Web doivent simplement
se mettre d’accord sur la syntaxe et la sémantique des messages échangés. Une fois ce contrat
défini, elles sont libres de choisir les langages de programmation,
les systèmes, les machines
virtuelles ou les bases de données.

Afin d’accélérer le développement et le déploiement de l’interopérabilité des services Web et donc,
de garantir que les différents standards supportant les services Web soient réellement
implé
mentés de manière interopérable entre les différents éditeurs du marché, Microsoft et 45
autres entreprises ont fondé l’organisation WS
-
I. Les membres
du « board » sont Accenture, BEA
Systems, Fujitsu, Hewlett
-
Packard, IBM, Intel, Microsoft, Oracle, et SAP
. L’organisation comprend
d’autres membres participants parmi les utilisateurs de services Web comme Daimler Chrysler,
Ford Motor, Qwest,

Reuters, et United Airlines. Sun a rejoint récemment cette organisation qui
comprend aujourd’hui plus de 130 membres.

La première mission de WS
-
I est de garantir l’interopérabilité par l’usage des services Web qui
promettent d’intégrer des applications développées et maintenues par différentes organisations sur
différentes technologies. Les services Web développés avec le
s outils existants
n’interopèrent

pas
toujours de manière satisfaisante

: des méthodes de services Web ne peuvent pas être exposées,
des méthodes peuvent être exposées mais pas consommées ou encore des types de données ne
peuvent être sérialisés. Ces incom
patibilités sont dues à l’utilisation de différents types de
message SOAP ou à des différences d’interprétation des interfaces WSDL. Les éditeurs d’outils
ont travaillé à corriger ces problèmes, mais la rapide évolution de SOAP et des standards
complémenta
ires ainsi que la gestion des différentes versions d’un même standard rendent ce
travail difficile. De plus, les éditeurs doivent s’entendre non plus sur une seule, mais sur plusieurs
technologies ne serait
-
ce qu’au niveau du fondement des services Web com
me nous l’avons vu
(HTTP, XML Schema, SOAP, WSDL, UDDI).

En raison de la
multiplicité

de
s

plates
-
formes et
de technologies (Cf. section suivante)
, il est
essentiel que les services Web soient capables de fonctionner dans un environnement hétérogène.

WS
-
I
peut simplifier cette tâche en définissant des profils qui correspondent

à

un groupe de
spécifications compatibles à un certain niveau de version adressant un ensemble cohérent de
fonctionnalités et de recommandations d’utilisation à observer.
Un profil es
t un ensemble de
sp
é
cifications, accompagné de clarifications, interpr
é
tations et restr
ic
tions

de celles
-
ci de façon à
promouvoir l’interopérabilité.

Dans le même temps, WS
-
I crée des
protocoles et outils de test
37

afin de vérifier le respect effectif
de ces profils par les différents produits et solutions du marché. Les éditeurs proposent
conjointement des
modèles de mise en œuvre
38

qui se conforment aux recommandations
précédentes. En ce sens, WS
-
I est une sorte d’intégrateur de standards qui s’appuie et qui utilise
les spécifications des différents organismes comme le W3C, OASIS ou IETF.

Vis
-
à
-
vi
s du fondement des services Web, WS
-
I a déjà publié le
profil élémentaire
WS
-
I

B
ASIC
P
ROFILE
1.1
39
, qui prend en considération SOAP 1.1, XML Schema 1.0, WSDL 1.1, et UDDI 2.0. Ce
profil cons
titue aujourd’hui
LA référence en matière d’interopérabilité des services Web
.

Ce
dernier
correspond désormais à la norme
ISO/IEC 29361:20
08 Information Technology


Web
Services Interoperability


WS
-
I Basic Profile version 1.1
.

WS
-
I travaille à présent sur la définition de profil pour les services Web avancés avec notam
ment
la publication du
profil
WS
-
I

B
ASIC
S
ECURITY
P
ROFILE
1.0
40

à destination du standard
OASIS WS
-
Security dont les implémentations deviennent omniprésentes.




37

Protocoles et outils de test du WS
-
I :
http://www.ws
-
i.org/deliverables/workinggroup.aspx?wg=testingtools

38

Mod
èles de mise en œuvre du WS
-
I

:
http://www.ws
-
i.org/deliverables/workinggroup.aspx?wg=sampleapps

39

Profil
WS
-
I

B
ASIC
P
ROFILE
1.
1

:
http://www.ws
-
i.org/Profiles/BasicProfile
-
1.1.html

40

Profil
WS
-
I

B
ASIC
S
ECURITY
P
ROFILE
1.0

:
http://www.ws
-
i.org/Profiles/BasicSecurityProfile
-
1.0.html


Approches technologiques pour la construction des systèmes connectés


13

De nouveaux profils sont en cours de définition
ou publiés
au niveau du WS
-
I. Il s’agit plus
particulièrement des

profils suivants
:

1.

Profil
WS
-
I

B
ASIC
P
ROFILE
1.2
41

-

Cette version du
profil élémentaire

WS
-
I introduit la prise
en compte d
es recommandations WS
-
Addressing et MTOM du W3C

;

2.

Profil
WS
-
I

B
ASIC
P
ROFILE
2.0
42

-

Cette
version du
profil élémentaire

WS
-
I
sera basée sur
les spécifications suivantes : SOAP 1.2, XML
InfoSet, WSDL 1.1 and XML Schema 2001
pour la description des services, WS
-
Addressing, MTOM, XOP, UDDI v2 & v3 pour la
découverte et la publication

;

3.

Profil
WS
-
I

R
ELIABLE

S
ECURE
P
ROFILE
(RSP)

1.0
43

-

Ce profil prend en compte les
spécifications
WS
-
ReliableMessaging et WS
-
SecureConversation.

Les travaux sont en
cours au niveau de l’organisation WS
-
I
.

4.3

Niveau d’adoption par l’industrie

Le processus d’élaboration des spécificat
ions
/protocoles de la pile WS
-
*

a
int
é
gr
é

très tôt
la mise à
disposition
des

développeurs de kits de développement avant

même
que ces technologies ne
soient intégrées de manière native
aux

offres des différents éditeurs

ou communautés Open
Source.

Ceci con
stitue une démarche pragmatique où les standards et leurs implémentations sont
développés en parallèle, de manière itérative et modulaire.

Les implémentations opérationnelles
en version finale
de ces standards sont, d’ores et déjà,
disponibles.

Chaque édi
teur
ou communauté
a bien évidemment sa propre feuille de route.

Pour ce qui est de Microsoft, le support des spécifications WS
-
*
a été

introduit

par Microsoft WSE
(
Web Services Enhancements

en anglais
)
sous forme d’une
extension du
Framework

.NET
2.0
.
Cette approche a permis, à

travers un cycle de gestion d’évolution propre, de bénéficier au sein d
u

Framework
.NET
de l’implémentation des toutes dernières spécifications WS
-
* et/ou de leur
évolution.

Le travail de définition

des spécifications
/protocoles

WS
-
* constituant les piliers principaux
Sécurité/Messages fiables/Transactions et coordination étant aujourd’hui achevé, l’intégration en
natif au sein de la plate
-
forme Windows de la pile

complète

WS
-
* est amené
e

par les
classes
WCF (
Windows Communication Foundation

en anglais,
nom de code Indigo
)
44
,

introduites avec
la
version 3.0 du
Framework

.NET
.

WCF est la technologie Microsoft des services Web
avancés

qui propose un ca
dre de travail
extrêmement productif pour le développement de logiciels
(interopérables)
sécurisés,
transactionnels et fiables

basés sur les standards de l’industrie. WCF étend le .NET Framework
2.0 avec des fonctionnalités additionnelles destinées à la mi
se en œuvre de systèmes connectés.

Pour cela, WCF vise à offrir le support le plus large des spécifications
/protocoles

WS
-
*
-

maximisant ainsi la capacité à interopérer avec une large gamme de systèmes au sein d’un
environnement hétérogène.
L
a plateforme d
e services et d’échanges Microsoft BizTalk Server
2006 R2 propose nativement un connecteur WCF.








41

Profil
WS
-
I

B
ASIC
P
ROFILE
1.2

:
http://www.ws
-
i.org/Profiles/BasicProfile
-
1.2.html

42

Profil
WS
-
I

B
ASIC
P
ROFILE
2
.0

:
http://www.ws
-
i.org/Profiles/BasicProfile
-
2_0(WGD).html

43

Profil
WS
-
I

R
ELIABLE

S
ECURE
P
ROFILE
(RSP)

1.0

:
http://www.ws
-
i.org/Profiles/Reliable_Secure_Profile_Version_1.pdf

44

WCF :
http://www.microsoft.com/net/windowscommunicationfoundation.aspx


14

Approches technologiques pour la construction des systèmes connectés


Microsoft a fait en février 2008 une
annonce majeure
45

dans le but d’améliorer l’ouverture de ses
produits, d’offrir une meilleure interopérabilité et de créer des opportunités pour les développeurs,
les partenaires, les clients et les concurrents.

L’échange d’information
s

entre personnes et organisations, l
’interopérabilité entre applications et
services sont devenus en effet des besoins essentiels. Microsoft a pris depuis déjà un certain
temps des engagements concernant l’interopérabilité. Nous avons échangé avec nos clients au
sujet de leurs besoins d’inte
ropérabilité et nous les avons écoutés sur la manière dont les solutions
Microsoft pourraient devenir encore plus ouvertes et interopérables.

Pour répondre à ces enjeux et ces besoins, Microsoft va appliquer quatre principes
d’interopérabilité à ses produ
its à large diffusion comme Windows Vista (y compris le Framework
.NET qui nous intéresse ici), Windows Server 2008, etc., ainsi que toutes les futures versions de
ces produits :

1.

Garantir une connexion ouverte à ces produits ;

2.

Promouvoir la portabilité d
es données ;

3.

Améliorer le support des standards de l’industrie ;

4.

Favoriser l’échange et la collaboration avec l’industrie y compris les différentes
communautés Open Source autour des questions d’interopérabilité et de standards.

Conformément à
cette
anno
nce majeure, WCF propose avec la version 3.5 du Framework .NET
une flexibilité accrue en terme
s

de conception en offrant un support de

l’architecture
REST
(
Representational State Transfer

en anglais),
et des encodages
JSON (
JavaScript Object Notation

en an
glais) et POX (
Plain Old XML

en anglais).

L’interopérabilité avec l
a

technologie GlassFish V2
46

compatible
Java Platform, Enterprise Edition
(Java EE) 5

de la
société Sun Microsystems

a été démontrée comme décrit dans le livre
-
blanc
P
ROJECT
T
ANGO
-

S
ECURE
,

R
ELIABLE
,

T
RANSACTIONAL AND
.NET

3.0
-
INTEROPERABLE
W
EB SERVICES
47
.

Project Tango est un composant clé du Project
Metro qui correspond à la pile service
s Web dans
la technologie
GlassFish V2.

Sun Java System Application Server 9.1
est basé sur

GlassFish V2.

De même, le projet Apache a finalisé, le moteur Services Web Apache Axis2 qui intègre le support
des spécificati
ons/protocoles WS
-
*. Une implémentation Java avec
Apache Axis2/Java
48

et C avec
Apache Axis2/C
49

sont ainsi disponibles. La conception de ce moteur permet
de
supporter
l’
ensemble de la pile protocolaire WS
-
* avec le concept de modules ou de projets Apache distincts.
Il s’agit au moment de la rédaction de ces
lignes d’Apache Axis2 et des projets
Apache Rampart,
Apache Rahas, Apache Sandesha2, Apache Axiom, et Apache Neethi.

WS02

propose de son côté le
Framework
WSO2 WSF (
Web Services Framework

en anglais
)
50

qui
est un package intégré, testé et prêt à l’usage des kits Apache Axis2/Java et Apache Axis2/C et
des projets associés. Sur cette base, WS02 propose des extensions pour les environnements
PHP, Perl, Ruby ainsi que des extensions AJAX pour
Mozilla Firefox

et Microsoft

Internet Explorer.

WS02 propose également, sur cette fondation technologique, une
plateforme WS02 WSAS (
Web
Services Application Server

en anglais
)
51
.

Ces quelques exemples illustrent aujourd’
hui l
a très large adoption des standards de la pile WS
-
*
(recommandations du W3C ou standards de l’OASIS selon le périmètre fonctionnel)
quelque soit la
plateforme ou la technologie utilisée.




45

Cf.
Microsoft Makes Strategic Changes in Technology and Business Practices to Expand I
nteroperability
-

New
interoperability principles and actions will increase openness of key products

:
http://www.microsoft.com/presspass/press/2008/feb08/02
-
21ExpandInteroperabilityPR.mspx

46

Technologie GlassFish :
http://java.sun.com/javaee/community/gla
ssfish/index.jsp

47

Livre
-
blanc
P
ROJECT
T
ANGO
-

S
ECURE
,

R
ELIABLE
,

T
RANSACTIONAL AND
.NET

3.0
-
INTEROPERABLE
W
EB SERVICES

:
https://wsit.dev.java.net/docs/tango
-
overview.pdf

48

Apache Axis2/Java

:
http://ws.apache.org/axis2

49

Apache Axis2/
C
:
http://ws.apache.org/axis2/c

50

Framework WSO2 WSF

:
http://wso2.org/projects/wsf

51

P
lateforme WS02 WSAS

:
http://wso2.org/projects/wsas/java


Approches technologiques pour la construction des systèmes connectés


15

C’est cette même raison qui a conduit

la DGME (
Direction Général
e de la Modernisation de l’Etat
)

à

repos
er

sur ces standards

pour

le
protocole PRESTO (
PRotocole d’Echanges Standard et
Ouvert
)
52
, protocole d’échange pour les besoins de l’adm
inistration électronique.

Le livre blanc
PRESTO

UN PROTOCOLE D
'
ECHANGE POUR LES BES
OINS DE L
'
ADMINISTRATION
ELECTRONIQUE
53

revient

sur les défis architecturaux et les orientations et axes d’architecture retenus
dans ce cadre.

La volonté des concepteurs de PRESTO était non seulement de définir ce
protocole, mais
également de démontrer que la dite spécification pouvait être implémentée sur des
environnements et langages divers et que les implémentations résultantes tenaient les promesses
d’interopérabilité des orientations retenues.


I
l s’agit
ici
d
e rationaliser les coûts d’investissement et d’exploitation, en tirant le meilleur parti de
l’existant et des nouvelles plates
-
formes déployées. En effet, l’interopérabilité permet de favoriser
le choix, la concurrence et l’innovation, de réduire les coûts

et la dépendance vis
-
à
-
vis d’un
fournisseur unique tout en favorisant un accès ouvert aux informations.

Cette orientation technologique reposant sur des
standards ouverts internationaux

trouve de
multiples motivations. Elle

:

1.

Constitue la clé du succès de
s initiatives d’administration électronique à la lumière
notamment des prévisions du Gartner Group

;

2.

Promeut un accès ouvert à l’information et adresse les problèmes de compatibilité avec le
passé (continuité de l’État dans le temps et sur tout le territoi
re) notamment au travers des
possibilités de façades

;

3.

Entretient la bonne santé de l’écosystème informatique : choix, compétition et innovation

;
les services Web étant aujourd’hui supportés

par les principaux éditeurs de logiciels avec,
à la clé, des
solutions propriétaires ou Open Source ;

4.

Évite à un État d’être l’otage d’un fournisseur, de très nombreux éditeurs et autres acteurs
de l’informatique proposant de telles solutions ou de l’expertise sur ces dernières

;

5.

Réduit les coûts, améliore l’efficac
ité, la flexibilité et la valeur ajoutée du système
.

PRESTO et les services Web avancés WS
-
* font des émules. Le colloque
eGovINTEROP’07
54

qui
s’est tenu à Paris
en fin d’année 2007
a montré que

l’Allemagne avec la version 2.0 de son
protocole OSCI est en cours de définition d’un protocole proche de PRESTO. D’autres pays
comme la Suède, le Danemark et l’Estonie emboîtent le pas.


Le protocole européen
eLink

ayant été abandonné, la commission eur
opéenne, dans le cadre du
programme IDABC (
Interoperable Delivery of Pan
-
European eGovernment Services to Public
Administrations, Business and Citizens

e
n anglais
), assiste aujourd’hui ces pays dans la définition
d’un profil commun s’appuyant sur PRESTO, m
ais basé sur des profils d’interopérabilité
internationaux.




52

Protocole PRESTO :
http://www.synergies
-
publiques.fr/rubrique.php?id_rubrique=165

53

Livre
-
blanc
PRESTO

UN PROTOCO
LE D
'
ECHANGE POUR LES BES
OINS DE L
'
ADMINISTRATION ELECT
RONIQUE
:
http://download.microsoft.com/downloa
d/4/7/2/4729870a
-
44f4
-
4e60
-
abcc
-
14d9d6f37fe4/PRESTO%20un%20protocole%20d'échange%20pour%20les%20besoins%20de%20l'administration%20élect
ronique%20v1%200.pdf

54

C
olloque eGovINTEROP’07

:
http://egovinterop.eu/public/page.tpl?rub=9600


16

Approches technologiques pour la construction des systèmes connectés


5

Pour en savoir plus…

Pour de plus amples information sur les solutions
d
’architectures orientées service

proposées par
Microsoft, nous
vous
invitons à consulter le

site
Microsoft SOA
55
.

Pour de plus amples informations sur
l'interopérabilité technique
des produits et technologies
Microsoft
avec des logiciels et matériels d'autres fournisseurs
, nous vous invitons à consulter le
site Microsoft Interopérabilité
56
.
Vous retrouverez notamment l’
annonce majeure
57

que Microsoft a
faite au mois de février 2008
dans le but d’améliorer l’ouverture de ses produits, d’offrir une
meilleure interopérabilité et de créer des opportunités pour les développeurs, les partenaires, les
clients et les concurren
ts.


Pour de plus amples informations sur les standards
d'interopérabilité

que Microsoft soutient ou
auxquels Microsoft apporte sa collaboration, nous vous invitons à consulter le
site Microsoft
Sta
ndards
58
.




55

Site Microsoft SOA

:
http://msdn.microsoft.com/en
-
us/architecture/aa948857.aspx

56

Site

Microsoft Interopérabilité :
http://www.microsoft.com
/france/interop

57

Communiqué de presse

M
ICROSOFT
M
AKES
S
TRATEGIC
C
HANGES IN
T
ECHNOLOGY AND
B
USINESS
P
RACTICES TO
E
XPAND
I
NTEROPERABILITY

:

58

Site

Microsoft Standards :
http://www.microsoft.com
/france/standards