Oracle SOA Suite Online Training

Interested in learning Oracle SOA Suite 12c?
Learn from the author of this blog!
A complete and comprehensive course on the #1 platform on SOA - Oracle SOA Suite

Click here to find the complete course details
Click here to check the first session on Oracle SOA Suite 12c


Service Registries : WSIL & UDDI

Often there is a confusion on what is WSIL and what is UDDI, what is the difference between them, as on a high level, both seem to be the same.

Both Web Services Inspection Language(WSIL) and Universal Description, Discovery, and Integration(UDDI) specifications address the same task of Web service discovery. And both contain only references to WSDL's, but do not contain documents themselves.

If both serve the same purpose, why two different specifications..?

The UDDI specification addresses Web service discovery through the use of a centralized model.
UDDI compliant registries serve as central hubs where service providers and service requestors come together and satisfy their needs.
There are, however, few flaws in the UDDI business model that prevents it from taking off (at least today) the way it was intended:
  1. Not all records in the UDDI registries are really existing. There are instances where a service is registered in the UDDI, but the actual implementation do not. Infact, in an  independent research carried out by SalCentral, it is found that 2/3rd's of the service entries in the UDDI's are actually not existing. Also, there are situations where the entries are duplicated with different names. There is no proper moderation to these registries.
  2. No Quality of Service(QOS) is guaranteed to the services registered. How can you trust a service registered in the UDDI by some service provider, and use it by giving your data? Though some implementations provide digital signatures for this, this is not in the standard spec for UDDI.
  3. Also, UDDI requires the deployment and maintenance of a some infrastructure, thus increasing the cost of operation.

This is where WSIL just fits in.
WSIL decentralizes the centralized model of service publication within a UDDI registry and distributes them such that each service provider itself can advertise its Web Services offerings. The service descriptions can be stored at any location, and requests to retrieve the information are generally made directly to the entities that are offering the services.

The primary difference between both is that the Web Service "find" no longer goes directly to a centralized UDDI registry. Instead, the "find" is sent directly to the service providers from the requestors. If the service provider is maintaining the service advertising, he would always have the latest and greatest, non-duplicated, trusted(based on the service provider) service offerings. Thus the centralized, un-moderated registry is now a decentralized, moderated registry distrsibuted over the web.

WSIL defines an XML based language by which services can be advertised to interested consumers.

Which is better?
It completely depends on the situation.
UDDI is more advanced to WSIL in terms of the capabilities it provides. If your use case doesn't require advanced functionality offered by UDDI(some impl. like OSR provide approval mechanisms for publishing, digital signatures, etc.), WSIL is the option.
If the use case is that the data needs to be centrally managed, UDDI is the option.
Note that each of these technologies are complimentary to each other.

inspection.wsil document
All the services are advertised through WSIL using a fixed document called inspection.wsil
Once an inspection document has been created, a consumer needs to be able to find it. Consumers would only need to ping a URL such as http://<host>:<port>/inspection.wsil to discover the file's existence for retrieval.

Creating a WSIL Connection in Jdeveloper
Jdeveloper has an inbuilt WSIL wizard, which lets you create a WSIL connection very easily.
Go to Resource Pallette --> New Connection --> WSIL

Give the inspection.wsil location(normally in the root of the managed server), managed server's credentials

That’s it!!!
Now, You may refer to all the webservices deployed to this host through this connection.

Thanks for going through my post, feel free to provide a feedback!

No comments:

Post a Comment