<<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. However, 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.>> You can read this at: http://weblog.infoworld.com/realworldsoa/archives/2008/01/some_thoughts_o.html?source=NLC-SOA&cgd=2008-01-22 Gervas
