In the first workshop, we collectively looked at what a BSR should
be over and above the existing UDDI, and how these requirements
apply to the "top 10 Points of Pain (PoP)" in moving to a
Services-Oriented Architecture (SOA).
Some of the requirements are obvious and general: it should be
easy to register and publish a service. There should be a global
authentication method. One we have suggested is that the individual
registering should give a domain name owned by the company the
individual is representing: a challenge/response email is then
sent to "postmaster" at that domain address in order
to verify that this individual represents the company.
At a high-level, it should be noted that a BSR should be a
federation of BSRs, differing by industry, and perhaps competing for
quality of information and trust.
In deciding what information a BSR should carry, over and above
that of UDDI, it is important to note that the service itself may
contain additional information that addresses SOA PoP. In the list
below, we try to address what information a BSR should
in order to facilitate search for a desired service. Contain
may mean that the BSR provides a distributed search function,
finding the information maintained by the service provider at
the provider site, rather as search engines now search for
Finally, it may be obvious, but the point of this information is
that it be standardized. Every service today could specify all of
this information. But if the registry doesn't facilitate distributed
search, then it is simply not useful. Standardization is necessary
for such functionality, as well as any level of search automation.
Summary of BSR Service Description Information Requirements
- There should be, at a minimum, a set of industrial
taxonomies that provide common semantics for simple
common terms such as "city", as well as sets of terms specialized
for various industries, such as "Airline ID" or "Interest Rate".
- There need to be specified preconditions for the use
of services, so that the service requester knows whether they
are eligible/authorized to use the services, or what actions
they should take in order to do so. Preconditions might include
the hours the service is available, the age of the user, or
even requirements that the service not be used in conjunction
with services from certain other providers. .
- Possibly the single most important part of a service description
for search is a description of the effects of a service.
One does not want to just look for companies that have registered
themselves as travel agencies: one wants to look for services that
book flights. Having a taxonomy of common terms is necessary in
order to represent this information, but we need further a description
of actions, such as "ship" and place and time constants,
such as "today".
- At least as optional information, it may be desirable also
for a search in a BSR to select only those services that are
advertised to work with a particular orchestration method, such as
Rosettanet or BPEL4WS, for example. However, the listing of
preconditions and effects should mitigate the requirement for
such explicit orchestrations.
- Under the single label of authentication, we have actually
three qualities (AAA) determined to be important:
In the BSR, the potential requester must be able to determine the
authentication method used, what level of service can be obtained, and
the auditing method, in order to determine that this is indeed a
- Authenticating the service requester
- Authorizing which service operations at what levels
can be provided to the requester, and
- Auditing the use of the service by the requester for
various purposes, including billing and payment.
- This in turn brings up the fact that the searcher should be able
to determine the method of payment for the service.
- A BSR should allow a service search to determine the Service
including what quality of service will be provided (including
of the service) and what, if any agreement is provided, perhaps
by a third-party.
- This brings up the general subject of trust: there must be
some way for a service search to filter out services below a certain
level of trust-worthiness, perhaps determined by personal preferences
on the certifying authorities. Trustworthiness ratings can indeed be
another service provided by many competing providers. A BSR has to
facilitate use of this information in a search. And finally, good
BSRs should certify the services listed to some degree.
- In addition to trustworthiness, general ratings of service
quality, utility, availability, timeliness, etc. will be provided
by disparate raters, each judged on a level of trustworthiness, and
the BSR should facilitate searches based on ratings. In conjunction
with ratings, it may be desirable to consider the recommendations
and references offered by each individual service.
- A BSR should allow one search parameter to be the level of
testing of a service and whether it can be used in a debugging
mode prior to actual use.
Applicability to SOA PoP
- The top SOA PoP is the lack of a Service Level Agreement (SLA) and
indeed this should be a part of service descriptions in a new
Business Service Description Language (BSDL), and is addressed
by the BSR information requirements above.
- The second SOA PoP was lack of Trust Services. A BSR cannot
establish these directly but the availability of search based on
trust ratings is likely to facilitate the establishment of such
services. In addition, the structure of federated BSRs, competing
for trust and certification of services will greatly aid in
establishing trust in services. BSR nodes should certify the
services they offer.
- The third SOA PoP was the lack of mediation within
the commercial model of services requiring contracts with
terms and conditions. BSR can address this partly by
providing AAA information, based on existing contracts, perhaps
with 3rd party intermediaries, especially wrt authorization
by roles. Specifying effects, preconditions, and payment methods
also provides some contractual terms and conditions information.
Again, it should be noted that the BSR should facilitate search
of this information that may be largely provided and maintained
by the provider.
- The lack of adequate Business Process Orchestration
and Choreography definitions is addressed most directly by
the requirement to specify preconditions and effects of
a BS. If one knows this information, then one can determine,
even dynamically, what other services are compatible with
this one, and in what sequence. One does not need pre-specified
graphs of allowable sequences. However, a BSR should also
allow the the specification of orchestration standards
supported or not by the service.
- . A major PoP for SOA is the lack of capability of
testing services and their integration. This means that
real BSs should provide test information, including
parameters stored for testing, a URL for certification
and debugging, and a debug mode for the service. Whether
such information is available and to what degree should
be searchable using a BSR.
- The lack of standard I/O is almost a "hard stop"
for SOA. Intel is pushing forms as a way to standardize
documents. To some extent, this just pushes the problem back
as one must then determine what is the meaning of the label
on the blank to be filled in. However, even the input
and output messages of WSDL can be considered as "virtual
forms". What is missing is the use of existing
XML schema mechanisms to specify the part names of these
messages, as well as the taxonomies discussed in the
BSR Requirements. If we can get all of the information
specified to be standardized using common taxonomies
and XML schema, then we have most of what is needed. In
addition, one can also use these mechanisms to specify
any document formats and schemes to be exchanged. But
of course, we must standardize these taxonomies and
use of XML schema.
- The lack of AAA stops SOA. As discussed above,
this is crucial to the actual deployment of BSs.
Without AAA, no one would ever deploy services that
actually did anything. We must have service descriptions
that include some level of authentication, and make
this searchable in a BSR.
- Concerns about the performance and scalability of web services
is a major SOA concern. To a large extent, this is simply
not applicable to BSR requirements. However, to the
extent that performance testing and availability information
is subject to BSR search, this concern is addressed by a BSR.
- Lack of standardization of documents is a concern
especially for the Supplier Adoption Forum. However, this
is largely the same issue as the lack of I/O for
business documents, addressed above.
- No standard way to Provision and Consume services is
at the heart of BSR functionality. A BSR needs to facilitate
service registration, and automate service provisioning as
much as possible. The information described above in BSR
requirements goes a very long way in addressing this SOA PoP.
Globalization of sevices was another frequently mentioned
barrier that will need to be addressed by a BSDL and also
then by a BSR. However, it was agreed that the items above
need to be addressed first, as long as a globilization solution
was not precluded by the representations chosen.
We recognize that the BSR (and SOA) requirements above are
ambitious, but they are feasible, and represent the practical
concerns of large enterprises who are moving towards an SOA.
This requirements are general ones and subsequent work will
reveal the right way to proceed in engineering them into
a federated system of BSRs, supporting grid services for
Business Service Networks.