Common Service Descriptions could be a key to Governance

When reviewing 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. We need a common standard.

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 architects.

Purpose means that we have a common notion of the purpose of the service, such as a service that 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.

However, I suspect it will still be the Wild West out there for awhile as SOAs moves out of the playground and into business critical production systems, which seems to be occuring now. Thus, we better have some sense of how to define, share, and leverage service descriptions in a common way, or it will be a very confusing world.

Posted by Dave Linthicum on January 4, 2007 05:52 AM