Liang-Jie Zhang

Subscribe to Liang-Jie Zhang: eMailAlertsEmail Alerts
Get Liang-Jie Zhang: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Next-Generation Web Services Discovery

Next-Generation Web Services Discovery

Exploring a business application published as a Web service in the UDDI registry or Web Services-Inspection (WS-Inspection) documents is a critical issue. A search for such an application should be effective in terms of time and uniform in terms of interfaces. This article will examine the existing Web services publishing and corresponding discovery technologies, including potential problems and a novel technology for advanced Web services discovery.

Web Services Publishing
The emergence of Web services represents the evolution of e-business. Web services are reusable Web components with standard interfaces described in WSDLs. They can be accessed by universal clients such as wireless devices, Web clients, and other application clients. As an enabling technology, they've been adopted to represent services and communicate with other services in a standard way.

In general, Web services can be published to a public or private UDDI registry or Web Services Inspection Language (WSIL) documents, illustrated in Figure 1. The design of UDDI allows simplified searching and allows trading partners to publish data about themselves and their advertised Web services for categorization. A UDDI registry is a central place to store the information and pointers about a Web service. There are two types of UDDI registries: private and public. As an application developer, you can publish your Web services to the existing public UDDI registries operated by IBM, Microsoft, HP, and SAP. If you want to publish your private or confidential Web services, however, you should use a private UDDI registry. For testing or small-scale integration purposes you can publish your Web services to WS-Inspection documents, which enable Web services discovery, deployment, and invocation without the need for a UDDI registry. WS-Inspection documents provide a means for aggregating references to preexisting service description documents authored in any number of formats. These inspection documents are then made available at the point-of-offering for the service as well as through references that may be placed within a content medium such as HTML. For example, there is a URL for developers to locate the WS-Inspection documents on a Web site (e.g., wsil).


The UDDI registries and the WS-Inspection documents are tightly associated by WS-Inspection data tag "wsiluddi." Thus, in a WS-Inspection document, you can use a reference pointer to connect to a business or service published in a UDDI registry.

Simple UDDI Search and WS-Inspection Screening
Many developers believe Web services will open up a world of interlocking business services that find each other over the Internet, thus integrating disparate code into useful programs. If this vision is to be realized, users must be able to find services on the vast public network.

There are currently solutions for finding Web services from centralized UDDI registries or distributed WS-Inspection documents published on regular Web servers. As shown in Figure 2, a WSIL document can have a link to point to another WSIL document, and a UDDI registry can be private or public. Think of WS-Inspection as a cheap solution for organizations with existing relationships to discover each others' Web services. UDDI, on the other hand, is more like a traditional Yellow Pages directory that organizations can use to get a series of listings for Web services under different categories. UDDI is the building block that will enable businesses to quickly, easily, and dynamically find and transact with one another via their preferred applications.

As for simple WS-Inspection crawling, a search tool can be easily built on top of a WSIL parser for searching WS-Inspection documents. For example, the Web Services Inspection Language for Java API (WSIL4J) provides a Java interface that can be used to parse existing WS-Inspection documents or programmatically create new ones. The WSIL4J is included in the Web Services Toolkit (WSTK) release ( Most of the WSIL4J classes represent elements that can appear in a WS-Inspection document. The WSIL4J API also provides a WSILProxy class that can be used to easily access certain types of information within a WS-Inspection document. The proxy interface will read the WS-Inspection document and then allow you to directly access the WSDL documents for UDDI business services you need.

As for simple UDDI search, a UDDI client can be used to search a UDDI registry. The typical Java-based UDDI client is UDDI4J (UDDI for Java,, an open-source project initialized by IBM. UDDI4J is a Java class library that provides an API to interact with a UDDI registry. The UDDI Project is a comprehensive, open industry initiative enabling businesses to discover each other and define how they interact over the Internet and share information in a global registry architecture. Currently, UDDI4J version 2 beta is available. It provides full support of the UDDI v2 specification, support for multiple SOAP transports including AXIS (SOAP version 3), debug logging, and configuration capabilities. HP, IBM, and SAP announced in December 2001 that they've committed to supporting UDDI4J.

As shown in Figure 2, a Web services search requester can use WSIL4J to look into WS-Inspection documents represented as WSIL. If a requester wants to search a UDDI registry, he/she needs to use a UDDI client such as UDD4J. As the public UDDI operators, IBM, Microsoft, SAP, and HP provide their own Web browser interface to allow users to specify the search criteria for a specific search from their own UDDI registry.

In general, UDDI can locate businesses whose identities are well known so users can find out what services they offer and how to interface with them electronically. But one of the big concerns is accuracy. When a specific category is registered along with UDDI registration data, only people searching for that exact category will find the results (see Moreover, the simple UDDI search is focused on a single search criterion such as business name, business location, business category, or service type by name, business identifier, and discovery URL. With a projected near-term population of several hundred thousand to a million distinct entities, it's unlikely that searching for businesses that satisfy a particular set of criteria will yield a manageable result set. The current advanced UDDI search is trying to deal with multiple search criteria included in a single search request for a fixed UDDI registry.

Current search APIs are rudimentary at best, and developers must write a lot of code to find the Web services they desire. Especially from an e-business application developer's point of view, it's necessary to send a few sequential or programmed search commands to the UDDI registry or other Web services sources, such as WSIL documents, for information aggregation. The information sources may include multiple UDDI registries and other searchable sources. Obviously, there is a need to provide an advanced search mechanism for Web services to dramatically extend the current search capability, which is based on categories or key words, by improving efficiency and enhancing performance.

The UDDI Browser provided by allows you to search custom or private UDDI registries. One UDDI registry should be specified for each request. This doesn't support the aggregation of search results from multiple UDDI registries or other Web services sources.

Next-Generation Web Services Discovery Mechanism
The script-based search agent will likely play an important role in Web services discovery for Web browser-based Web services, discovery clients, and e-business applications. The mechanism should:

  • Use a standard interface
  • Simplify the developer's work
  • Hide the complexity of UDDI and WSIL search clients
  • Perform result aggregation from one or multiple sources
  • Act as an advanced search portal on an application server
Based on these concerns, the next-generation Web services discovery mechanism should look like the search agent shown in Figure 3. The advanced Web services search agent can be accessed by a regular application client or Web browser and communicates with multiple UDDI registries and WS-Inspection documents. A complicated result aggregation mechanism can be defined in the search agent. When a service requester looks for a Web service, three basic data types can be returned from UDDI registries: businessEntity, businessService, and ServiceType (Technical Model, t-Model).


The example aggregation includes, but isn't limited to, intersection-, union-, and script-based logic operation for the resulting responses from multiple sources. The final response to the search requester may be a new XML format or an existing XML format such as WSIL. Due to its extensibility WSIL will play an important role in representing the aggregated result.

In addition, the semantic information about Web services will contribute to efficient Web services discovery. For example, Web services discovery described in DAML for Web Services (DAML-S) involves the automatic location of Web services that provide a particular service and adhere to requested constraints. DAML-S is trying to provide declarative advertisements of service properties and capabilities that can be used for automatic service discovery. The disadvantage of DAML-S is in trying to create a new Web services registry from scratch. If it can describe the semantic information of regular Web services published in UDDI registries or WS-Inspection documents, DAML-S can be adopted by the next-generation Web services discovery mechanism.

On the other hand, the Web Services Relationships Language (WSRL) describes the relationships of the Web services rather than the requests. Current Web services specifications and UDDI specifications lack definitions and descriptions of the generic relationships among business entities, business services, and operations. But these relationships are keys to composing and executing dynamic business processes integration. Web services relationships are defined at different levels: business-business relationships, business-service relationships, service-service relationships, business-operation relationships, service-operation relationships, and operation-operation relationships. The resulting relationships are captured by WSRL. For example, the partner relationship among business entities defined in WSRL can help the Web services discovery mechanism effectively locate desired service providers based on the specific search criteria. Currently, a simple relationship (publisherAssertion) between two parties has been defined in UDDI v2. The WSRL will be a natural extension to publisherAssertion.

The next-generation Web services discovery mechanism should be built on uniform script-based XML search requests a, federated UDDI search engine with result aggregation, semantic information utilization, and relationship definition in WSRL.

An Example: Business Explorer for Web Services
IBM has been pioneering the advanced Web services discovery work through its alphaWorks technology - Business Explorer for Web Services (BE4WS) - since last December. I believe other companies will follow up to develop similar technologies or systems. Currently, BE4WS has been enhanced to support UDDI version 2 and SOAP version 3 (i.e., AXIS). You can get the latest technology release of BE4WS from Web Services Toolkit version 3.1 or later.

What are the major differences between using BE4WS and using a regular UDDI client? A UDDI client like the UDDI4J typically provides only lower-level APIs for searching the UDDI registry. BE4WS provides higher-level APIs to take advantage of UDDI4J or other clients, such as the WS-Inspection search tool, to define a script-based search request, aggregate search results, and explore multiple UDDI registries concurrently. For example, a script-based single USML (UDDI Search Markup Language) request in BE4WS can include multiple queries, different UDDI sources, and an aggregation operator. The returned result is aggregated from different UDDI registries or other sources according to the search criteria defined in the USML script. If you're using UDDI4J alone, you must write your own code to send out multiple search queries to different UDDI registries and then aggregate the data yourself. Obviously, this is a time-consuming process, and an advanced UDDI search engine can better handle such requests.

BE4WS can incorporate not only different Web services discovery technical layers (such as UDDI for Java technology or other similar UDDI client packages), but also different sources (such as standard UDDI registries, WS-Inspection documents, etc.). So BE4WS enables you to interact with XML representations of a UDDI exploring mechanism instead of working directly with UDDI for Java technology and other UDDI clients. With BE4WS, you can use the same programming model regardless of how your Web services discovery clients are implemented. BE4WS could emerge as a standard efficient and effective exploring mechanism and common interface for UDDI registries and other sources.

BE4WS provides two types of APIs for business application developers: a regular Java API and a Web services interface. Three pubic methods have been exposed in the BE4WS: searchByFi leName, search ByString, and searchByURL. Any e-business application developer can use these APIs to easily find desired business entities, services, and service types (tModels) from different UDDI registries using a single Java or SOAP call. The only input parameter for these calls is a USML request string or a USML document location. The returned result is also a USML response document. Thus, BE4WS can be easily deployed as a central UDDI search portal. All authorized e-business applications can take advantage of this service to explore business and service information across multiple UDDI registries.

Once a BE4WS Web service is published in a private or public UDDI registry, any application can find this useful UDDI search service and invoke it through a WSDL interface. The installed BE4WS Web service works as an advanced UDDI search portal that allows SOAP clients to search for business and service information in multiple UDDI registries. There are two methods in the BE4WS Web service: searchByString and searchByURL. The SOAP service ID is urn:uddisearch-service, and the provider class is com. ibm.UDDI.BusinessExplorer. UDDI Search.

Listing 1 illustrates a USML script. There are two queries in one USML request, and this request will be sent to BE4WS. The first query represents the search requester who wants to find business entities whose names include Explorer from Private UDDI Registry 1 installed on wsbi5. The second query represents the search requester who wants to find business entities whose names start with KEP from Private UDDI Registry 2 installed on wsbi10. The results from these two UDDI registries will be aggregated according to the definition of AggOperator (Aggregation Operator) in the USML script. In this example the two results will be united and sent back to the search requester. The Aggregation Operator can be defined as "OR", "AND", or "Script". The detailed description of the tags in the USML can be found in the BE4WS informayion included in the WSTK 3.1 release.

After the user creates the above simple script, named BE4WS-example.xml, he/she can put this file into the local system or on a Web server. If this USML script is stored on the local system, the user simply needs to type the following command to execute the BE4WS engine:

Java services.demos.be4ws.client.Demo1 BE4WS-example.xml

Listing 2 shows the search result - a typical business list composed from two UDDI registries.

As mentioned earlier, BE4WS can be deployed on an application server as an advanced Web services search portal for B2B integration or Web application integration. For example, the federated UDDI search request defined in Listing 1 could be used by an enterprise application, such as an intelligent service locator (agent), to look up UDDI registries for finding desired services providers. The aggregated search result (USML response) shown in Listing 2 can be parsed and presented in a JavaServer Page (JSP) created by the intelligent service locator. Figure 4 shows the aggregated result from BE4WS.


This example demonstrates a simple USML script for searching multiple UDDI registries. This method simplifies the developer's programming work and provides a more accurate result aggregated by BE4WS according to the search criteria defined in the USML script.

We know the existing Web services discovery mechanisms are designed for very limited use of UDDI or WS-Inspection documents. The BE4WS-like, script-based Web services discovery mechanism with result aggregation from different sources - a key enabling technology for e-business integration providers - will be the next big thing in the integration of Web services applications.

More Stories By Liang-Jie Zhang

Dr. Liang-Jie Zhang is a researcher at IBM T.J. Watson Research Center. He
has more than 12 years of experience in creating novel technologies and
products for streaming media, e-business integration and intelligent
information appliances. He is actively working on enhanced Web Services
technologies for B2B integration. Liang-Jie has numerous patents and is
chairing "Web Services Computing" at IC'2002.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.