Web Services Part 5 – SOAP, UDDI, WSDL
Publish, Discover, Subscribe and Invoking of SOAP Services
We have discussed about WSDL document and the structure in previous section Web Services – SOAP part 4.
Below figure depicts a WSDL document to a sample Web Service called : foobarService.
Lets discuss about UDDI , mapping between WSDL and UDDI and how client’s can discover and get the details about a Web Service using UDDI.
Universal Description, Discovery and Integration (UDDI)
UDDI Specification defines the format and the way to publish the Web Service and Discovery of a Web Service over the Web Service Directory. UDDI also follows the soap based protocol to communicate with UDDI Supported Web Service Directory services.
UDDI comes up with an XML schema document for SOAP message format that defines a set of documents to :
a) describe the nature of business and service information
b) An API for querying and publishing WSDL documents to the Web Service Directory services and also a supporting API for
replicating or mirroring the Web Service Directory entries between the peer UDDI supported nodes.
UDDI Registries :
UDDI registries are the repository of information of Web Services and their meta data. UDDI manages the discovery through a common XML document format by relying on a distributed registry of Businesses and the Service Descriptions.
In order to publish our web services and our business model data and entity to a registry, we must first register our business entity with UDDI registry so that subscribers can search and discover our web services.
UDDI registries can be private and Public.
Private registries commonly are setup and secured in a private internal on-premise environment/cloud where as a public registry is a collection of peer directory nodes that are available for public for discovery and subscription.
But one point to be noted is both private and public UDDI registries comply to the same UDDI specifications.
How does a UDDI specification deal with WSDL documents ?
UDDI has two basic functions :
- It is a SOAP based protocol that defines how UDDI clients communicate with registries
- it’s a specific set of globally replicated registries.
Web Service Providers in order to register a service, they need to rely on 4 basic data structure types.
businessEntity data type holds the information about the business that owns the published Web Service.
businessService data type that holds the description of a web service.
bindingTemplate datatype that contains technical information pertinent to the entry point and construction specification of invoking a web service.
tModel data type that provides the reference model that assists in discovering the web Services and acts as a technical specification for a web service. for more details on UDDI data structures : refer site UDDI
Below figure illustrates the Relationship between UDDI v2 and WSDL document : ( image owner: oasis-open.org)
a) The WSDL Service element references the WSDL binding element. The document URL that contains the WSDL binding element is published to the UDDI registry as tModel type.
b) The URL of the document containing the WSDL service element is published to the UDDI registry as a business registry as a business service and holds information about the bindingTemplate.
More information for UDDI registry datastructures refer the following page : Using WSDL in a UDDI Registry, Version 2.0.2.
Web Service – Publish, Discovery, Subscribe and Invoke
Below Figure illustrates the basic flow between Service Consumer and Service Provider.
Below are the generic Steps involved in Publish, Discover , subscribe and Consume a Web Service :
1.Service Provider implements and hosts a Web Service. Now if it wants to expose the web service to the internet world, for that, it needs to register itself and also must publish the details of Web Service, its interface, transmission protocol and other meta data in a WSDL document to public UDDI supported web services directory through the UDDI protocol ( as discussed in previous section).
2.once the Service provider successful in registration and publishing its web service details to the Web Service Directory/repository,
3.Service consumers looking for a particular services, perform a query search using the criteria across the Web Service directory as per their interests through UDDI search functionality support.
4.Service consumer if he finds a web service ( free or paid service packages) he is interested in , will subscribe to that particular service he is interested in by finishing the formalities with Service provider( if paid service).
5.next step is to retrieve the WSDL document of that Web Service for information related to interface, inputs and output formats etc.
6.Service consumer then frames the Web Service request ( as per WSDL specification of that Web Services) and invokes the web service.
7.Consumer service should also be aware of consuming the response of web service and able to properly interpret the response and could process it.
In this article, we have discussed on SOAP, WSDL , UDDI and the basic flow involving all these specifications.
Next article discusses about Web Service Security which is very crucial to secure our data and resources.