Business Service Registries
Unlike looking for a single service on UDDI, a Business Service Registry (BSR) would allow businesses to dynamically and automatically develop a sequence of services that accomplish a business task.
There is a a clear need and business model for a BSR. It would be based upon a combination of "Yellow Pages" and the Underwriters Laboratory ®. Like the former, companies pay to list their services in the registry. Like the latter, the owner of the BSR vouches for the quality of the registered services. The fundamental business model is one of advertisement but with various degrees of added value for different BSRs. Each BSR will establish a different reputation for completeness and trust. In addition, BSRs may offer additional services. For instance, instance, a trusted BSR may serve as a third-party broker between an enterprise and previously unused suppliers. The broker guarantees that the supplier will perform and that the buyer will pay, as well as any other terms and conditions required for the transaction.
But BSRs can offer differentiating services just at the level of service discovery and consumption: instead of just offering a taxonomy of services, such as UDDI currently does, a more sophisticated BSR will accept criteria for finding a service. An even more sophisticated BSR will accept a complex request and return a sequence of web services that accomplishes the request. DERI Stanford will provide the technology that will allow such BSR functions.
The Problem: Existing WSDL and UDDI technologies are inadequate to allow business to expose real business services[Petrie-Bussler].
In conjunction with CommerceNet, the Stanford CIT organized two workshops1 in June 2003 focused on the barriers to the adoption of a SOA and the requirements for a Business Service Registry (BSR), as a fundamental building block for a SOA. The two outcomes of these workshops were 1) a gap analysis of what extensions were required to WSDL and UDDI in order to provide a infrastructure adequate to support the discovery, use, and composition of business services2, including a mockup of an improved UDDI interface3 ; and 2) an identification of the barriers to adoption of an SOA and how a BSR would address these problems4.
The fundamental problems include a lack of a standard way to describe services so that both the consumer and provider understand the pre-conditions for using the service, what effects the service will have, as well as standard descriptions so that the consumer can determine payment methods, document formats, expected performance, level of trust, and security. The provider likewise needs standard methods for authentication, authorization, and auditing. All of these may in fact be fundamental infrastructure services offered by competing vendors and consumed by higher-level services. All of these services in turn must be informed by common semantics for descriptive terms. We note here that authentication is a crucial fundamental policy. There has to be a global non-vendor-specific method of providing and proving identity in order for any business to take place.
Finally, a BSR will not be a simple mechanism of replicated data but a federated systems supported by competing vendors with interoperable standards supporting the distributed service descriptions located at service provider sites, much as today's search engines provide various levels of completeness, accuracy, and trust in search the distributed search of the unstructured data on today's web.
The complete description of the results of the first two workshops is outside the scope of this documen. DERI Stanford will refine and further these architectural issues. Further, there are important difficulties with the dynamic integration and composition of business services if one tries to use today's web service technologies. DERI Stanford's mission is to address all of these problems. However, one can see that there are a fundamental problems simply by noting that despite the huge opportunities an Internet-wide SOA would offer, there is not today a single business service offered on a public UDDI node today. None of these web services produce revenue for a provider or cause the provider to change the world in any way. No revenue is generated by use of a service. No rental cars are reserved, no flights are booked, no food is delivered, and no packages are shipped.
Supporting Materials
1Agendas: Workshop I, Workshop II
[Petrie-Bussler]
C. Petrie and C. Bussler,
"Service Agents and Virtual Enterprises,"
Internet Computing, 7(4) July/August 2003, pp. 2-12.