In This Chapter
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.
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.
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.
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.
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 tModel
s.
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.
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.
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).
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 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.)
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.
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).
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.
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.
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 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.
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
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.
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 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 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();
Now it’s time to look at some sample UDDI tasks performed using the WebLogic UDDI client proxies.
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(); } }
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) { ... } }
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.
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.
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.
You can invoke the UDDI Explorer by doing the following:
At a DOS command prompt, start the WebLogic Examples server by invoking the start script:
<wl_home>weblogic700samplesserverconfigexamplesstartExamplesServer.cmd
Go to the following URL:
http://localhost:7001/uddiexplorer
Figure 31.4 shows 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.
The following steps show how to create a project called Orders, add a service called Payments, and add a contact:
Invoke the UDDI Explorer.
Click the Modify Private Registry Details link on the left pane of the UDDI Explorer. Log in with the username/password combination weblogic/weblogic.
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.
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.
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 | |
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
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.