Chapter 31. Discovering Web Services

Introduction

Now it’s time to answer these questions: How can I advertise my Web service? What is the best searching mechanism that will produce the most precise and appropriate list of possible Web services that will meet my needs? This chapter briefly introduces the standard in Web service registries, Universal Description, Discovery, and Integration (UDDI), and what it has to offer. UDDI is an initiative conceived and sponsored by a private consortium of technology companies named uddi.org. This chapter then explains how WebLogic Server supports this technology. Prior knowledge of UDDI (the UDDI API and its data structures) is presumed and is necessary for comprehending the concepts in this chapter. More information on UDDI can be found at www.uddi.org.

The service-oriented architecture of Web services is shown in Figure 31.1.

Players in a Web service-oriented architecture.

Figure 31.1. Players in a Web service-oriented architecture.

A service provider offers some Web services, but these services are useless if no client knows about them. Hence, the provider publishes its services in a UDDI registry. A client can then search or browse a UDDI registry to discover Web services that meet its needs. When an appropriate service is found, the client then invokes the service from the provider.

Service discovery can occur at two possible junctures:

  • During client development—When the client is being written, a UDDI registry can be manually browsed or searched for appropriate services. The client developer reads the service details and hard-codes the service invocations into the client. This is also known as static discovery.

  • During client execution—The client is written such that, at runtime, it contacts a UDDI registry of choice and issues the necessary UDDI calls to find and then bind to a particular service. It then needs to comprehend the service details and formulate a service call in the format prescribed by the technical service interface. Although implementing this paradigm of dynamic discovery is obviously more complex, it does provide the ultimate in flexibility of service choice and provider choice. For reasons we won’t describe here, this approach may not be practical at the current evolution of Web services. But there are many possibilities for static/dynamic hybrids, where certain service elements can be known and hard-coded at development time (such as a service interface) and some discovered dynamically (such as a service location/URL).

Again, it is not the intent of this chapter to provide a full treatise on UDDI. The goal is to provide a simplified and high-level discussion of the UDDI technology and to point out what WebLogic Server 7.0 features support UDDI.

What Is UDDI?

The goal of UDDI is to provide a Web-based registry for the publishing and advertising of businesses and their Web services so that clients can not only discover such services, but also glean information on how to invoke them.

UDDI is composed of the following:

  • An API for searching the registry, the Inquiry API, and for publishing your service in the registry, the Publish API. UDDI publishes the API specifications but does not provide an implementation. These specifications are available at http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf.

  • A prescribed set of data structures used by the API. Again, UDDI publishes only the specification, not the implementation. These specifications are available at http://www.uddi.org/pubs/DataStructure_v2.pdf.

  • A schema definition for the various SOAP messages and responses that are necessitated by the API. This schema is available at http://www.uddi.org/schema/uddi_v2.xsd.

How Does UDDI Work?

As Figure 31.1 shows, the players communicate exclusively using SOAP messages and SOAP responses. In a sense, you can say that the UDDI Inquiry and Publish calls are themselves Web services. Contrary to what you might think, the UDDI API is not a programmatic, language-specific API. That is, each UDDI API as defined in the UDDI specifications is not a programmatic function call. Instead, each API call is actually a distinct SOAP message and response. Therefore, a server that claims to implement the UDDI API must understand each of these SOAP calls, perform the necessary call logic, and then respond appropriately with a SOAP response message.

A UDDI registry can be hosted by one or more UDDI operators, or nodes. A UDDI operator implements the UDDI API and, of course, also implements the necessary back-end logic to persist the registry information and perform lookups on that persistent store. UDDI does not prescribe any particular implementation or persistence mechanism. A UDDI operator has one other critical responsibility: to make sure all information in all UDDI nodes is synchronized. That is, a client should be able to inquire from any UDDI node and receive the same results.

The UDDI API at a Glance

A UDDI registry basically answers the following questions:

  • Who? It identifies the business entity offering the service.

  • What? Classification information sheds light on what the business purports to offer, as well as all service descriptions.

  • Where? It identifies the service location (such as a URL for an HTTP binding or an e-mail address for SMTP binding).

  • How? It provides information on the technical interface or process for the service, called tModels.

The API affords clients a number of search methods:

  • They can search by business name. This is known as the “white pages” search method, directly alluding to the telephone directory white pages.

  • They can search by business category. This is known as the “yellow pages” search method, directly alluding to the telephone directory yellow pages. Here, you use the categoryBag and identifierBag attributes to specify search parameters.

  • After you find a business, you can query its specific service interface details by using bindingTemplate and tModel, called the “green pages.”

  • A tModel likely describes a standard service interface that many businesses in the same problem space may support. If you already have the tModel at hand (identified by a tModelKey), you can also conduct a search for all businesses that support that tModel.

The UDDI API utilizes certain data “structures,” although they are not programming data structures like those you would use in Java. Rather, they are units of structured XML data used in the UDDI API SOAP messages and responses. The main structures include the following (this list is not exhaustive):

  • BusinessEntity—. Represents a business that offers some Web service. It carries information such as business name, description, and contacts.

  • BusinessService—. Represents a particular business service being offered and includes information such as its service name, description, classification (via categoryBag construct), and bindingTemplate(s).

  • BindingTemplate—. A binding of a service to a particular transport (such as SOAP) and protocol (such as HTTP).

  • tModel—. A service interface definition that is not tied to any particular binding or provider. This abstract and reusable service definition can be referenced by any number of businessEntities offering the same service. For instance, a standardized Payment Authorization service might have an industrywide tModel defined.

Refer to the UDDI Data Structures specification for more information; it is available at http://www.uddi.org/pubs/DataStructure_v2.pdf.

UDDI Usage Patterns

To understand the intended UDDI interaction paradigm, you need to look at three query patterns:

  • Browse pattern—You start with some broad information such as a business name and perform a search by name. From the results returned, you then drill down to its list of service offerings. When you find a desired service, you then find its available bindings and so on. This pattern emphasizes broad navigation, without getting deep into any item, as illustrated by actions 1, 2, 3, and 4 in Figure 31.2.

    UDDI Inquiry usage patterns.

    Figure 31.2. UDDI Inquiry usage patterns.

  • Drill-down pattern—Obtaining a key using the Browse pattern, you can find all detailed, registered information available. This pattern is illustrated in Figure 31.2 for any series of actions involving 1A, 2A, 3A, and 4A.

  • Invocation pattern—By drilling down to the “green pages” (actions 3A and 4A in Figure 31.2), you can glean technical interface information necessary for you to understand what message structure must be used to invoke a service. This knowledge can be codified during development, whereas some other information can be dynamically cached (such as service endpoints) and the cache refreshed as necessary (as runtime UDDI queries reveal).

A Sample Use Case

Suppose you heard about a company called WeatherCentral that offers a weather report service, and you need to find out where that service is located and how to invoke it. You can use a combination of the Browse and Drill-down patterns by starting a white pages search for the business entity by name. Then you can find the appropriate service category, from which you can examine the service’s possible bindings (HTTP-based or SMTP-based and so on) and its tModel. From there, you should have all the information you need to invoke the weather Web service.

The Inquiry API

The Inquiry API messages are for browsing or searching the UDDI registry, and because these functions are strictly read-only, no authentication is required to invoke them. Table 31.1 lists the two groups of inquiry messages: the Find group, which returns overview information, and the Obtain Details group, which returns all information about an item. These are the main Inquiry API calls; this list is not exhaustive. (The response message type is shown in parentheses.)

Table 31.1. Main Inquiry API Messages

 

Business

Service

Binding

tModel

Find

find_business (businessList)

find_service (serviceList)

find_binding (bindingDetail)

find_tModel (tModelList)

Obtain Details

Get_businessDetail (businessDetail)

Get_serviceDetail (serviceDetail)

Get_bindingDetail (bindingDetail)

Get_tModelDetail (tModelDetail)

The Publish API

The Publish API messages are for publishing your business, service, binding, or tModel to the UDDI registry. Because these functions alter the registry, authentication is required for invoking these calls. An opaque token must first be obtained from the target UDDI operator by invoking the get_authToken call, which returns an authentication token that is valid for use only with publishing to that particular UDDI operator. That is, opaque tokens are not portable.

Note

When you are done publishing with that UDDI operator, you should send it a discard_authToken message.

Table 31.2 lists the main publish API messages (this list is not exhaustive).

Table 31.2. Main Publish API Calls

 

Business

Service

Binding

tModel

Create New

save_business

save_service

save_binding

save_tModel

Delete

delete_business

delete_service

delete_binding

delete_tModel

What a UDDI SOAP Call Looks Like

It’s time to see exactly what SOAP messages are being sent and returned when a UDDI API call is made. Here, you will look at the find_service invocation, which searches a given businessEntity (identified by the businessKey attribute) for certain services based on matching criteria: in this case, that the service name matches Authorize Payment. Listing 31.1 shows the UDDI SOAP request.

Example 31.1. SOAP Request for the find_service UDDI Invocation

<Envelope xmlns=... >
  <Body>
<find_service businessKey="D8J4D980-78W7-33L4-98745DRF9909"
   generic="1.0" xmlns="urn:uddi–org:api">
   <name>Authorize Payment</name>
</find_service>
  </Body>
</Envelope>

Listing 31.2 shows the UDDI SOAP response.

Example 31.2. SOAP Response from the find_service UDDI Call

<Envelope xmlns=...>
  <Body>
<serviceList generic="1.0" operator="UDDIOperator"
   truncated="false" xmlns="urn:uddi-org:api">
   <serviceInfos>
      <serviceInfo businessKey="D8J4D980-78W7-33L4-98745DRF9909"
         serviceKey="BGRG3457-7D2G-44K6-9YU5-G0L4488K893E">
      <name>Authorize Payment</name>
   </serviceInfos>
</serviceList>
   </Body>
</Envelope>

In any of the find_xxx calls, you can also specify a service classification by using categoryBag and/or identifierBag as a search parameter.

UDDI Features in WebLogic Server

WebLogic Server provides the following components for service registry functionality:

  • Implementation of the UDDI 2.0 API. That is, WebLogic Server is capable of being a UDDI operator that can host your own private registry of Web services. Start the server by running

    <w1_home>weblogic700samplesserverconfigexamplesstartExamplesServer.cmd
    

    When the WebLogic Examples server is started, it deploys an endpoint that acts as a UDDI listener who understands all the UDDI API SOAP messages. This endpoint is actually a J2EE Web application found in

    <wl_home>weblogic700samplesserverconfigexamplesexamplesServer.internaluddi.war
    
  • A UDDI client proxy layer (Java API). Using it, you can conveniently write Java programs that make UDDI searches or publish actions, without needing to craft the UDDI SOAP calls or parse the UDDI SOAP responses like those shown in Listings 31.1 and 31.2.

  • A browser-based tool, called the UDDI Directory Explorer, for managing your private registry. It also acts as a registry of public or external UDDI registries on which you can perform searches.

The WebLogic UDDI Client Proxy

The UDDI client proxy offers convenience classes that facilitate the writing of Java clients which interact with a UDDI registry. Specifically, these proxies obviate the need for your Java client to be aware of the various UDDI API Inquiry and Publish SOAP message formats. They provide an abstraction layer that closely mirrors the UDDI API data structures and interactions. All these classes are packaged in the main WebLogic Server library:

<wl_home>weblogic700serverlibweblogic.jar

The proxy layer is composed of several Java packages that implement the following: UDDI data structures, the Inquiry and Publish calls, classes that simplify invoking the API, and classes that facilitate consumption of API responses.

UDDI Data Structures Implementation: weblogic.uddi.client.structures.datatypes

The Java package weblogic.uddi.client.structures.datatypes implements some of the data structures used by the UDDI API, as documented in the “UDDI Version 2.0 Data Structure Reference” specification. It also implements a few new convenience structures that are not part of the specifications. Some of the main classes in this package that will be used in the following examples are

  • BusinessEntity, BusinessKey, BusinessInfo, BusinessInfosBusinessService, ServiceKey, ServiceInfo, ServiceInfosBindingTemplate, BindingKey, BindingTemplates—. Main structures used in the Inquiry and Publish APIs

  • AuthInfo—. Used to specify the opaque authentication token that is required for the publish API

  • FindQualifier, FindQualifiers—. Used for specifying search parameters when invoking the Inquiry API find_xxx calls

API Request Data Objects: weblogic.uddi.client.structures.request

The Java Package weblogic.uddi.client.structures.request contains more convenience classes that provide data objects used for invoking the UDDI API. One distinct object needs to be “filled out” and then passed into each API call. For instance, the FindBusiness class needs to be instantiated, configured, and then passed to the inquiry.findBusiness() method. These structures are not part of the UDDI specifications. You will learn more about this in the ensuing examples.

API Response Data Objects: weblogic.uddi.client.structures.response

The Java Package weblogic.uddi.client.structures.response implements classes for each response message structure documented in the UDDI Data Structures specification. For instance, this package provides a BusinessList object that would be returned by the inquiry.findBusiness() call.

The Inquiry Class: weblogic.uddi.client.service.Inquiry

The Java Package weblogic.uddi.client.service.Inquiry class implements the UDDI Inquiry API described in Table 31.1, providing methods to accomplish the Find and Obtain Details functionality. Listing 31.3 shows the main methods in this class, which help tie all these proxy packages together.

Example 31.3. Methods in the Inquiry Proxy

import weblogic.uddi.client.structures.response.*;
import weblogic.uddi.client.structures.request.*;
import weblogic.uddi.client.structures.exception.*;

BindingDetail findBinding(FindBinding x) throws UDDIException,
                                                XML_SoapException;

BusinessList findBusiness(FindBusiness x) throws UDDIException,
                                                 XML_SoapException;

ServiceList findService(FindService x) throws UDDIException, XML_SoapException;

TModelList findTModel(FindTModel x) throws UDDIException, XML_SoapException;

BindingDetail getBindingDetail(GetBindingDetail x) throws UDDIException,
                                                          XML_SoapException;

BusinessDetail getBusinessDetail(GetBusinessDetail x) throws UDDIException,
                                                             XML_SoapException;

BusinessDetailExt getBusinessDetailExt(GetBusinessDetailExt x) throws
                                  UDDIException, XML_SoapException;

ServiceDetail getServiceDetail(GetServiceDetail x) throws UDDIException,
                                                          XML_SoapException;

TModelDetail getTModelDetail(GetTModelDetail x) throws UDDIException,
                                                       XML_SoapException;

void setURL(String x);  // set URL of target UDDI operator to inquire of
String getURL();

Note the following “holistic” observations:

  • All the return types shown are in the response package.

  • All first parameter types are in the request package.

  • All method exceptions are in the weblogic.uddi.client.structures.exception package.

  • Compare these signatures to Table 31.1 and note that the response message types shown there correspond to each of the return types in Listing 31.3.

The Publish Class: weblogic.uddi.client.service.Publish

The Java Package weblogic.uddi.client.service.Publish class implements the UDDI Publish API described in Table 31.2, providing methods to accomplish the Create New and Delete functionality. Listing 31.4 shows the main methods in this class, which help tie all these proxy packages together.

Example 31.4. Methods in the Publish Proxy

import weblogic.uddi.client.structures.response.*;
import weblogic.uddi.client.structures.request.*;
import weblogic.uddi.client.structures.exception.*;

DispositionReport deleteBinding(DeleteBinding x) throws UDDIException,
                                                        XML_SoapException;

DispositionReport deleteBusiness(DeleteBusiness x) throws UDDIException,
                                                          XML_SoapException;

DispositionReport deleteService(DeleteService x) throws UDDIException,
                                                        XML_SoapException;

DispositionReport deleteTModel(DeleteTModel x) throws UDDIException,
                                                      XML_SoapException;

DispositionReport discardAuthToken(DiscardAuthToken x) throws UDDIException,
                                                              XML_SoapException;

AuthToken getAuthToken(GetAuthToken x) throws UDDIException, XML_SoapException;

RegisteredInfo getRegisteredInfo(GetRegisteredInfo x) throws UDDIException,
                                                             XML_SoapException;

BindingDetail saveBinding(SaveBinding x) throws UDDIException, XML_SoapException;

BusinessDetail saveBusiness(SaveBusiness x) throws UDDIException,
                                                   XML_SoapException;

ServiceDetail saveService(SaveService x) throws UDDIException, XML_SoapException;

TModelDetail saveTModel(SaveTModel x) throws UDDIException, XML_SoapException;

DispositionReport validateCategorization(ValidateCategorization x)
                                       throws UDDIException, XML_SoapException;

void setURL(String x); // set URL of target UDDI operator to publish to
String getURL();

Sample Client Code (Tasks)

Now it’s time to look at some sample UDDI tasks performed using the WebLogic UDDI client proxies.

Finding a Business

Listing 31.5 shows a business lookup by name, that is, using the “white pages” paradigm. This is only a code snippet; some code statements have been omitted for brevity.

Example 31.5. Looking Up a Business by Name

import weblogic.uddi.client.service.Inquiry;

import weblogic.uddi.client.structures.datatypes.Name;
import weblogic.uddi.client.structures.datatypes.Result;
import weblogic.uddi.client.structures.datatypes.ErrInfo;
import weblogic.uddi.client.structures.datatypes.BusinessInfo;
import weblogic.uddi.client.structures.datatypes.BusinessInfos;
import weblogic.uddi.client.structures.datatypes.FindQualifiers;

import weblogic.uddi.client.structures.request.FindBusiness;

import weblogic.uddi.client.structures.response.BusinessList;
import weblogic.uddi.client.structures.response.DispositionReport;

import weblogic.uddi.client.structures.exception.UDDIException;
import weblogic.uddi.client.structures.exception.XML_SoapException;

public void LookupBusiness() {

    // Init the Inquiry object
    Inquiry inquire = new Inquiry();
    inquire.setURL("http://localhost:7001/uddi/uddilistener"); // uddi operator

    try {

      // Prepare to invoke find business method
      Name name = new Name("PaymentsRUs");

      FindQualifiers searchParms = new FindQualifiers();
      searchParms.addFindQualifier("exactNameMatch");
      searchParms.addFindQualifier("caseSensitiveMatch");

      // Obtain & fill out findBusiness data object
      FindBusiness findBizDO = new FindBusiness();
      findBizDO.setFindQualifiers(searchParms);
      findBizDO.setName(name);

      // CALL FIND BUSINESS
      BusinessList bizList = inquire.findBusiness(findBizDO);

      // Process results
      BusinessInfos bizInfos = bizList.getBusinessInfos();

      if (bizInfos == null) {
         System.out.println("Could not locate Business: " + name.getValue());
         return;
      }

      // Assume biz name is unique - only one bizInfo returned
      Vector bizInfoVector = bizInfos.getBusinessInfoVector();
      BusinessInfo bizInfo = (BusinessInfo) bizInfoVector.elementAt(0);

      // Print out results
      System.out.println("********* BUSINESS FOUND ********");
      System.out.println("Attribute BusinessKey: "
                                 + bizInfo.getBusinessKey());

      Name bizName = bizInfo.getName();
      System.out.println("Name : " + bizName.getValue());

      String bizKey = bizInfo.getBusinessKey();

    } catch (UDDIException uex) {
         System.out.println("UDDIEXception: ");
         System.out.println(uex.getFaultActor());
         System.out.println(uex.getFaultCode());
         DispositionReport report = uex.getDispositionReport();
         Vector results = report.getResultVector();
         Result res = (Result) results.elementAt(0);
         ErrInfo errInfo = res.getErrInfo();
         System.out.println("Error Info : " + errInfo.getValue());
    } catch (XML_SoapException exc) {
         System.out.println("XML_SoapException: ");
         System.out.println(exc.getMessage());
         exc.printStackTrace();
    } catch (Exception e) {
         System.out.println("Exception: ");
         e.printStackTrace();
    }
}

Finding a Service

Listing 31.6 shows a method that looks up a service from a known business (a known businessKey). This is only a code snippet; some statements have been omitted for brevity. The omitted catch statements are the same as those shown in Listing 31.5.

Example 31.6. Looking for a Service in a Particular Business

import WebLogic.uddi.client.service.Inquiry;

import WebLogic.uddi.client.structures.datatypes.FindQualifiers;
import WebLogic.uddi.client.structures.datatypes.BusinessKey;
import WebLogic.uddi.client.structures.datatypes.ServiceInfo;
import WebLogic.uddi.client.structures.datatypes.ServiceInfos;

import WebLogic.uddi.client.structures.request.FindService;
import WebLogic.uddi.client.structures.response.ServiceList;
import WebLogic.uddi.client.structures.exception.*;


public void LookupServiceInBusiness(String bizKeyString) {

    // Init the Inquiry object
    Inquiry inquire = new Inquiry();
    inquire.setURL("http://localhost:7001/uddi/uddilistener"); // uddi operator

    try {
      BusinessKey bizKey = new BusinessKey(bizKeyString);
      Name name = new Name("Authorize Payment");

      FindQualifiers searchParms = new FindQualifiers();

      searchParms.addFindQualifier("sortByNameDesc");
      searchParms.addFindQualifier("caseSensitiveMatch");

      // Obtain & fill out findService data object
      FindService findServiceDO = new FindService();
      findServiceDO.setBusinessKey(bizKey.getValue());
      findServiceDO.setFindQualifiers(searchParms);
      findServiceDO.setName(name);

      ServiceList serviceList = inquire.findService(findServiceDO);

      ServiceInfos serviceInfos = serviceList.getServiceInfos();

      if (serviceInfos == null) {
        System.out.println("Could not locate service: " + name.getValue());
        return;
      }

      // Assume service name is unique - only 1 service found
      Vector serviceInfoVector = serviceInfos.getServiceInfoVector();
      ServiceInfo serviceInfo = (ServiceInfo) serviceInfoVector.elementAt(0);

      // Print results
      System.out.println("********* SERVICE FOUND ********");
      System.out.println("Registered Service Name: "
                                     + serviceInfo.getName().getValue());
      System.out.println("Service Key: " + serviceInfo.getServiceKey());

    } catch (UDDIException ue) {
      ...
    }
}

Creating a New Business

The example in Listing 31.7 uses the Publish API to save a new business into the registry. Recall that authentication is required for publishing into the UDDI registry; therefore, you need to obtain an opaque authentication token by invoking the getAuthToken call.

Example 31.7. Publishing a New Business into UDDI

import weblogic.uddi.client.service.Publish;

import weblogic.uddi.client.structures.request.GetAuthToken;
import weblogic.uddi.client.structures.request.SaveBusiness;
import weblogic.uddi.client.structures.request.DiscardAuthToken;

import weblogic.uddi.client.structures.response.AuthToken;
import weblogic.uddi.client.structures.response.BusinessDetail;

import weblogic.uddi.client.structures.datatypes.BusinessEntity;
import weblogic.uddi.client.structures.exception.*;


public void createNewBusiness() {

    // Init the Publish object
    Publish publish = new Publish();
    publish.setURL("http://localhost:7001/uddi/uddilistener"); // uddi operator

    try {

      // Obtain auth info, using user+pw for WLS Examples Server
      GetAuthToken getAuthTokenDO = new GetAuthToken();
      getAuthTokenDO.setUserID("WebLogic");
      getAuthTokenDO.setCred("WebLogic");

      AuthToken authToken = publish.getAuthToken(getAuthTokenDO);
      AuthInfo authInfo = authToken.getAuthInfo();

      // Obtain & fill out biz entity object
      BusinessEntity bizEntity = new BusinessEntity();

      bizEntity.setBusinessKey("");
      bizEntity.setName("PaymentsRUs");
      bizEntity.addDescription("Payment Processing Center");

      Vector bizEntityVector = new Vector();
      bizEntityVector.add(bizEntity);

      // Obtain & fill out Save Business data object
      SaveBusiness saveBizDO = new SaveBusiness();
      saveBizDO.setAuthInfo(authInfo);
      saveBizDO.setBusinessEntityVector(bizEntityVector);

      // CALL SAVE BUSINESS
      BusinessDetail bizDetails = publish.saveBusiness(saveBizDO);

      // Print results
      bizEntity = (BusinessEntity)
                       bizDetails.getBusinessEntityVector().elementAt(0);

      System.out.println("********* BUSINESS SAVED *********");
      System.out.println("BusinessName = " + bizEntity.getName().getValue() +
                         "
Key = " + bizEntity.getBusinessKey());

      // Don't forget to log off!
      DiscardAuthToken discardAuthTokenDO = new DiscardAuthToken();
      discardAuthTokenDO.setAuthInfo(authInfo);
      publish.discardAuthToken(discardAuthTokenDO);

    } catch (UDDIException ue) {
      ...
    }
}

This example shows only how to create a new business. Typically, you would next invoke a save service belonging to this new business and then a save binding for completeness.

The WebLogic UDDI Directory Explorer

WebLogic Server 7.0 provides a basic browser-based tool for keeping a private registry of Web services and their WSDL files. The out-of-the-box WebLogic Examples server, by default, implements a UDDI operator at

http://localhost:7001/uddi/uddilistener

The UDDI operator is deployed as a J2EE Web application in uddi.war, and the UDDI Explorer as uddiexplorer.war, both in

<wl_home>weblogic700samplesserverconfigexamplesexamplesServer.internal

The UDDI Explorer, by default, is set to point to this listener. It uses the official UDDI API client proxy exclusively when inquiring or publishing to a private registry. That is, it actually sends UDDI SOAP messages to the Examples server that implements a Private UDDI operator, or to any public UDDI operator in your list. In addition, it uses the WebLogic UDDI client proxy classes Inquiry and Publish for generating all SOAP messages and parsing all SOAP responses from the operator.

The UDDI Explorer utilizes a simple and intuitive hierarchy of projects and services, as shown in Figure 31.3.

How the UDDI Explorer organizes services.

Figure 31.3. How the UDDI Explorer organizes services.

At the top level are one or more projects or departments, which can own multiple Web services as well as contacts. Contacts are not associated with any particular service, but to a project. Changes to your private registry require authorization via a username and password.

The following sections discuss how to create, edit, and manage these objects. The UDDI Explorer can also serve as a “Registry of Registries”; it can maintain a list of public registries (links) for your searching convenience.

This approach basically implements a registry of WSDL files, unlike the more comprehensive UDDI framework, which is a flexible, generic mechanism for categorizing services using any taxonomic system you choose and with any service description format (not just WSDL) you need.

Running UDDI Explorer

You can invoke the UDDI Explorer by doing the following:

  1. At a DOS command prompt, start the WebLogic Examples server by invoking the start script:

    <wl_home>weblogic700samplesserverconfigexamplesstartExamplesServer.cmd
    
  2. Go to the following URL:

    http://localhost:7001/uddiexplorer
    

Figure 31.4 shows the WebLogic UDDI Explorer home page.

The WebLogic UDDI Explorer home page.

Figure 31.4. The WebLogic UDDI Explorer home page.

The actions available on the left pane are as follows:

  • Search Public Registries—Allows you to perform searches using various search parameters such as businessName and key on external public service registries not hosted by WebLogic. You must maintain the list of public registries to search on, via the Setup UDDI Directory Explorer page, discussed below. WebLogic does not cache or mirror any information found in these sites; rather, it merely functions like a search engine. Obviously, you need Internet connectivity to run these searches.

  • Search Private Registry—Provides a starting point for finding existing projects and services.

  • Publish Private Registry—Provides a quick link for adding new services and contacts. You are required to log in to access these pages. The out-of-the-box username/password combination for the WebLogic Examples server is weblogic/weblogic unless your system administrator has changed it.

  • Modify Private Registry Details—Allows you to add new projects and edit existing projects. From here, you can also manage services and contacts (add, delete, modify). You are required to log in to access these pages. See the preceding bullet.

  • Setup UDDI Directory Explorer—Allows you to select the private registry you want to browse or manage and maintain a list of public UDDI registries on which you want to be able to perform searches using this UDDI Explorer.

Creating Entries in a Private Registry

The following steps show how to create a project called Orders, add a service called Payments, and add a contact:

  1. Invoke the UDDI Explorer.

  2. Click the Modify Private Registry Details link on the left pane of the UDDI Explorer. Log in with the username/password combination weblogic/weblogic.

  3. When the Modify Private Registry page appears, enter Orders in the Add New Project column and click the Add button (see Figure 31.5). When Orders appears in the list of projects, click the Orders link.

    Add new project page.

    Figure 31.5. Add new project page.

  4. The Add New Services and Contacts page then appears (see Figure 31.6). If there were any existing services or contacts, they are listed under Services List or Contacts List, respectively, each a live link enabling you to edit the existing item. Fill in the necessary fields for the new service and click Add New Service. You will need to come back to this page and add the contact later.

    Add new services or contacts page.

    Figure 31.6. Add new services or contacts page.

  5. When the Add New Service Confirmation page appears, click the Publish button; otherwise, the new service will not be added.

Table 31.3 outlines tasks that can be performed on projects and links to the pages for accomplishing them.

Table 31.3. Links to Follow to Accomplish Project Tasks

Task

Links to Navigate

Get a list of existing projects

Click Modify Private Registry Details.

Add a new project

Click Modify Private Registry Details; then click Add.

Edit a project name

Click Modify Private Registry Details; then click Edit Name.

Delete a project

Click Modify Private Registry Details; then click Remove.

Work on services for a project

Click Modify Private Registry Details; then click the project name.

Table 31.4 outlines tasks that can be performed on Services and Contacts and links to the pages for accomplishing them.

Table 31.4. Links to Follow to Accomplish Service and Contact Tasks

Task

Links to Navigate

Get a list of existing services or contacts

Click Modify Private Registry Details; then click a project.

Add a new service or contact

Click Modify Private Registry Details, click a project, and then click Add Service. Alternatively, click Publish to Private Registry.

Edit a service or contact

Click Modify Private Registry Details, click a project, and then click a service.

Delete a service or contact

Click Modify Private Registry Details, click a project, and then click Remove.

Browse a service

Click Search Private Registry, select List All Services, and then click the service name.

Summary

This chapter provided a cursory discussion on UDDI and what WebLogic Server features are available for you to either host your own private or public registry or be a client to a private or public registry.

The BEA dev2dev site is a collaborative environment where various demonstration and sample code can be posted for public consumption, specifically for WebLogic developers. You can find a separate downloads page for Web services samples, most notably on the use of UDDI in WebLogic, at

http://dev2dev.bea.com/managed_content/direct/webservice/index.html

You need to register with the dev2dev site to access these downloads; registration is free.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset