When Building Your SOA…Service Descriptions are Key
With the advent of Web services, most enterprises that I deal with now have thousands sometimes tens of thousands of services under management. To make matters even more complex, we also have to consider services that are out of our direct control, those found on the open Internet (public services). Clearly, you can count on the number of these services increasing over time, perhaps very quickly over the next few years.
While we do have some interface information about these services, as defined by standards such as WSDL and UDDI, we really need a more complete set of info surrounding the services in order to create a proper SOA.This information should include things such as; the purpose, interfaces, parameters, rules, logic, owner, semantics, included services, and other important data. Let’s call this what it is, a service descriptions.
I believe that before understanding the need for service descriptions, we need to first better understand what’s information is already available within existing standards such as WSDL and UDDI.
WSDL is really a collection of low-level metadata about XML-based services used for describing what businesses do and how to access their services electronically. Based on SOAP, WSDL specifies the procedures to discover functional and technical information about Web services over the Internet. It does not exist to describe everything about a service, however. Only the basic low-level information needed to invoke the service from a calling process.
A WSDL document is comprised of a number of elements:
-
Type definitions, for data elements (normally using XML Schema).
-
Message definitions, which comprise one or more typed data elements.
-
Operation definitions, which are abstract descriptions of actions supported by the service, and which defines the input and output messages.
-
Port type definitions, which list the set of operations supported by the Web service.
-
Binding definitions, which describe the binding between the port types and protocols (e.g., SOAP or HTTP GET/POST).
-
Service definitions, which list the set of bindings.
The UDDI Business Registry is a standard for cataloging and publishing WSDL descriptions of Web services that are available over the Internet. In much the same way as people peruse common Yellow Pages for a particular service, commerce systems can search the UDDI registry and find Web services, download the parameters for interaction, and effectively interact with the discovered Web service (using SOAP).
What’s Missing
As you can see from the short descriptions of both WSDL and UDDI, the information you’re able to obtain about services are very low level indeed, allowing you to both discover and bind to a service…let’s face it, that is what they were designed to do. However, neither WSDL nor UDDI provides the “meta” information that will prove useful as we leverage both private and public services.
There are a few more dimensions we need to address including: semantics, purpose, authentication, dependencies, and service levels. These by the way, are only basic suggestions, other dimensions and even sub-dimensions are all allowable.
Semantics, is a no brainer and it’s been known for awhile that semantics are a weak point of Web services. Today we are attempting to solve this problem with new standards such as The Semantic Web, or more often through proprietary mechanisms, so I really don’t need to sell this dimension. This is a pain point for most service-oriented integration architects.
Purpose means that we have a common notion of the purpose of the service, such as a service that’s written to update cash in an accounting system, or a service that controls a large inventory system. Here we should document the uses of the service, examples, and any calling information needed.
Authentication would provide the security element to a service, including who’s authorized to use it, identity management issues, and any special security issues such as the use of encryption.
Dependencies would define any other services encapsulated inside of a service where the calling service is dependent upon. For instance, an inventory control service may leverage a public service to determine the date and time, that needs to be documented as a dependency for obvious reasons (e.g., that service dies so does your service).
Finally, we need to define service levels.In other words, the service levels you can expect from a particular service including standard outages and accessibility issues, such as limited bandwidth. This will allow those creating a composite application around a group of services to determine the service levels of the composite application, which is only as good as the services that make up the composite application.
Clearly we need to go a few more levels of detail down to better define the notion of service description as well as the properties we need to track within each service. Perhaps we can meld this into an existing standard, much in the same way metadata is moving towards a standard (finally).However, I suspect it will still be the Wild West out there for awhile as SOA and service-oriented integration moves out of the playground and into business critical production systems.When that occurs we better have some sense of how to define, share, and leverage service description or it will be a very confusing world.
Trackback URL for this post: http://www.webservices.org/trackback/id/5755