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 "contain" 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 unstructured information.

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:
  • 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.
  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 useful service.
• 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 Level: including what quality of service will be provided (including availability 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

1. 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.
2. 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.
3. 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.
4. 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.
5. . 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.