Web Services - Protocols.
Communications between the web service components is based on messaging. XML formatted messages are exchanged between components. Typically, delivery is by HTTP but other protocols may be used. SOAP allows methods to be invoked remotely. UDDI includes the procedures for updating and searching service registries. WSDL is a language for describing client/server interfaces. Communications between client and server is application dependent but based on SOAP.
The Hypertext Transfer Protocol (HTTP) is the protocol used by web browsers to access pages on the worldwide web. HTTP is also used to transfer messages between clients and servers in web service environments.
HTTP is a client/server protocol. Web services are based on the client/server model. Web services make use of the following HTTP messages:
- HTTP GET messages to download files from servers.
- HTTP POST messages are used by the client to cause particular application code to be executed on the server.
Web service clients operate as clients to the registry servers as well as to the web services. Clients request services using HTTP POST messages; they download service descriptions in WSDL files using HTTP GET messages.
HTTP is a good choice as a transport mechanism for web service data. The protocol is widely understood, widely available and stable. HTTP messages are permitted by most firewalls so there should be few set-up problems.
The web service standards allow other transport mechanism to be used. File transfer and email mechanisms such as FTP and SMTP could be used. There are questions over the efficiency of HTTP. To address these concerns a new protocol, the Blocks Extensible Exchange Protocol (BEEP) is being developed.
The basis of web services is messaging. Clients send messages to servers, the servers respond with messages. Web service messages are encoded using the Extensible Markup Language (XML). The content of XML messages is independent of the participating hardware, operating systems and protocols.
XML defines syntax for marking up data in a human readable form. The language is extensible, XML based languages can be defined for particular application areas. The extensibility of XML is made use of by the higher web-services protocols.
The Simple Object Access Protocol (SOAP) is a protocol for Remote Procedure Calls (RPCs). As it is an extension of XML it is independent of the operating system, programming language and protocols used.
A client invokes a procedure (or method) on a remote server by transmitting a SOAP message to the server. The message identifies the remote method and carries the method arguments as objects. When HTTP is used as the underlying transport, the HTTP POST message is sent by the client to initiate the processing of the SOAP messages.
The server performs the invoked procedure and returns the results as objects in another SOAP message.
An example SOAP message follows.
<?xml version="1.0" encoding="UTF-8" ?> <envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <body> <get_tModelDetail xmlns="urn:uddi-org:api" generic="1.0"> <tModelKey> uuid:0e727db0-3e14-11d5-98bf-002035229c64 </tModelKey> </get_tModelDetail> </Body> </Envelope>
This message requests execution of the get_tModelDetail method with a tModelKey parameter.
The Universal Description, Discovery and Integration (UDDI) service is the specification to which web service registries conform. UDDI consists of a data model and an application program interface (API).
The UDDI data model describes four core object types.
The businessEntity objects describe individual businesses that provide web services. These objects carry information such as the business address and contact information.
The businessService objects describe available web services. Information carried in these objects includes a service name and description as well as bindingTemplate objects.
The bindingTemplate objects describe where a particular object is located and how it should be accessed. This includes the access point of the service and details of the protocol to use (e.g. FTP or HTTP).
The tModel describes the technical model of the interface. This describes the interface. The tModel includes pointers to the WSDL files that describe the interface.
The UDDI API is an extension of SOAP, it provides an RPC interface to the registry database. The methods provided by the UDDI API allow registry data to be published or searched.
The publishing interface to UDDI is used by service provider to advertise the availability of their services. The API includes save_binding, save_business, save_service, save_tModel, delete_binding, delete_business and delete_tModel methods for creating the UDDI objects. It also includes getAuthToken and discard_authToken methods, these ensure that the UDDI data is only modified by those users who are authorised to do so.
The search interface to UDDI is used by potential clients looking for service details. The API includes find_binding, find_business, find_service and find_tModel methods to find UDDI objects matching particular criteria. It also includes getBindingDetail, getBusinessDetail, getServiceDetail and get_tModelDetail to obtain details of particular UDDI objects.
The Web Service Definition Language (WSDL) is an XML extension. It is used to describe the client/server interface that should between web service clients and servers. WSDL is capable of describing:
- All publicly available methods provided by the service.
- Data types used in method calls and responses.
- Information about how to use the underlying transport mechanism (HTTP, FTP etc).
- The address of the server.
The WSDL file describing a service is stored on a server, perhaps on the registry or the application server. It will be read by the client using a simple HTTP GET exchange.
Some web service application will be made available to a closed set of users, those who have paid for the service, those who work for particular organisations or those who are known to provide reliable information. The web service standards include the Security Assertion Markup Language (SAML). SAML is a SOAP extension used to provide security functions to web services.
The core idea of SAML is the assertion, a fact about something. For example, there may be an assertion that a particular user has been authenticated. A client uses SAML to request an authentication assertion from a security service. The assertion is then used in subsequent requests to other services.
The interface provided by the server and used by the client is devised by the designers of the service and described in the WSDL file. The client invokes methods on the server, providing any necessary parameters. The server returns objects in the reply. The protocol is based on SOAP.