2012 11 30 WebServices

Web Services
Mineure SOA
Cécile Hardebolle
cecile.hardebolle@supelec.fr
Programme de la mineure
Introduction. Enjeux, rôle de l'architecte SI Deux intervenants :
16 nov. Partie n°1 du cas d'étude Olivier Besnard (Solucom)
Cécile Hardebolle (Supélec)
Architectures applicatives
D1.13E
23 nov. et inter-applicatives
Web Services D1.13E

30 nov.
Modèle SOA
7 déc. Partie n°2 du cas d'étude
Intégration et gestion des processus

14 déc.
Modélisation de processus D1.13E

21 déc.
Exécution de processus D1.13E

11 jan. Examen : présentation de
Compléments et ouverture. Conclusion 5 fév. vos travaux sur le cas
18 jan. Partie n°3 du cas d'étude d'étude « Chaus'Star »
2 Web Services 30 novembre 2012

Au programme ce matin…
} Les grands principes des Web Services

} Les technologies sur lesquelles reposent les Web Services
} Un peu de méthodologie
} De la pratique !
à retenir avancé démo/exercice

Qu'est-ce qu'un Web Service ?

SOA & notion de service
} Service = tâche, action, unité de travail (métier ou technique)
} Sans état
} Laisse le système dans un état stable
} Autonome, indépendant du contexte
} Réutilisable
} Composable
} « Gros grain »
} Interface
} Masque la logique d’implémentation
} Contrat d’utilisation (contrat de service)
} Format pivot = langage commun pour décrire et échanger des données

Web Service = service + web
} Service = application déployée sur internet
} Associée à une URL sur le web
} Accessible via des protocoles internet standard (principalement HTTP)
} Accessible indépendamment des technologies d’implémentation
} Auto-descriptive
} Interface (contrat) = fichier XML
} Format pivot = langage XML + protocole internet
Web Services = ensemble de standards pour l’interopérabilité

Principe des Web Services
Annuaire de services
Découverte Publication
Client Fournisseur
Internet
Application Web Service
Utilisation Interface

Utilisation d'un Web Service
Client Annuaire Fournisseur
Déploiement
Enregistrement du service
Recherche du service A
Voici l’adresse du serveur

qui héberge A
Quel format utiliser pour le service A ?
Contrat de service
Requête
Réponse

Les Web Services WS-*

Web Services
« Galaxie Standards
» des standards Overview
WS-*
Dependencies
© innoQ Deutschland GmbH. All Rights Reserved. The poster may also contain references to other company, organisation, brand and product names. These company, organisation, brand and product names are used herein for identification purposes only and may be the trademarks of their respective owners.
Messaging Specifications
SOAP 1.1
Interoperability Business Process Specifications Management Specifications Presentation

SOAP 1.2
SOAP Message Transmission Optimization Mechanism
Issues Specifications
WS-Notification
Business Process Execution WS-Choreography Model Web Service Choreography Web Service Choreography Management Using Web Management Of WS-BaseNotification
WS-Management
Metadata
Resource
Security
Language for Web Services 1.1 Overview Interface Description Language Services (WSDM-MUWS) Web Services (WSDM-MOWS) AMD, Dell, Intel, Microsoft and Sun WS-Topics
(BPEL4WS) · 1.1 · BEA Systems, IBM, (WSCI) · 1.0 · W3C 1.0 1.0 Microsystems
1.0 · W3C (CDL4WS) · 1.0 · W3C WS-BrokeredNotification
Microsoft, SAP, Sun Microsystems, SAP, BEA Systems OASIS OASIS Published Specification Web Services for Remote
Working Draft Candidate Recommendation
Basic Profile Siebel Systems · OASIS-Standard and Intalio · Note OASIS-Standard OASIS-Standard
Portlets (WSRP) WS-Addressing – Core
1.1
WS-I ! Business Process Execution Language for Web Services ! WS-Choreography Model Overview defines the format ! Web Service Choreography Interface (WSCI) describes ! Web Service Choreography Description Language ! Web Service Distributed Management: Management Using ! Web Service Distributed Management: Management Of ! WS-Management describes a general SOAP-based 2.0 WS-Addressing – WSDL Binding
1.1(BPEL4WS) provides a language for the formal and structure of the (SOAP) messages that are exchanged, how Web Service operations can be choreographed in the (CDL4WS) is to specify a declarative, XML based language Web Services (WSDM-MUWS) defines how an IT resource Web Services (WSDM-MOWS) addresses management of protocol for managing systems such as PCs, servers, OASIS
Final Specification specification of business processes and business interaction and the sequence and conditions in which the messages context of a message exchange in which the Web Service that defines from a global viewpoint the common and connected to a network provides manageability interfaces the components that form the network, the Web services devices, Web services and other applications, and other
protocols using Web Services. are exchanged. participates. complementary observable behaviour, where message such that the IT resource can be managed locally and from endpoints, using Web services protocols. manageable entities. Committee Draft WS-Addressing – SOAP Binding
exchanges occur, and when the jointly agreed ordering remote locations using Web services technologies.
! Basic Profile – The Basic Profile 1.1 provides rules are satisfied. " Web Services for Remote Portlets (WSRP) defines a WS-Eventing
implementation guidelines for how related set of non-
proprietary Web Service specifications should be used Business Process Execution Business Process Management XML Process Definition
set of interfaces and related semantics which standardize
interactions with components providing user-facing WS-Enumeration
together for best interoperability. Language for Web Services 2.0 Language (BPML) Language (XPDL) Service Modeling Language markup, including the processing of user interactions with
that markup.
(BPEL4WS) · 2.0 1.1 IBM, BEA, BMC, Cisco, Dell, HP, Intel,
Metadata Specifications
2.0
OASIS, BEA Systems, IBM, Microsoft, SAP, BPMI.org Microsoft, Sun
Final
Siebel Systems · Committee Draft Final Draft Draft Specification
Basic Profile
1.2 ! Business Process Execution Language for Web Services ! Business Process Management Language (BPML) ! XML Process Definition Language (XPDL) provides an WS-Policy
2.0 (BPEL4WS) provides a language for the formal provides a meta-language for expressing business XML file format that can be used to interchange process ! Servcie Modeling Language (SML) is used to model
WS-I specification of business processes and business interaction processes and supporting entities. models between tools. complex IT services and systems, including their structure, WS-PolicyAssertions
Working Group Draft protocols using Web Services.
Security
constraints, policies, and best practices.
WS-PolicyAttachment
! Basic Profile – The Basic Profile 1.2 builds on Basic Profile
Messaging
1.1 by incorporating Basic Profile 1.1 errata, requirements WS-Discovery
from Simple SOAP Binding Profile 1.0, and adding support
for WS-Addressing and MTOM. WS-MetadataExchange
Universal Description, Discovery and Integration
Web Service Description Language 1.1

Basic Profile
Web Service Description Language 2.0 Core
Metadata Specifications Reliability Security Specifications Transaction Resource

2.0
WS-I
Working Group Draft Web Service Description Language 2.0 SOAP Binding
! Basic Profile – The Basic Profile 2.0 is an update of WS-I

BP that includes a profile of SOAP 1.2.
WS-Policy WS-PolicyAssertions Specifications WS-Security WS-SecurityPolicy Specifications Specifications Security Specifications
1.1 1.1 WS-Security
1.5 1.1
BEA Systems, IBM, Microsoft,
W3C
IBM, Microsoft, SAP
OASIS
RSA Security, VeriSign WS-Coordination Web Services WS-Security: SOAP Message Security
Attachments Profile Working Draft
Public Draft WS-ReliableMessaging OASIS-Standard
Public Draft 1.1 Resource Framework (WSRF)
1.0 1.1 OASIS WS-Security: Kerberos Binding
1.2
WS-I ! WS-Policy describes the capabilities and constraints of ! WS-PolicyAssertions provides an initial set of assertions OASIS ! WS-Security is a communications protocol providing a ! WS-SecurityPolicy defines how to describe policies related Working Draft OASIS
Final Specification the policies on intermediaries and endpoints (e.g. business to address some common needs of Web Services Committee Draft means for applying security to Web Services. to various features defined in the WS-Security specification. WS-Security: SAML Token Profile
Messaging
OASIS-Standard
Reliability
Metadata
rules, required security tokens, supported encryption applications. ! WS-Coordination describes an extensible framework for providing
algorithms, privacy rules). protocols that coordinate the actions of distributed applications. ! Web Services Resource Framework (WSRF) defines a family of WS-Security: X.509 Certificate Token Profile
! Attachments Profile – The Attachment Profile 1.0 specifications for accessing stateful resources using Web Services.
complements the Basic Profile 1.1 to add support ! WS-ReliableMessaging describes a protocol that allows
WS-Business Activity WS-Security: Username Token Profile
for interoperable SOAP Messages with attachments-based
Web Services.
Web services to communicate reliable in the presence of
software component, system, or network failures. It defines WS-Security: WS-Security: 1.1 WS-BaseFaults (WSRF) WS-SecurityPolicy
a SOAP binding that is required for interoperability. SOAP Message Security Username Token Profile OASIS 1.2
WS-PolicyAttachment WS-Discovery 1.1 1.1 Working Draft OASIS WS-Trust
1.2 Microsoft, BEA Systems, Canon, OASIS OASIS Working Draft
! WS-Business Activity provides the definition of the business activity
Simple SOAP W3C Intel and webMethods WS-Reliable Messaging Public Review Draft Public Review Draft coordination type that is to be used with the extensible coordination WS-Federation
! WS-BaseFaults (WSRF) defines a base set of information
Binding Profile W3C Member Submission Draft Policy Assertion (WS-RM Policy) framework described in the WS-Coordination specification. that may appear in fault messages. WS-BaseFaults defines an WS-SecureConversation
1.0 ! WS-Security: SOAP Message Security describes ! WS-Security: Username Token Profile describes how XML schema type for base faults, along with rules for how
1.1
WS-I
! WS-PolicyAttachment defines two general-purpose ! WS-Discovery defines a multicast discovery protocol for OASIS
enhancements to SOAP messaging to provide message
integrity and confidentiality. Specifically, this specification
a Web Service consumer can supply a Username Token as a
means of identifying the requestor by username, and
WS-Atomic Transaction this base fault type is used and extended by Web Services.
Final Specification
! Simple SOAP Binding Profile – The Simple SOAP Binding

mechanisms for associating policies with the subjects to
which they apply; the policies may be defined as part
of existing metadata about the subject or the policies may
dynamic discovery of services on ad-hoc and managed
networks.
Committee Draft provides support for multiple security token formats, trust
domains, signature formats and encryption technologies.
The token formats and semantics for using these are
optionally using a password (or shared secret, etc.) to
authenticate that identity to the Web Service producer.
1.1
OASIS
Committee Draft
WS-ServiceGroup (WSRF)
1.2
Reliability Specifications
! Web Services ReliableMessaging Policy Assertion
Basic Profile
Transaction
Profile consists of those Basic Profile 1.0 requirements be defined independently and associated through an defined in the associated profile documents. OASIS
Metadata
(WS-RM Policy) describes a domain-specific policy assertion WS-ReliableMessaging
Security
related to the serialization of the envelope and its external binding to the subject. ! WS-Atomic Transaction defines protocols that enable existing
representation in the message.
for WS-ReliableMessaging that that can be specified within
transaction processing systems to wrap their proprietary protocols
Working Draft
a policy alternative as defined in WS-Policy Framework.
and interoperate across different hardware and software vendors. WS-Reliability
! WS-ServiceGroup (WSRF) defines a means by which Web
WS-MetadataExchange Universal Description, WS-Security: WS-Federation Services and WS-Resources can be aggregated or grouped
1.1 WS-Composite Application together for a domain specific purpose. WS-Reliable Messaging Policy Assertion
Discovery and Integration (UDDI) Kerberos Binding 1.0
Framework (WS-CAF)
Basic Security Profile BEA Systems, Computer Associates,
3.0.2 WS-Reliability 1.0 IBM, Microsoft, BEA Systems, WS-ResourceProperties
1.0
WS-I
IBM, Microsoft, SAP, Sun Microsystems and
webMethods
Public Draft
OASIS
OASIS-Standard
1.1
OASIS
Microsoft, IBM, OASIS
Working Draft
RSA Security, and VeriSign
Initial Draft
1.0 · Arjuna Technologies, Fujitsu, IONA,
Oracle and Sun Microsystems
Committee Specification
1.2
OASIS
Resource Specifications
Board Approval Draft OASIS-Standard Working Draft
! WS-MetadataExchange enables a service to provide ! Universal Description, Discovery and Integration (UDDI) ! WS-Security: Kerberos Binding defines how to encode ! WS-Federation describes how to manage and broker the ! WS-Composite Application Framework (WS-CAF) is a Web Service Resource Framework
metadata to others through a Web services interface. Given defines a set of services supporting the description Kerberos tickets and attach them to SOAP messages. As trust relationships in a heterogeneous federated collection of three specifications aimed at solving problems ! WS-ResourceProperties specifies the means by which the
! Basic Security Profile defines the WS-I Basic Security only a reference to a Web service, a user can access a set and discovery of businesses, organizations, and other Web ! WS-Reliability is a SOAP-based protocol for exchanging well, it specifies how to add signatures and encryption to the environment including support for federated identities. that arise when multiple Web Services are used in combina- definition of the properties of a WS-Resource may be declared WS-BaseFaults
Profile 1.0, based on a set of non-proprietary Web services of WSDL /SOAP operations to retrieve the metadata that services providers, the Web services they make available, SOAP message, in accordance with WS-Security, which tion. It proposes standard, interoperable mechanisms for
Transaction
SOAP messages with guaranteed delivery, no duplicates, as part of the Web Service interface. The declaration of the
Messaging
specifications, along with clarifications and amendments describes the service. and the technical interfaces which may be used to access uses and references the Kerberos tokens. managing shared context and ensuring business processes
and guaranteed message ordering. WS-Reliability is WS-Resource properties represents a projection of or a view WS-ServiceGroup
Security
to those specifications which promote interoperability. those services. defined as SOAP header extensions and is independent of achieve predictable results and recovery from failure. on the WS-Resource state.
the underlying protocol. This specification contains a WS-ResourceProperties
binding to HTTP. WS-Context (WS-CTX) WS-ResourceLifetime
Web Service Description Web Service Description WS-Security: WS-Trust 1.0 1.2
WS-ResourceLifetime
REL Token Profile Language 2.0 Language 2.0 Core SAML Token Profile BEA Systems, Computer Associates, IBM, Layer 7 Arjuna Technologies, Fujitsu, IONA, Oracle OASIS
This poster is not to be reproduced or transmitted in any form or for any purpose without the express permission of innoQ Deutschland GmbH. · Copyright
Technologies, Microsoft, Netegrity, Oblix, WS-Transfer
1.0 SOAP Binding 2.0 1.1 OpenNetwork, Ping Identity Corporation,
and Sun Microsystems
Committee Draft
Working Draft
WS-I 2.0 W3C OASIS Reactivity, RSA Security, VeriSign and Westbridge Resource Representation SOAP Header Block (RRSHB)
Working Group Draft Candidate Recommendation Public Review Draft ! WS-ResourceLifetime is to standardize the terminology,
W3C · Working Draft Technology · Initial Draft ! WS-Context (WS-CTX) is intended as a lightweight mechanism concepts, message exchanges, WSDL and XML needed to
for allowing multiple Web Services to share a common context.
Management Specifications
monitor the lifetime of, and destroy WS-Resources.
! Web Service Description Language SOAP Binding ! Web Service Description Language 2.0 Core is an XML- ! WS-Security: SAML Token Profile defines the use of ! WS-Trust describes a framework for trust models that enables Additionally, it defines resource properties that may be used
! REL Token Profile is based on a non-proprietary
Web services specification, along with clarifications and
describes the concrete details for using WSDL 2.0 in based language for describing Web services and how to Security Assertion Markup Language (SAML) v1.1 assertions Web Services to securely interoperate. It uses WS-Security base WS-Coordination to inspect and monitor the lifetime of a WS-Resource.
conjunction with SOAP 1.1 protocol. access them. It specifies the location of the service and the in the context of WSS: SOAP Message Security including mechanisms and defines additional primitives and extensions
amendments to that specification which promote Framework (WS-CF)
Meta
operations (or methods) the service exposes. for the purpose of securing SOAP messages and SOAP for security token exchange to enable the issuance and
interoperability. message exchanges. dissemination of credentials within different trust domains. 1.0 · Arjuna Technologies, Fujitsu, IONA, WS-Transfer WS-Management
Messaging
Security
Oracle and Sun Microsystems W3C
Management Of Web Services
Committee Draft W3C Member Submission
Resource
Web Service Description WS-Security: X.509 WS-SecureConversation ! WS-Coordination Framework (WS-CF) allows the Management Using Web Services
SAML Token Profile BEA Systems, Computer Associates, IBM, management and coordination in a Web Services interaction ! WS-Transfer describes a general SOAP-based protocol for
1.0 Language 1.1 Certificate Token Profile Layer 7 Technologies, Microsoft, Netegrity, of a number of activities related to an overall application. accessing XML representations of Web service-based resources.
Service Modeling Language
WS-I 1.1 1.1 Oblix, OpenNetwork,
Working Group Draft W3C OASIS Ping Identity Corporation, Reactivity, WS-Transaction Resource Representation
Note Public Review Draft RSA Security, VeriSign and Westbridge
Technology ·Public Draft
Management (WS-TXM)
SOAP Header Block (RRSHB)
W3C
Business Process Specifications
! SAML Token Profile is based on a non-proprietary ! Web Service Description Language 1.1 is an XML-based ! WS-Security: X.509 Certificate Token Profile describes ! WS-SecureConversation specifies how to manage and Recommendation
Web services specification, along with clarifications and Oracle and Sun Microsystems
language for describing Web services and how to access the use of the X.509 authentication framework with the authenticate message exchanges between parties including Committee Draft Business Process Execution Language for Web Services
amendments to that specification which promote them. It specifies the location of the service and the ! Resource Representation SOAP Header Block (RRSHB)
WS-Security: SOAP Message Security specification. security context exchange and establishing and deriving
interoperability. operations (or methods) the service exposes. session keys. ! WS-Transaction Management (WS-TXM) defines a core infrastructure complements MTOM by defining mechanisms for Web Service Choreography Description Language
service consisting of a Transaction Service for Web Services. describing and conveying non-XML resource representations
Transaction
Messaging
in a SOAP 1.2 message.
Reliability
Web Service Choreography Interface
Security
Conformance Claim WS-Choreography Model Overview
Attachment Mechanism (CCAM)
1.0 Business Process Management Language
WS-I
Final Specification Business Process Execution Language for Web Serv. 2.0
XML Process Definition Language

! Conformance Claim Attachment Mechanism (CCAM)
catalogues mechanisms that can be used to attach WS-I
Messaging Specifications SOAP

Profile Conformance Claims to Web services artefacts
(e.g., WSDL descriptions, UDDI registries).
Transaction Specifications
Messaging
Metadata
WS-Business Activity
Reliable Asynchronous " WS-Notification is a " WS-BrokeredNotification " WS-BaseNotification " WS-Eventing defines a " WS-Addressing – Core " SOAP Message
Messaging Profile (RAMP) family of related white defines the interface for standardizes the terminology, baseline set of operations provides transport-neutral SOAP Message Transmission WS-Atomic Transaction
1.0 WS-Notification papers and specifications WS-BrokeredNotification the NotificationBroker. WS-BaseNotification concepts, operations, WSDL
WS-Eventing that allow Web services to WS-Addressing – Core mechanisms to address SOAP Transmission Optimization
Optimization
WS-Coordination
Security
WS-I that define a standard A NotificationBroker is an and XML needed to express provide asynchronous Web services and messages. Mechanism
1.3 1.3 1.3 1.0 1.2
Working Draft OASIS
Web services approach to
notification using a topic- OASIS
intermediary, which, among
other things, allows OASIS
the basic roles involved in
Web services publish and
W3C notifications to interested
parties. W3C
This specification defines
XML elements to identify W3C Mechanism (MTOM) describes an
abstract feature for WS-Composite Application Framework
OASIS-Standard OASIS-Standard OASIS-Standard Public Draft Recommendation Recommendation 1.0 · W3C
Reliability
based publish/subscribe publication of messages subscribe for notification Web service endpoints and optimizing the
! Reliable Asynchronous Messaging Profile (RAMP) is a pattern. from entities that are not message exchange. to secure end-to-end Recommendation transmission and/or WS-Transaction Management
profile, in the fashion of the WS-I profiles, that enables, themselves service endpoint identification in wire format of a
among other things, basic B2B integration scenarios using providers. messages. SOAP message. WS-Context
Web services technologies.
" WS-Enumeration describes " WS-Topics defines three " WS-Addressing – WSDL " WS-Addressing – SOAP " SOAP is a lightweight,
WS-Enumeration a general SOAP-based
protocol for enumerating WS-Topics
topic expression dialects
that can be used as sub-
WS-Addressing – WSDL Binding defines how the
abstract properties defined
WS-Addressing – Binding provides transport-
neutral mechanisms to SOAP
XML-based protocol for
exchange of information
WS-Coordination Framework
Systinet, Microsoft, Sonic Software, BEA a sequence of XML
1.3
scription expressions in Binding in Web Services Addressing SOAP Binding address Web services and
1.1
in a decentralized,
Systems and
Presentation Specifications
elements that is suitable subscribe request messages 1.0 – Core are described using 1.0 messages. distributed environment.
for traversing logs, message OASIS and other parts of the WSDL. W3C
Computer Associates W3C W3C
queues, or other linear OASIS-Standard WS-Notification system. Note
Public Draft information models. Candidate Recommendation Recommendation
Reliab.
Secur.
Mess.
Web Services for Remote Portlets
Standards Bodies
The Organization for the Advancement of Structured Information
Standards (OASIS) is a not-for-profit, international consortium
that drives the development, convergence, and adoption of e-business standards. The
consortium produces more Web services standards than any other organization along with stan-
dards for security, e-business, and standardization efforts in the public sector and for applica-
tion-specific markets. Founded in 1993, OASIS has more than 4,000 participants representing
Version 3.0 · February 2007
over 600 organizations and individual members in 100 countries.
The World Wide Web Consortium (W3C) was created in October 1994 to lead the
XML Specifications
World Wide Web to its full potential by developing common protocols that promote
its evolution and ensure its interoperability. W3C has over 350 Member organiza-
tions from all over the world and has earned international recognition for its contributions to the
growth of the Web. W3C is designing the infrastructure, and defining the architecture and the core
technologies for Web services. In September 2000, W3C started the XML Protocol Activity to address
the need for an XML-based protocol for application-to-application messaging. In January 2002, the
Web Services Activity was launched, subsuming the XML Protocol Activity and extending its scope. " XML – Extensible Markup " XML – Extensible Markup " Namespaces in XML " XML Information Set is " XML Schema – XML " XML binary Optimized " Describing Media Content
Language is a pared-down Language is a pared-down provides a simple method an abstract data set to Schema Definition Language
XML binary Optimized Packaging (XOP) is an XML Describing Media Content of Binary Data in XML
The Web Services Interoperability Organization (WS-I) is an open industry
organization chartered to promote Web services interoperability across platforms, XML 1.1 version of SGML, designed
especially for Web
XML 1.0 version of SGML, designed
especially for Web
Namespaces in XML for qualifying element and
attribute names used in XML
XML Information Set provide a consistent set of
definitions for use in other
XML Schema is an XML language for
describing and constraining Packaging (XOP)
language for describing and
constraining the content of of Binary Data in XML
(DMCBDX) specifies how to
indicate the content-type
operating systems and programming languages. The organization’s diverse community of Web 1.1 documents. It allows one to 1.0 documents. It allows one to 1.1 documents by associating 1.0 specifications that need to 1.1 the content of XML XML documents. associated with binary
services leaders helps customers to develop interoperable Web services by providing guidance, W3C W3C W3C W3C W3C 1.0 (DMCBDX)
create own customized tags, create own customized tags, them with namespaces refer to the information documents. element content in an XML
recommended practices and supporting resources. Specifically, WS-I creates, promotes and
Recommendation enabling the definition, Recommendation enabling the definition, Recommendation identified by IRI references. Recommendation in a well-formed XML Working Draft W3C W3C document and to specify, in
supports generic protocols for the interoperable exchange of messages between Web services. Recommendation
transmission, validation, and transmission, validation, and document. Note XML Schema, the expected
The Internet Engineering Task Force (IETF) is a large open international
interpretation of data interpretation of data content-type(s) associated
between applications and between applications and with binary element
community of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the smooth between organizations. between organizations. content. innoQ Deutschland GmbH innoQ Schweiz GmbH
operation of the Internet.
Halskestraße 17 Gewerbestrasse 11
D-40880 Ratingen CH-6330 Cham
Phone +49 21 02 77 162 -100 Phone +41 41 743 01 11
info@innoq.com · www.innoq.com

Acteurs majeurs
} W3C (World Wide Web Consortium)
} Consortium académique international fondé en 1994
} Principal organisme de standardisation concernant le web
} HTTP, URI, HTML, XML…
} A l’origine des technologies qui forment la base des Web Services
} SOAP, WSDL
} Mécanisme de recommandations
} OASIS
(Organization for the Advancement of Structured Information Standards)
} Consortium international d’éditeurs de logiciel
} Objectif = développement, convergence et adoption de standards e-business
} Organisme le plus productif dans le domaine des Web Services :
} UDDI, BPEL, WSRP, WS-Security, SAML, WS-Transactions…

Principales technologies
XML XML
UDDI UDDI
Client Fournisseur
Internet
Application HTTP Web Service
SOAP WSDL
XML XML
Comment ça marche ?

HTTP (HyperText Transfer Protocol)
} Protocole de communication dédié au web
} Chaque ressource du web est identifiée par une URL
} Mode de communication = requête / réponse

} Requête
GET /index.html HTTP/1.1
} Méthode de requête + nom ressource Host: www.example.com
‣ Lecture : GET, HEAD…
‣ Modification : POST, PUT, DELETE…
} En-tête : nom du serveur, …
HTTP/1.1 200 OK
} Réponse Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
} En-tête : code de statut, type de serveur, Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
type de contenu… Etag: "3f80f-1b6-3e1cb03b"
} Contenu de la ressource demandée Accept-Ranges: bytes
Content-Length: 438
Connection: close
} Non conservation de l’état Content-Type: text/html; charset=UTF-8
entre deux couples requête/réponse
HTTP
Exemple
} Accès en lecture à une page web pour affichage dans un navigateur
Serveur web
Client wwwdi.supelec.fr
1 – Requête :
C:\server\htdocs\hardebolle\
GET http://wwwdi.supelec.fr/hardebolle/fichier. html
3 – Affichage : HTML
interprétation HTML
HTML
2 – Réponse :
fichier. html contenu de fichier.html
fichier. html

MIME
(Multipurpose Internet Mail Extension)
} Standard définissant le type et le format de contenus échangés sur internet
} Contenu textuel : langue, codage des caractères…
} Contenu multimédia (images, sons, films…) : type de média…
} Transfert sous forme binaire
} Contenus multiples (pièces jointes…)
} Utilisé pour les emails avec SMTP
} Utilisé pour le web avec HTTP

HTTP/1.1 200 OK
} En-tête « Content-Type: type/sous-type » Date: Mon, 23 May 2005 22:38:34 GMT
} Exemples : Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
} text/xml Etag: "3f80f-1b6-3e1cb03b"
} audio/mpeg Accept-Ranges: bytes
Content-Length: 438
} image/jpeg Connection: close
} application/pdf Content-Type: text/html; charset=UTF-8

XML (eXtensible Markup Language)
} Standard du W3C depuis 1998
} XML = langage permettant de structurer des données de manière logique
} Extensible
} Indépendant des plates-formes et des systèmes d’exploitation
} Concernant uniquement le contenu, pas la forme (apparence)
} Document XML = structure arborescente auto-descriptive

} Structure des données = balises personnalisées (« tags »)
} Données = texte
auteur
prenom nom date_naissance adresse poids taille
Gaston Lagaffe
compagnie boite_postale ville code_postal pays

Structure de documents XML
Exemple
<?xml version="1.0" encoding="UTF-8"?>
<auteur>
<prenom>Gaston</prenom>
<nom>Lagaffe</nom>
<date_naissance>30/03/1976</date_naissance>
<adresse>
<compagnie>Journal Spirou</compagnie>
<boite_postale>355</ boite_postale >
<ville>Paris Cedex</ville>
<code_postal>75116</ code_postal >
<pays code="ISO-3166">FR</pays>
</adresse>
<taille unite="cm">180</taille>
<poids unite="kg">70</ poids > auteur
</auteur>
prenom nom date_naissance adresse poids taille unite
Gaston Lagaffe 180 cm

compagnie boite_postale ville code_postal pays

Validité d’un document XML
} Grammaire = définition d’un vocabulaire valide et de règles de structure
} Pour XML, grammaire = schéma
} Définit les balises et leurs attributs
} Définit les contraintes de structure des documents
} XML Schema = un des langages de description de schémas
<xsd:element name="auteur"> <auteur>
<xsd:complexType> <prenom>Gaston</prenom>
<xsd:sequence> <nom>Lagaffe</nom>
<xsd:element name="prenom" type="xsd:string"/> </auteur>
<xsd:element name="nom" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
} Espace de noms = préfixe permettant d’éliminer les conflits lorsque

plusieurs balises ont des noms identiques
<liv:auteur xmlns:liv="http://livres">…</liv:auteur>

XML XML
UDDI UDDI
Client Fournisseur
Internet
SOAP WSDL
XML XML
WSDL
(Web Service Description Language)
} Standard du W3C
} Version 1.1 en 2001
} Version 2.0 en 2007, encore peu supporté par les outils
} Objectif = décrire l'interface publique d'un Web Service

(contrat de service)
} Grammaire dérivée d’XML
} Interface d’un Web Service avec WSDL

} Web Service = ensemble de ports de connexions mettant à disposition des
opérations qui reçoivent et envoient des messages
} Deux types d’informations
} Fonctionnelles : interface du service (signature des méthodes…)
} Techniques : URL, protocole…
} Fichier WSDL utilisable par des outils de génération de code

Structure d’un fichier WSDL 1.1
Service
Nom et adresse (URL)
du service
Informations
Port Port
techniques
Protocole de transport et
Binding Binding format des messages
PortType
Operation Operation
Interface
du service Input Output
(fonctionnelle)
Message Noms, types et ordre des paramètres
Type
Type
Part Part Type

Structure d'un fichier WSDL 1.1
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" …>
<types> […] </types>
<message […]><part […]/></message>
<portType […]>
<operation […]>
<input […] />
<output […] />
</operation>
</portType>
<binding […]>[…]</binding>
<service […]>
<port […]>[…]</port>
</service>
</definitions>
WSDL
Exemple d’interface de service
} Avec des types simples
<portType name="Hello">
<operation name="sayHello">
<input message="tns:sayHello" />
<output message="tns:sayHelloResponse" />
</operation>
</portType>
<message name="sayHello">
<part name="name" type="xsd:string" />
</message>
<message name="sayHelloResponse">
<part name="return" type="xsd:string" />
</message>

WSDL
Exemple d’interface de service
} Avec des types complexes
} Déclarés dans un fichier XSD séparé
} Ou déclarés dans le fichier WSDL
<part name="parameters" element="sayHello" />
<xsd:element name="sayHello" >

<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xs:string" minOccurs="0"/>
…
</xsd:sequence>
</xsd:complexType>
</xsd:element>
} Attention aux espaces de noms !

WSDL
Exemple d’informations techniques
<binding name="HelloPortBinding" type="tns:Hello">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="HelloService">
<port name="HelloPort" binding="tns:HelloPortBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port>
</service>

XML XML
UDDI UDDI
Client Fournisseur
Internet
SOAP WSDL
XML XML
SOAP (Simple Object Access Protocol)
} Standard du W3C
} Version1.2 en 2003
} Objectif = formater les requêtes et les réponses échangées entre client et
Web Service pour le transport (notamment sur HTTP)
} Grammaire dérivée d’XML
} Définit principalement <Envelope>!

!
} Un modèle de structure pour les requêtes et ! <Header>!
les réponses (messages) ! <transId>1234</transId>!
! </Header>!
} Envelope : obligatoire, définit un message SOAP !
! <Body>!
} Header : optionnel, informations non applicatives ! <add>!
(sécurité…) ou destinées aux intermédiaires ! <varx>3</varx>!
! <vary>4</varY>!
} Body : décrit la requête ou la réponse ! </add>!
! </Body>!
!
</Envelope>!
} Un modèle de traitement des messages

SOAP
Exemple
} Requête : sayHello("Robert")
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns:sayHello xmlns:ns="http://hello/">
<name>Robert</name>
</ns:sayHello>
</soap:Body>
</soap:Envelope>
Précédés d’un
message HTTP !
} Réponse : "Hello dear Robert !"
<soap:Body>
<ns:sayHelloResponse xmlns:ns="http://hello/">
<return>Hello Robert !</return>
</ns:sayHelloResponse>
</soap:Body>
</soap:Envelope>
XML XML
UDDI UDDI
Client Fournisseur
Internet
SOAP WSDL
XML XML
UDDI (Universal Discovery
Description and Integration)
} Standard porté par un consortium d’industriels
} Version 3 en 2005
} Objectif = publication et découverte de Web Services sur un réseau
} Définit :
} UDDI Business Registry (UBR) = annuaire pour permettre d'automatiser les
communications entre prestataires, clients, etc. (orienté « business »)
} Méthodes de publications (basées sur SOAP)
} Méthodes de consultation (basées sur SOAP)
Pages blanches Pages jaunes Pages vertes

§ Nom de la société § Index services et produits § Procédures e-business
§ Information sur les contacts § Code d’industrie (APE, etc.) § Descriptions technique des services
§ Description texte § Index géographique § Paramètres des services
§ Identifications (DUNS, SIRET, etc.) § Taxonomie

Web
Et lesServices Standards
autres WS-* ? Overview Dependencies
© innoQ Deutschland GmbH. All Rights Reserved. The poster may also contain references to other company, organisation, brand and product names. These company, organisation, brand and product names are used herein for identification purposes only and may be the trademarks of their respective owners.
Messaging Specifications
SOAP 1.1
Interoperability Business Process Specifications Management Specifications Presentation

SOAP 1.2
SOAP Message Transmission Optimization Mechanism
Issues Specifications
WS-Notification
Business Process Execution WS-Choreography Model Web Service Choreography Web Service Choreography Management Using Web Management Of WS-BaseNotification
WS-Management
Metadata
Resource
Security
Language for Web Services 1.1 Overview Interface Description Language Services (WSDM-MUWS) Web Services (WSDM-MOWS) AMD, Dell, Intel, Microsoft and Sun WS-Topics
(BPEL4WS) · 1.1 · BEA Systems, IBM, (WSCI) · 1.0 · W3C 1.0 1.0 Microsystems
1.0 · W3C (CDL4WS) · 1.0 · W3C WS-BrokeredNotification
Microsoft, SAP, Sun Microsystems, SAP, BEA Systems OASIS OASIS Published Specification Web Services for Remote
Working Draft Candidate Recommendation
Basic Profile Siebel Systems · OASIS-Standard and Intalio · Note OASIS-Standard OASIS-Standard
Portlets (WSRP) WS-Addressing – Core
1.1
WS-I ! Business Process Execution Language for Web Services ! WS-Choreography Model Overview defines the format ! Web Service Choreography Interface (WSCI) describes ! Web Service Choreography Description Language ! Web Service Distributed Management: Management Using ! Web Service Distributed Management: Management Of ! WS-Management describes a general SOAP-based 2.0 WS-Addressing – WSDL Binding
1.1(BPEL4WS) provides a language for the formal and structure of the (SOAP) messages that are exchanged, how Web Service operations can be choreographed in the (CDL4WS) is to specify a declarative, XML based language Web Services (WSDM-MUWS) defines how an IT resource Web Services (WSDM-MOWS) addresses management of protocol for managing systems such as PCs, servers, OASIS
Final Specification specification of business processes and business interaction and the sequence and conditions in which the messages context of a message exchange in which the Web Service that defines from a global viewpoint the common and connected to a network provides manageability interfaces the components that form the network, the Web services devices, Web services and other applications, and other
protocols using Web Services. are exchanged. participates. complementary observable behaviour, where message such that the IT resource can be managed locally and from endpoints, using Web services protocols. manageable entities. Committee Draft WS-Addressing – SOAP Binding
exchanges occur, and when the jointly agreed ordering remote locations using Web services technologies.
! Basic Profile – The Basic Profile 1.1 provides rules are satisfied. " Web Services for Remote Portlets (WSRP) defines a WS-Eventing
implementation guidelines for how related set of non-
proprietary Web Service specifications should be used Business Process Execution Business Process Management XML Process Definition
set of interfaces and related semantics which standardize
interactions with components providing user-facing WS-Enumeration
together for best interoperability. Language for Web Services 2.0 Language (BPML) Language (XPDL) Service Modeling Language markup, including the processing of user interactions with
that markup.
(BPEL4WS) · 2.0 1.1 IBM, BEA, BMC, Cisco, Dell, HP, Intel,
Metadata Specifications
2.0
OASIS, BEA Systems, IBM, Microsoft, SAP, BPMI.org Microsoft, Sun
Final
Siebel Systems · Committee Draft Final Draft Draft Specification
Basic Profile
1.2 ! Business Process Execution Language for Web Services ! Business Process Management Language (BPML) ! XML Process Definition Language (XPDL) provides an WS-Policy
2.0 (BPEL4WS) provides a language for the formal provides a meta-language for expressing business XML file format that can be used to interchange process ! Servcie Modeling Language (SML) is used to model
WS-I specification of business processes and business interaction processes and supporting entities. models between tools. complex IT services and systems, including their structure, WS-PolicyAssertions
Working Group Draft protocols using Web Services.
Security
constraints, policies, and best practices.
WS-PolicyAttachment
! Basic Profile – The Basic Profile 1.2 builds on Basic Profile
Messaging
1.1 by incorporating Basic Profile 1.1 errata, requirements WS-Discovery
from Simple SOAP Binding Profile 1.0, and adding support
for WS-Addressing and MTOM. WS-MetadataExchange
Universal Description, Discovery and Integration
Web Service Description Language 1.1

Basic Profile
Web Service Description Language 2.0 Core
Metadata Specifications Reliability Security Specifications Transaction Resource

2.0
WS-I
Working Group Draft Web Service Description Language 2.0 SOAP Binding
! Basic Profile – The Basic Profile 2.0 is an update of WS-I

BP that includes a profile of SOAP 1.2.
WS-Policy WS-PolicyAssertions Specifications WS-Security WS-SecurityPolicy Specifications Specifications Security Specifications
1.1 1.1 WS-Security
1.5 1.1
BEA Systems, IBM, Microsoft,
W3C
IBM, Microsoft, SAP
OASIS
RSA Security, VeriSign WS-Coordination Web Services WS-Security: SOAP Message Security
Attachments Profile Working Draft
Public Draft WS-ReliableMessaging OASIS-Standard
Public Draft 1.1 Resource Framework (WSRF)
1.0 1.1 OASIS WS-Security: Kerberos Binding
1.2
WS-I ! WS-Policy describes the capabilities and constraints of ! WS-PolicyAssertions provides an initial set of assertions OASIS ! WS-Security is a communications protocol providing a ! WS-SecurityPolicy defines how to describe policies related Working Draft OASIS
Final Specification the policies on intermediaries and endpoints (e.g. business to address some common needs of Web Services Committee Draft means for applying security to Web Services. to various features defined in the WS-Security specification. WS-Security: SAML Token Profile
Messaging
OASIS-Standard
Reliability
Metadata
rules, required security tokens, supported encryption applications. ! WS-Coordination describes an extensible framework for providing
algorithms, privacy rules). protocols that coordinate the actions of distributed applications. ! Web Services Resource Framework (WSRF) defines a family of WS-Security: X.509 Certificate Token Profile
! Attachments Profile – The Attachment Profile 1.0 specifications for accessing stateful resources using Web Services.
complements the Basic Profile 1.1 to add support ! WS-ReliableMessaging describes a protocol that allows
WS-Business Activity WS-Security: Username Token Profile
for interoperable SOAP Messages with attachments-based
Web Services.
Web services to communicate reliable in the presence of
software component, system, or network failures. It defines WS-Security: WS-Security: 1.1 WS-BaseFaults (WSRF) WS-SecurityPolicy
a SOAP binding that is required for interoperability. SOAP Message Security Username Token Profile OASIS 1.2
WS-PolicyAttachment WS-Discovery 1.1 1.1 Working Draft OASIS WS-Trust
1.2 Microsoft, BEA Systems, Canon, OASIS OASIS Working Draft
! WS-Business Activity provides the definition of the business activity
Simple SOAP W3C Intel and webMethods WS-Reliable Messaging Public Review Draft Public Review Draft coordination type that is to be used with the extensible coordination WS-Federation
! WS-BaseFaults (WSRF) defines a base set of information
Binding Profile W3C Member Submission Draft Policy Assertion (WS-RM Policy) framework described in the WS-Coordination specification. that may appear in fault messages. WS-BaseFaults defines an WS-SecureConversation
1.0 ! WS-Security: SOAP Message Security describes ! WS-Security: Username Token Profile describes how XML schema type for base faults, along with rules for how
1.1
WS-I
! WS-PolicyAttachment defines two general-purpose ! WS-Discovery defines a multicast discovery protocol for OASIS
enhancements to SOAP messaging to provide message
integrity and confidentiality. Specifically, this specification
a Web Service consumer can supply a Username Token as a
means of identifying the requestor by username, and
WS-Atomic Transaction this base fault type is used and extended by Web Services.
Final Specification
! Simple SOAP Binding Profile – The Simple SOAP Binding

mechanisms for associating policies with the subjects to
which they apply; the policies may be defined as part
of existing metadata about the subject or the policies may
dynamic discovery of services on ad-hoc and managed
networks.
Committee Draft provides support for multiple security token formats, trust
domains, signature formats and encryption technologies.
The token formats and semantics for using these are
optionally using a password (or shared secret, etc.) to
authenticate that identity to the Web Service producer.
1.1
OASIS
Committee Draft
WS-ServiceGroup (WSRF)
1.2
Reliability Specifications
! Web Services ReliableMessaging Policy Assertion
Basic Profile
Transaction
Profile consists of those Basic Profile 1.0 requirements be defined independently and associated through an defined in the associated profile documents. OASIS
Metadata
(WS-RM Policy) describes a domain-specific policy assertion WS-ReliableMessaging
Security
related to the serialization of the envelope and its external binding to the subject. ! WS-Atomic Transaction defines protocols that enable existing
representation in the message.
for WS-ReliableMessaging that that can be specified within
transaction processing systems to wrap their proprietary protocols
Working Draft
a policy alternative as defined in WS-Policy Framework.
and interoperate across different hardware and software vendors. WS-Reliability
! WS-ServiceGroup (WSRF) defines a means by which Web
WS-MetadataExchange Universal Description, WS-Security: WS-Federation Services and WS-Resources can be aggregated or grouped
1.1 WS-Composite Application together for a domain specific purpose. WS-Reliable Messaging Policy Assertion
Discovery and Integration (UDDI) Kerberos Binding 1.0
Framework (WS-CAF)
Basic Security Profile BEA Systems, Computer Associates,
3.0.2 WS-Reliability 1.0 IBM, Microsoft, BEA Systems, WS-ResourceProperties
1.0
WS-I
IBM, Microsoft, SAP, Sun Microsystems and
webMethods
Public Draft
OASIS
OASIS-Standard
1.1
OASIS
Microsoft, IBM, OASIS
Working Draft
RSA Security, and VeriSign
Initial Draft
Oracle and Sun Microsystems
Committee Specification
1.2
OASIS
Resource Specifications
Board Approval Draft OASIS-Standard Working Draft
! WS-MetadataExchange enables a service to provide ! Universal Description, Discovery and Integration (UDDI) ! WS-Security: Kerberos Binding defines how to encode ! WS-Federation describes how to manage and broker the ! WS-Composite Application Framework (WS-CAF) is a Web Service Resource Framework
metadata to others through a Web services interface. Given defines a set of services supporting the description Kerberos tickets and attach them to SOAP messages. As trust relationships in a heterogeneous federated collection of three specifications aimed at solving problems ! WS-ResourceProperties specifies the means by which the
! Basic Security Profile defines the WS-I Basic Security only a reference to a Web service, a user can access a set and discovery of businesses, organizations, and other Web ! WS-Reliability is a SOAP-based protocol for exchanging well, it specifies how to add signatures and encryption to the environment including support for federated identities. that arise when multiple Web Services are used in combina- definition of the properties of a WS-Resource may be declared WS-BaseFaults
Profile 1.0, based on a set of non-proprietary Web services of WSDL /SOAP operations to retrieve the metadata that services providers, the Web services they make available, SOAP message, in accordance with WS-Security, which tion. It proposes standard, interoperable mechanisms for
Transaction
SOAP messages with guaranteed delivery, no duplicates, as part of the Web Service interface. The declaration of the
Messaging
specifications, along with clarifications and amendments describes the service. and the technical interfaces which may be used to access uses and references the Kerberos tokens. managing shared context and ensuring business processes
and guaranteed message ordering. WS-Reliability is WS-Resource properties represents a projection of or a view WS-ServiceGroup
Security
to those specifications which promote interoperability. those services. defined as SOAP header extensions and is independent of achieve predictable results and recovery from failure. on the WS-Resource state.
the underlying protocol. This specification contains a WS-ResourceProperties
binding to HTTP. WS-Context (WS-CTX) WS-ResourceLifetime
Web Service Description Web Service Description WS-Security: WS-Trust 1.0 1.2
WS-ResourceLifetime
REL Token Profile Language 2.0 Language 2.0 Core SAML Token Profile BEA Systems, Computer Associates, IBM, Layer 7 Arjuna Technologies, Fujitsu, IONA, Oracle OASIS
This poster is not to be reproduced or transmitted in any form or for any purpose without the express permission of innoQ Deutschland GmbH. · Copyright
Technologies, Microsoft, Netegrity, Oblix, WS-Transfer
1.0 SOAP Binding 2.0 1.1 OpenNetwork, Ping Identity Corporation,
and Sun Microsystems
Committee Draft
Working Draft
WS-I 2.0 W3C OASIS Reactivity, RSA Security, VeriSign and Westbridge Resource Representation SOAP Header Block (RRSHB)
Working Group Draft Candidate Recommendation Public Review Draft ! WS-ResourceLifetime is to standardize the terminology,
W3C · Working Draft Technology · Initial Draft ! WS-Context (WS-CTX) is intended as a lightweight mechanism concepts, message exchanges, WSDL and XML needed to
for allowing multiple Web Services to share a common context.
Management Specifications
monitor the lifetime of, and destroy WS-Resources.
! Web Service Description Language SOAP Binding ! Web Service Description Language 2.0 Core is an XML- ! WS-Security: SAML Token Profile defines the use of ! WS-Trust describes a framework for trust models that enables Additionally, it defines resource properties that may be used
! REL Token Profile is based on a non-proprietary
Web services specification, along with clarifications and
describes the concrete details for using WSDL 2.0 in based language for describing Web services and how to Security Assertion Markup Language (SAML) v1.1 assertions Web Services to securely interoperate. It uses WS-Security base WS-Coordination to inspect and monitor the lifetime of a WS-Resource.
conjunction with SOAP 1.1 protocol. access them. It specifies the location of the service and the in the context of WSS: SOAP Message Security including mechanisms and defines additional primitives and extensions
amendments to that specification which promote Framework (WS-CF)
Meta
operations (or methods) the service exposes. for the purpose of securing SOAP messages and SOAP for security token exchange to enable the issuance and
interoperability. message exchanges. dissemination of credentials within different trust domains. 1.0 · Arjuna Technologies, Fujitsu, IONA, WS-Transfer WS-Management
Messaging
Security
Oracle and Sun Microsystems W3C
Management Of Web Services
Committee Draft W3C Member Submission
Resource
Web Service Description WS-Security: X.509 WS-SecureConversation ! WS-Coordination Framework (WS-CF) allows the Management Using Web Services
SAML Token Profile BEA Systems, Computer Associates, IBM, management and coordination in a Web Services interaction ! WS-Transfer describes a general SOAP-based protocol for
1.0 Language 1.1 Certificate Token Profile Layer 7 Technologies, Microsoft, Netegrity, of a number of activities related to an overall application. accessing XML representations of Web service-based resources.
Service Modeling Language
WS-I 1.1 1.1 Oblix, OpenNetwork,
Working Group Draft W3C OASIS Ping Identity Corporation, Reactivity, WS-Transaction Resource Representation
Note Public Review Draft RSA Security, VeriSign and Westbridge
Technology ·Public Draft
Management (WS-TXM)
SOAP Header Block (RRSHB)
W3C
Business Process Specifications
! SAML Token Profile is based on a non-proprietary ! Web Service Description Language 1.1 is an XML-based ! WS-Security: X.509 Certificate Token Profile describes ! WS-SecureConversation specifies how to manage and Recommendation
Web services specification, along with clarifications and Oracle and Sun Microsystems
language for describing Web services and how to access the use of the X.509 authentication framework with the authenticate message exchanges between parties including Committee Draft Business Process Execution Language for Web Services
amendments to that specification which promote them. It specifies the location of the service and the ! Resource Representation SOAP Header Block (RRSHB)
WS-Security: SOAP Message Security specification. security context exchange and establishing and deriving
interoperability. operations (or methods) the service exposes. session keys. ! WS-Transaction Management (WS-TXM) defines a core infrastructure complements MTOM by defining mechanisms for Web Service Choreography Description Language
service consisting of a Transaction Service for Web Services. describing and conveying non-XML resource representations
Transaction
Messaging
in a SOAP 1.2 message.
Reliability
Web Service Choreography Interface
Security
Conformance Claim WS-Choreography Model Overview
Attachment Mechanism (CCAM)
1.0 Business Process Management Language
WS-I
Final Specification Business Process Execution Language for Web Serv. 2.0
XML Process Definition Language

! Conformance Claim Attachment Mechanism (CCAM)
catalogues mechanisms that can be used to attach WS-I
Messaging Specifications SOAP

Profile Conformance Claims to Web services artefacts
(e.g., WSDL descriptions, UDDI registries).
Transaction Specifications
Messaging
Metadata
WS-Business Activity
Reliable Asynchronous " WS-Notification is a " WS-BrokeredNotification " WS-BaseNotification " WS-Eventing defines a " WS-Addressing – Core " SOAP Message
Messaging Profile (RAMP) family of related white defines the interface for standardizes the terminology, baseline set of operations provides transport-neutral SOAP Message Transmission WS-Atomic Transaction
1.0 WS-Notification papers and specifications WS-BrokeredNotification the NotificationBroker. WS-BaseNotification concepts, operations, WSDL
WS-Eventing that allow Web services to WS-Addressing – Core mechanisms to address SOAP Transmission Optimization
Optimization
WS-Coordination
Security
WS-I that define a standard A NotificationBroker is an and XML needed to express provide asynchronous Web services and messages. Mechanism
1.3 1.3 1.3 1.0 1.2
Working Draft OASIS
Web services approach to
notification using a topic- OASIS
intermediary, which, among
other things, allows OASIS
the basic roles involved in
Web services publish and
W3C notifications to interested
parties. W3C
This specification defines
XML elements to identify W3C Mechanism (MTOM) describes an
abstract feature for WS-Composite Application Framework
OASIS-Standard OASIS-Standard OASIS-Standard Public Draft Recommendation Recommendation 1.0 · W3C
Reliability
based publish/subscribe publication of messages subscribe for notification Web service endpoints and optimizing the
! Reliable Asynchronous Messaging Profile (RAMP) is a pattern. from entities that are not message exchange. to secure end-to-end Recommendation transmission and/or WS-Transaction Management
profile, in the fashion of the WS-I profiles, that enables, themselves service endpoint identification in wire format of a
among other things, basic B2B integration scenarios using providers. messages. SOAP message. WS-Context
Web services technologies.
" WS-Enumeration describes " WS-Topics defines three " WS-Addressing – WSDL " WS-Addressing – SOAP " SOAP is a lightweight,
WS-Enumeration a general SOAP-based
protocol for enumerating WS-Topics
topic expression dialects
that can be used as sub-
WS-Addressing – WSDL Binding defines how the
abstract properties defined
WS-Addressing – Binding provides transport-
neutral mechanisms to SOAP
XML-based protocol for
exchange of information
WS-Coordination Framework
Systinet, Microsoft, Sonic Software, BEA a sequence of XML
1.3
scription expressions in Binding in Web Services Addressing SOAP Binding address Web services and
1.1
in a decentralized,
Systems and
Presentation Specifications
elements that is suitable subscribe request messages 1.0 – Core are described using 1.0 messages. distributed environment.
for traversing logs, message OASIS and other parts of the WSDL. W3C
Computer Associates W3C W3C
queues, or other linear OASIS-Standard WS-Notification system. Note
Public Draft information models. Candidate Recommendation Recommendation
Reliab.
Secur.
Mess.
Web Services for Remote Portlets
Standards Bodies
The Organization for the Advancement of Structured Information
Standards (OASIS) is a not-for-profit, international consortium
that drives the development, convergence, and adoption of e-business standards. The
consortium produces more Web services standards than any other organization along with stan-
dards for security, e-business, and standardization efforts in the public sector and for applica-
tion-specific markets. Founded in 1993, OASIS has more than 4,000 participants representing
Version 3.0 · February 2007
over 600 organizations and individual members in 100 countries.
The World Wide Web Consortium (W3C) was created in October 1994 to lead the
XML Specifications
World Wide Web to its full potential by developing common protocols that promote
its evolution and ensure its interoperability. W3C has over 350 Member organiza-
tions from all over the world and has earned international recognition for its contributions to the
growth of the Web. W3C is designing the infrastructure, and defining the architecture and the core
technologies for Web services. In September 2000, W3C started the XML Protocol Activity to address
the need for an XML-based protocol for application-to-application messaging. In January 2002, the
Web Services Activity was launched, subsuming the XML Protocol Activity and extending its scope. " XML – Extensible Markup " XML – Extensible Markup " Namespaces in XML " XML Information Set is " XML Schema – XML " XML binary Optimized " Describing Media Content
Language is a pared-down Language is a pared-down provides a simple method an abstract data set to Schema Definition Language
XML binary Optimized Packaging (XOP) is an XML Describing Media Content of Binary Data in XML
The Web Services Interoperability Organization (WS-I) is an open industry
organization chartered to promote Web services interoperability across platforms, XML 1.1 version of SGML, designed
especially for Web
XML 1.0 version of SGML, designed
especially for Web
Namespaces in XML for qualifying element and
attribute names used in XML
XML Information Set provide a consistent set of
definitions for use in other
XML Schema is an XML language for
describing and constraining Packaging (XOP)
language for describing and
constraining the content of of Binary Data in XML
(DMCBDX) specifies how to
indicate the content-type
operating systems and programming languages. The organization’s diverse community of Web 1.1 documents. It allows one to 1.0 documents. It allows one to 1.1 documents by associating 1.0 specifications that need to 1.1 the content of XML XML documents. associated with binary
services leaders helps customers to develop interoperable Web services by providing guidance, W3C W3C W3C W3C W3C 1.0 (DMCBDX)
create own customized tags, create own customized tags, them with namespaces refer to the information documents. element content in an XML
recommended practices and supporting resources. Specifically, WS-I creates, promotes and
Recommendation enabling the definition, Recommendation enabling the definition, Recommendation identified by IRI references. Recommendation in a well-formed XML Working Draft W3C W3C document and to specify, in
supports generic protocols for the interoperable exchange of messages between Web services. Recommendation
transmission, validation, and transmission, validation, and document. Note XML Schema, the expected
The Internet Engineering Task Force (IETF) is a large open international
interpretation of data interpretation of data content-type(s) associated
between applications and between applications and with binary element
community of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the smooth between organizations. between organizations. content. innoQ Deutschland GmbH innoQ Schweiz GmbH
operation of the Internet.
Halskestraße 17 Gewerbestrasse 11
D-40880 Ratingen CH-6330 Cham
Phone +49 21 02 77 162 -100 Phone +41 41 743 01 11
info@innoq.com · www.innoq.com

Comment exposer une application
sous forme de Web Service ?

Zoom : client + service
Client Fournisseur
SOAP/HTTP
WSDL
} Application « métier » (service ou client)
} Traitement du XML
} Pré-traitement du XML entrant Comment exposer une application
sous forme de Web Service ?
} Passage des appels à la couche métier
} Formulation des réponses en XML

Création d’un Web Service
avec Java EE
} Web Service = classe annotée
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService; Correspondance
annotation ⬌ WSDL
@WebService(serviceName="HelloService") (JAX-WS)
public class HelloService {
@WebMethod(operationName="sayHello")
public String sayHello(@WebParam(name = "n") String n) {
return "Hello dear "+n+" !";
}
}
} Le serveur d’application a un rôle majeur
} Gère le cycle de vie du composant
} Gère les communications (JAX-WS + JAX-B)
} Intercepte les requêtes SOAP, les transforme en appels de méthodes
} Intercepte les résultats d’appels de méthodes, les transforme en réponses SOAP
JAX-WS
(Java API for XML Web Services)
} API de Java Enterprise Edition et Standard Edition, basée sur JAX-B
} Objectif = conversion WSDL-Java et SOAP-Java

} Correspondance automatique et paramétrable entre WSDL et Java
} Génération automatique de WSDL à partir d’une classe (ou interface) Java
‣ Exposition du service
‣ Génération du WSDL chez le client à partir d’une interface
} Génération de code Java à partir de WSDL
‣ Génération d’un squelette de service à partir de son contrat
‣ Génération d’un stub chez le client
} Transformation automatiquement d’un appel de méthode Java en message SOAP
puis envoi, et réciproquement
} 3 modes
‣ Appel synchrone (bloquant)
‣ Appel asynchrone (non bloquant avec réponse)
‣ One-way RPC (non bloquant sans réponse)

Objets passés en XML : JAXB
(Java Architecture for XML Binding)
} API de Java Standard Edition
} Objectif = conversion XML-objets Java
= marshalling/unmarshalling
} Données nécessaires
} Schéma XML Schema
} ou classes Java annotées
} Support
} Génération de classes Java
annotées à partir d’un
schéma et inversement
} Génération d’une
représentation XML pour
un objet Java
} Création d’un objet Java
à partir d’une
représentation XML
} Validation Source : The Java EE 5 Tutorial

Exemple avec JAXB
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Book {
@XmlElement <?xml version="1.0" encoding="UTF-8"?>
private Long isbn; <book>
@XmlElement <isbn>2130565476</isbn>
private String title; <title>Penser l'éthique des ingénieurs</title>
</book>
public Book(){…}
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
…
}

Développement d’un Web Service
Client Fournisseur
SOAP/HTTP
WSDL
} Tâches du cycle de développement d’un Web Service

1. Définir le contrat du service
2. Développer le service
3. Développer la couche de traitement XML
4. Déployer sur le serveur
Suivant les technologies, certaines
5. Publier dans l’annuaire tâches sont automatisées…

Définition du contrat de service
« Code first » vs. « Contract first »
} Principe = } Principe =
1. Implémenter la logique métier 1. Ecrire le contrat WSDL
2. Générer automatiquement le 2. Implémenter la logique métier
contrat WSDL pour le publier Possibilité de générer le squelette de
} Avantages code de la logique métier à partir du
contrat
} Simple à réaliser
} Avantages
} Utilité pour exposer du code
legacy, ou pour faire des tests } Meilleur découplage interface –
implémentation, stabilité du WSDL
} Inconvénients
} Meilleures performances
} Variations dans le contrat généré généralement
} Dépendance entre le code et } Inconvénients
le contrat
} Plus complexe à réaliser
} Développement de l’application
cliente après développement du
service

Comment utiliser un Web Service
dans une application ?

Zoom : client + service
Client Fournisseur
SOAP/HTTP
WSDL
} Application « métier » (service ou client)
} Traitement du XML
Comment créer une
} Pré-traitement du XML entrant
application cliente
} Passage des appels à la couche métier pour un Web Service ?

Client d'un Web Service
} Comme en RMI, le client d'un Web Service a besoin d'utiliser un « stub »
pour pouvoir faire un appel de méthode sur un Web Service distant
} Stub = proxy = représentation du service dans l’espace du client,

que le client peut ensuite utiliser comme un composant local
et qui délèguera les appels au composant distant
JAX-WS
} Types de proxy :
} Stub statique : classes générées à partir du WSDL
} Proxy dynamique : classes générées à l'exécution
à partir du WSDL
} Dynamic Invocation Interface (DII) :
découverte dynamique du service à l'exécution
} Configuration : login / mot de passe, clé…

Création d’un client avec Java EE
URL wsdlURL = new URL("http://localhost:8080/HelloWebService/HelloService?WSDL");

QName serviceName = new QName("http://hello/", "HelloService");
Service serviceClient = Service.create(wsdlURL, serviceName);
System.out.println("serviceClient : "+serviceClient);
QName portName = new QName("http://hello/", "HelloServicePort");

HelloService portStub = serviceClient.getPort(portName, HelloService.class);
System.out.println("portStub : "+portStub);
System.out.println("réponse = " + portStub.sayHello("tutu tata"));

Développement d’un client
Client Fournisseur
SOAP/HTTP
WSDL
} Tâches du cycle de développement d’un client

1. Rechercher le service dans l'annuaire
2. Récupérer le contrat du service Suivant les technologies, certaines
3. Créer un proxy tâches sont automatisées…
4. Développer la couche de traitement XML
5. Utiliser le service et présenter les résultats (rendu)

Vue globale avec Java (SE + EE)
Serveur
d'Applications
Java EE
Client Fournisseur
SOAP/HTTP
WSDL
Java Java
JAX-WS JAX-WS
+JAXB +JAXB

Comment utiliser un annuaire
de Web Services ?

Publication du service
} Choisir un ou plusieurs registres
} Registre public (seekda.com, xmethods.net…)
} Registre de branche
} Registre privé
} A l’heure actuelle les registres sont majoritairement privés

(internes aux entreprises)
} Choisir une ou plusieurs catégories dans la taxonomie du registre

} Référencement

Interrogation d'un annuaire : JAXR
(JavaAPI for XMLRegistries)
} API de Java Enterprise Edition
} Objectif = accès à un registre de Web Services

} Support de plusieurs technologies d’implémentation de registre
} UDDI
} ebXML (OASIS)
} Support de plusieurs opérations

} Connexion au registre
} Envoi de requêtes
} Gestion des données du registre
} Utilisation des taxonomies
Source : The Java EE 5 Tutorial

Et ça fonctionne pour de vrai ?

Problématique de l’interopérabilité
} Problème = variations dans les implémentations des standards
} WS-I (Web Service Interoperability)

} Consortium d’éditeurs de logiciels STANDARDS
SPECIFICATIONS BESOINS
} Objectif = assurer l’interopérabilité
entre les implémentations des normes
liées aux Web Services
GUIDE
BESOINS
Produit
D’IMPLEMENTATION
}
} Des profils = ensembles de standards
à implémenter + guides
} Des exemples d’applications
ENTREPRISES, DEVELOPPEURS, UTILISATEURS FINAUX
} Des outils de test
} WSIT (Web Services Interoperability Technologies)

} Implémentation Java open source de certaines spécifications WS-* sélectionnées
par WS-I et interopérables avec le WCF de .NET

Les Web Services RESTful

REST
(Representational State Transfert)
} REST = style d’architecture orienté ressources semblable à celui du web
} Ressource = information qui peut être identifiée de manière unique
et référencée par un lien
} Identifiant unique ➡ pour le web : URI
} Plusieurs rendus possibles ➡ pour le web : HTML, XML…
} Opérations CRUD sur les ressources = Create, Read, Update, Delete

} Pour le web, opérations HTTP
} Architecture REST pour les Web Services

} Reprendre la philosophie du web : ressources + liens
} Simplifier l’utilisation par rapport aux WS-* :
} Moins de standards à maîtriser et implémenter
} Messages moins verbeux
} Utilisation moins couteuse
} …

RESTful Web Services
} Web Service = ressource
} Identifiant = URI logique
} Obtenue par hiérarchie : http://supermarche.fr/produitsfrais/fruits/raisin
} Obtenue par construction : http://geographie.fr/altitude?lat=36&lon=10
} Opérations CRUD = opérations HTTP (requêtes/réponses)

} PUT = Create = création de la ressource
} GET = Read = lecture de la valeur de la ressource
} POST = Update = modification de la valeur de la ressource
} DELETE = Delete = destruction de la ressource
} Contraintes de conception :
} Opérations idempotentes
} Pas de session client-serveur (mais le serveur peut être stateful)

Exemple de requête
} Requête HTTP GET
http://open.mapquestapi.com/nominatim/v1/reverse?format=xml&lat=48.7099500104522
&lon=2.16758762635404
} Equivalent SOAP
<soap:Body>
<serv:reverse xmlns:serv="http://open.mapquestapi.com/nominatim/v1/">
<format>xml</format>
<lat>48.7099500104522</lat>
<lon>2.16758762635404</lon>
</serv:reverse >
</soap:Body>
</soap:Envelope>
} Les URLs peuvent être générées par des formulaires HTML !

Exemple de réponse
} Réponse HTTP standard
} Chaine de caractères représentant le résultat de l’opération
} Ou document XML représentant la ressource
<?xml version="1.0" encoding="UTF-8" ?>

…
<addressparts>
<bus_stop>Le Moulon</bus_stop>
<road>Rue Joliot-Curie</road>
<suburb>Montjay</suburb>
<city>Gif-sur-Yvette</city>
<administrative>Palaiseau</administrative>
<county>Essonne</county>
<state>Île-de-France</state>
<postcode>91400</postcode>
<country>France métropolitaine</country>
<country_code>fr</country_code>
</addressparts>
</reversegeocode>

Client d'un service REST

Client d'un service REST
Exemple avec Java
Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress("proxy.supelec.fr", 8080));
URL url = new URL("http://localhost:8080/HelloREST/resources/helloREST");
HttpURLConnection connexion = (HttpURLConnection) url.openConnection(proxy);
/*** Requête ***/
connexion.setRequestMethod("GET");
connexion.connect(); // send GET request
/*** Réponse ***/
System.out.println("HTTP code : " + connexion.getResponseCode());
System.out.println("HTTP message : " + connexion.getResponseMessage());
System.out.println("HTTP Content type : " + connexion.getContentType());
System.out.println("Content :");
InputStream stream = connexion.getInputStream();
BufferedReader r = new BufferedReader(new InputStreamReader(stream));
String line;
while((line = r.readLine()) != null){
System.out.println(line);
}
connexion.disconnect();
Service REST
Exemple avec Java
@Path("/helloREST")
public class HelloResource { Chemin d'accès de la ressource
private String name;
public HelloResource(){
this.name="Robert";
}
Mapping des opérations HTTP
@GET sur des méthodes de la classe
@Produces("text/plain")
public String getHello() {
return "Hello "+this.getName()+" !";
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}

Synthèse et conclusion

En résumé
} Web Service = déclinaison technique des concepts SOA au niveau du web
} Technologies WS-* = SOAP + WSDL + UDDI

} basées sur XML + HTTP
} + d’autres technologies WS-* pour les aspects transverses
} Technologies REST = HTTP + XML
} Applications =
} Intégration inter-applications point-à-point événementielle
} Flux A2A : intégration de développement spécifiques, de COTS, de progiciels, de legacy,
diversification des types de clients d'applications existantes…
} Flux B2B : exposition de fonctionnalités à des partenaires
} Intégration inter-applications type bus dans les solutions ESB

Rappel : ESB
ESB Cœur
Cœurdu
dusocle
socleSOA
SOA Browser
Corbeille de Formulaires
Moteur de tâches
règles Socle
SocleSOA
SOAétendu
étendu Utilisateur
Outils de
Modélisation de
Processus Serveur d’applications
Monitoring Moteur Moteur Moteur de workflow

(BAM) d’orchestration de règles Outils de
états Corbeille de Formulaires
KPI tâches développement de
formulaires
Processus
Processus(BPEL)
(BPEL)
Annuaire des ESB
services WSDL
WSDL
UDDI
Routage
Routageet
etTransformation
Transformationdes
desflux
flux
WSDL Connecteur Connecteur Connecteur
Connecteur Connecteur
Web service JCA ou JMS Web service Progiciel (ex: SAP) JDBC
Application nouvelle
Ecran
technologie (Ex :
Utilisateur J2EE / .NET / PHP) Web
WebService
Service
Web
WebService
Service
SOAP
SOAP Base de
HTTP
Service
ServiceIMS
HTTP IMS
Revamping données
Outils de IMS (ex: SCORT) Progiciel
Application nouvelle (ex: SAP)
développment
technologie (Ex : Application
intégrant les Web
62 Services
J2EE / .NET / PHP)Web Services
« legacy » 30 novembre 2012
Atouts & Challenges
} Interopérabilité } Point-à-point inhérent
} Environnement technologique } Normes, produits et technologies
hétérogène en évolution
} Systèmes existants, composants sur } Sécurité (authentification,
étagère (COTS)
autorisation, confidentialité)
} Diversité des clients
} Robustesse
} Services riches
} Passage à l’échelle
} Agrégation dynamique de contenu
} …
} Applications variées
} A2A, B2B, ESB…

Conclusion
} Les Web Services sont aujourd’hui incontournables dans le domaine
de l’intégration inter-applicative
} Ils ont révolutionné ce domaine par l’apport de standards
} Ils ont révolutionné ce domaine en l’ouvrant à internet
} Mais
} Malgré une « apparente » simplicité, les Web Services ne sont pas simples
} Beaucoup de standards différents et concurrents
} Beaucoup d’implémentations concurrentes
} Le traitement de certains aspects transverses n’est pas suffisamment mature
} Sécurité
} Fiabilité et cohérence
} Processus métier
} La communication point-à-point n’est pas suffisante
Nécessité d’outils autour des Web Services (développement, exécution…)

Annexes

Traitement du XML
} Manipulation de documents XML
} Analyse lexicale et syntaxique
} Vérification de la conformité du document avec la norme XML
} Validation par rapport à un schéma (DTD, XML Schema...)
} Éventuellement, modification du contenu
} Deux modèles de traitement <xyz>!

<azerty>!
} Modèle événementiel = vision « document balisé » blabla!
</azerty>!
} SAX (Simple API for XML), standard de fait </xyz>!
} http://www.saxproject.org/
} Modèle arborescent / objet = vision « arbre »
} DOM (Document Object Model), standard W3C
} http://www.w3.org/DOM/
} Des implémentations de SAX et DOM existent pour presque tous les langages
(Java, Javascript, C, C++, Perl, Python, langages .Net…)
Exemple avec Java : JAXP
(Java API for XML Processing)
} API de Java Standard Edition
} Objectif = traitement du XML
} Définit des APIs + des processeurs XML
} Support du modèle événementiel SAX
} Support du modèle arborescent DOM
} Support du modèle événement StAX (Streaming API for XML)
‣ ≈ SAX en mode « pull », streaming
} Support des transformations XSLT (eXtensible Stylesheet Language Transformation)

Rapports d’erreurs
} Problématiques de la gestion des erreurs
} Le client peut ne pas gérer les même exceptions ou pas de la même manière
} La trace de la pile d’exécution n’est pas transmise au client
} Solution = convertir les exceptions applicatives

en messages d’erreur spécifiques au service et significatifs pour le client
} Avec WSDL, élément « fault » permettant de décrire des rapports

d’erreurs

Rapports d’erreur : exemple
<definitions>
…
<message name="sayHello">
<part name="parameter" type="xsd:string" />
</message>
<message name="sayHelloResponse">
<part name="result" type="xsd:string" />
</message>
<message name="HelloException">
<part name="HelloException" element="tns:HelloException" />
</message>
<portType name="HelloService">
<input message="tns:sayHello" />
<output message="tns:sayHelloResponse" />
<fault name="HelloException" message="tns:HelloException"/>
</operation>
</portType>
…
</definitions>

Autres questions
} Granularité du service
} Compromis flexibilité / interaction (grain fin) vs. performance (gros grain)
} Imposée potentiellement par la logique métier
} Possibilité de mise en cache de données sur le client ? (impact)
} Type des paramètres et type de retour

} Compromis adaptation des types (types riches) vs. performance (types simples)
} Coût des transformations entre formats locaux et XML
} Non garantie de conservation de l’ordre des paramètres lors des transformations
} Pas de correspondance standard pour tous les types
} Attachements SOAP avec types MIMES
} Méthodes homonymes
} Génération automatique de noms possible mais peu « ergonomique »
} Désambiguïsation systématique et explicite des noms

Développement de la couche
traitement du XML
} Pré-traitement du XML entrant
} Validation par rapport au schéma
} Transformation vers un autre schéma si nécessaire
} Correspondance avec les objets
} Passage des appels au cœur de l’application (logique métier)

} Services synchrones : appel direct
} Services asynchrones :
} Message posté dans une file (JMS…)
} Réponse par récupération dans la file ou par callback

} Gestion de cache éventuelle
} Transformation des résultats de la couche métier (rendu)

2012 11 30 WebServices

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2012 11 30 WebServices

Transféré par

Droits d'auteur :

Formats disponibles

Web Services

Web Services D1.13E

Intégration et gestion des processus

Modélisation de processus D1.13E

Exécution de processus D1.13E

2 Web Services 30 novembre 2012

} Les grands principes des Web Services

à retenir avancé démo/exercice

3 Web Services 30 novembre 2012

4 Web Services 30 novembre 2012

} Format pivot = langage commun pour décrire et échanger des données

5 Web Services 30 novembre 2012

} Interface (contrat) = fichier XML

} Format pivot = langage XML + protocole internet

Web Services = ensemble de standards pour l’interopérabilité

6 Web Services 30 novembre 2012

7 Web Services 30 novembre 2012

Voici l’adresse du serveur

Quel format utiliser pour le service A ?

8 Web Services 30 novembre 2012

9 Web Services 30 novembre 2012

Interoperability Business Process Specifications Management Specifications Presentation

SOAP Message Transmission Optimization Mechanism

Universal Description, Discovery and Integration

Web Service Description Language 1.1

Metadata Specifications Reliability Security Specifications Transaction Resource

! Basic Profile – The Basic Profile 2.0 is an update of WS-I

! Simple SOAP Binding Profile – The Simple SOAP Binding

XML Process Definition Language

Messaging Specifications SOAP

over 600 organizations and individual members in 100 countries.

10 Web Services 30 novembre 2012

11 Web Services 30 novembre 2012

13 Web Services 30 novembre 2012

} Mode de communication = requête / réponse

15 Web Services 30 novembre 2012

} Utilisé pour les emails avec SMTP

} Utilisé pour le web avec HTTP

16 Web Services 30 novembre 2012

} Document XML = structure arborescente auto-descriptive

prenom nom date_naissance adresse poids taille

17 Web Services 30 novembre 2012

prenom nom date_naissance adresse poids taille unite

Gaston Lagaffe 180 cm

18 Web Services 30 novembre 2012

} Espace de noms = préfixe permettant d’éliminer les conflits lorsque

19 Web Services 30 novembre 2012

} Objectif = décrire l'interface publique d'un Web Service

} Interface d’un Web Service avec WSDL

} Fichier WSDL utilisable par des outils de génération de code

22 Web Services 30 novembre 2012

<message […]><part […]/></message>

24 Web Services 30 novembre 2012

<part name="parameters" element="sayHello" />

<xsd:element name="sayHello" >

} Attention aux espaces de noms !

25 Web Services 30 novembre 2012

26 Web Services 30 novembre 2012

} Définit principalement <Envelope>!

28 Web Services 30 novembre 2012

} Objectif = publication et découverte de Web Services sur un réseau

Pages blanches Pages jaunes Pages vertes

31 Web Services 30 novembre 2012