An IDL for Web Services ● Interface definitions are needed to allow clients to communicate with web services ● Interface definitions need to be provided as part of a more general web service description
Web Service Descriptions ● Service descriptions specify (1) how the messages are to be communicated and (2) the URI of the service ● Service descriptions are written in XML (so are accessible from any programming technology) ● The description forms the basis of an agreement between a client and a server ● The IDL is generally used to generate client stubs which automatically implement the correct behaviour for the client
WSDL ● Web Services Description Language (WSDL) is commonly used for service descriptions ● WSDL 2.0 is a working draft of the W3C ● It defines an XML schema for representing the components of a service description ● Included are standards for element name definitions, types, messages, interfaces, bindings and services
WSDL Requests and Replies message name = " ShapeList_newShape message name = " ShapeList_newShapeResponse " " part name part name= " result " ="GraphicalObject_1" type = " ns:GraphicalObject type = " xsd:int " " tns ミ target namespace xsd ミ XML schema definitions
More on WSDL ● The abstract part of the description includes a set of definitions of the types used by the service, in particular the types of the values exchanged in messages ● The concrete part specifies how and where the service may be contacted ● The inherent modularity of a WSDL definition allows its components to be combined in different ways - the same interface may be used with different bindings or locations
Web Service Clients and Servers ● All that the client and the server need is to have a common idea about the messages to be exchanged ● When a clients sends messages to a web service, the latter decides what operation to perform and what type of message to send back to the client, on the basis of the type of the message it received
WSDL Interfaces ● The collection of operations belonging to a web service are grouped together in an XML element named "interface" ● Each operation must specify the message exchange pattern between the client and server
Message Exchange Patterns Name Messages sent by Client Server Delivery Fault message Request Reply may replace Reply In-Out Request no fault message In-Only Request guaranteed may be sent Robust In-Only Reply Request may replace Reply Out-In Request no fault message Out-Only guaranteed may send fault Request Robust Out-Only
WSDL Inheritance ● Any WSDL interface may extend one or more other WSDL interfaces ● This is a simple form of inheritance ● However, recursive definitions of interfaces is NOT allowed
WSDL Concrete Part ● The concrete part of a WSDL document consists of the binding and the service , that is, the choice of protocols and the choice of endpoint or server address ● When you see “binding” think protocol ● When you see “service” think end-point or address
Binding and Services ● The binding section in a WSDL document says which message formats and form of external data representation are to be used ● Web services frequently use SOAP, HTTP and MIME ● Each service element in a WSDL document specifies the name of the server and one or more endpoints (or ports) where an instance of the service may be contacted
WSDL Use ● Complete WSDL documents can be accessed via their URLs by clients and servers, either directly or indirectly via a directory service ● Tools are available for generating WSDL definitions from information provided via a graphical user interface, removing the need for users to be involved in the complex details and structure of WSDL ● WSDL definitions can also be generated from interface definitions written in other languages
Web Service Directory Services ● The Universal Directory and Discovery Service (UDDI) provides both a name service and a directory service ● WSDL service descriptions may be looked up by name (white pages) or by attribute (yellow pages) ● They may also be accessed directly via their URLs, which is convenient for developers who are designing client programs that use the service
UDDI Lookup ● UDDI provides an API for looking up services based on two sets of query operations ● The get_xxx set of operations - retrieves an entity based on a key value ● The find_xxx set of operations - retrieves a set of entities that match a set of search criteria ● UDDI also provides a notify/subscribe interface by which clients register interest in a particular set of entities in a UDDI registry and get change notification messages (synchronously or asynchronously) sent to them
Coordination of Web Services ● Many useful web services applications involve several requests that need to be done in a particular order ● There's also a need for client web services to be provided with a description of a particular protocol to follow when interacting with other web services
The Travel Agent Service flight booking a flight booking b Travel Agent Client Service hire car booking a hire car booking b hotel booking hotel booking a b
The Travel Agent Scenario 1. The client asks the travel agent service for information about a set of services; for example, flights, car hire and hotel bookings. 2. The travel agent service collects prices and availability information and sends it to the client, which chooses one of the following on behalf of the user: (a) refine the query, possibly involving more providers to get more information, then repeat step 2; (b) make reservations; (c) quit. 3. The client requests a reservation and the travel agent service checks availability. 4. Either all are available; or for services that are not available; either alternatives are offered to the client who goes back to step 3; or the client goes back to step 1. 5. Take deposit. 6. Give the client a reservation number as a confirmation. 7. During the period until the final payment, the client may modify or cancel reservations
Achieving Coordination ● Distributed transaction technologies play a big part here! ● The W3C (and others) are working towards the definition of higher-level services ● Notable work in this area includes WS-Coordination
Web Service Choreography ● W3C use the term "choreography" to refer to a language based on WSDL for defining coordination ● Intended to support interactions between web services which are generally managed by different companies and organizations ● Described in terms of the sets of observable interactions between pairs of web services, which forms the basis of the contract between the participants ● The use of a common choreography description by a set of collaborating web services should result in more robust services with better interoperability ● The W3C have released early draft standards that describe CDL - the Choreography Definition Language
Securing Web Services ● As web services are based (almost exclusively) on XML, security comes down to protecting the text-based XML communications ● Obviously, documents shared over the Internet also need to be authenticated ● The W3C have developed XML security technologies that support signing, key management and encryption ● Another approach is WS-Security , which concerns itself with applying message integrity, message confidentiality and single message authentication to SOAP ● XML security depends on new tags that can be used to indicate the beginning and end of sections of encrypted or signed data and of signatures
XML Security Requirements ● To be able to encrypt either an entire document or just some selected parts of it ● To be able to sign either an entire document of just some selected parts of it ● To add to a document that is already signed and to sign the result ● To add to a document that already contains encrypted sections and to encrypt part of the new version, possibly including some of the already encrypted sections ● To authorize various users to view different parts of a document
Requirements: Algorithms and Keys ● The standard should specify a suite of algorithms to be provided to an implementation of XML security ● The algorithms used for encryption and authentication of a particular document must be selected from that suite and the name of the algorithms must be referenced with the XML document itself ● Appropriate keys must be chosen, without any negotiation with those parties that may access the document in the future ● Requirement - to help the users of secure documents with finding the necessary keys, to make it possible for cooperating users to help one another with keys
Canonical XML ● Designed for use with digital signatures , which are used to guarantee that the information content of a document has not been changed ● XML elements are canonicalized before being signed and the name of the canonicalization algorithm is stored with the signature ● This (obviously) enables the same algorithm to be used when the signature is validated upon receipt
Recommend
More recommend