XML and Java: Developing Web Applications, Second Edition
| [ directory ] |
|
13.3 Service Registration and DiscoveryOnce you have described the information about the Web services, you must be concerned with how to provide requestors with it. According to the Web services architecture (see Figure 13.1), you can employ a service broker for publishing, and requestors can access your service information on a service broker by using find operations. Universal Description, Discovery, and Integration (UDDI) is a specification of an XML-based API for publish and find operations, with which service requestors and service providers can access service brokers. On the service broker, a UDDI server called the UDDI registry is running to manage registered information. In this section, we overview the basic concepts of UDDI and develop a program to access the UDDI registry with UDDI for Java (UDDI4J). UDDI itself is not specialized for WSDL; any format of service information can be registered. We describe a best practice to register WSDL on the UDDI registry. 13.3.1 Overview of UDDIThrough UDDI, you can register information about your Web services. Although our ultimate goal here is to register WSDL, UDDI takes into account a broader perspective梱ou can register businesses in addition to services. Figure 13.8 illustrates the key constructs of UDDI and the relationships among them. Figure 13.8. Key constructs of UDDI
A business entity indicates information about the business that may provide some services. For example, business names and their contact information are included. A business service contains only descriptive information about services. For example, service names and their narrative descriptions are included. Implementation-specific information on the services is described in a binding template. Typically, the access point of the service is included here, but more details, such as message formats, are included in technology model (tModel). tModel is one of the most important (and difficult) concepts in UDDI. UDDI does not define standard ways to describe the details of a business entity, business service, and binding template, because such detailed descriptions are provided by standardization bodies, industry associations, and software vendors. This indicates that we need a mechanism to refer to such detailed information described by those other than UDDI. tModel is viewed as metadata on such non-UDDI information. We will discuss tModel using concrete examples soon. Listing 13.12 shows an example of UDDI data for a business entity, business service, and binding template, using our travel service example. The businessEntity element represents the business that provides the services. The name and a narrative description of the business are included here. Note that all constructs of UDDI are assigned unique keys represented as a Universal Unique Identifier (UUID). As for businessEntity, its businessKey attribute indicates the key. Also, because a business can provide multiple services, there is a container element called businessServices. The categoryBag element at the end of the listing shows which category this business belongs to. However, to specify such a category, we need a taxonomy in advance. NAICS in the keyName attribute of keyedReference is the name of the taxonomy, and the ModelKey attribute is the ID of the taxonomy.[6] The keyValue attribute indicates a particular category in the NAICS taxonomy. The value 56151 indicates a category of "Travel agency."
The businessService element represents a particular service. A business service is described with a name and a description and potentially includes binding Templates. For example, if the service is provided via telephone and fax, no bindingTemplate is required. Like business entities, services can be mapped to categories. The categoryBag element in the businessService element shows that this service belongs to a category of 901215 in the UNSPSC taxonomy.[7] The value 901215 is a category of "Travel reservation service" in UNSPSC.
The bindingTemplate element represents implementation-specific information to access the service. The accessPoint element specifies the physical location of the service梩he URL. However, there is no information on how to format messages to access the service. Such service interface information is referred via a tModel that is pointed to by the tModelInstanceInfo element. Listing 13.12 UDDI data: business entity, business service, and binding template
<businessEntity authorizedName="nakamury1"
businessKey="0D0976E0-B4FC-11D5-84EB-AAA81F9305C3"
operator="kbaba2.trl.ibm.com:80/services/uddi">
<discoveryURLs>
<discoveryURL useType="businessEntity">
http://kbaba2.trl.ibm.com:80/uddi/get?
businessKey=0D0976E0-B4FC-11D5-84EB-AAA81F9305C3
</discoveryURL>
</discoveryURLs>
<name>XMLBook2 Travel Agency</name>
<description xml:lang="en">
Wonderful travels to Hawaii and Neighbor Islands
</description>
<businessServices>
<businessService
businessKey="0D0976E0-B4FC-11D5-84EB-AAA81F9305C3"
serviceKey="0E0D5250-B4FC-11D5-84EB-AAA81F9305C3">
<name>TravelReservationService</name>
<bindingTemplates>
<bindingTemplate
bindingKey="0EF96000-B4FC-11D5-84EB-AAA81F9305C3"
serviceKey="0E0D5250-B4FC-11D5-84EB-AAA81F9305C3">
<accessPoint URLType="http">
http://demohost:8080/soap/servlet/rpcrouter
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey=
"UUID:0C0F1150-B4FC-11D5-84EB-AAA81F9305C3"/>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference
keyName="UNSPSC" keyValue="901215"
tModelKey=
"UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384"/>
</categoryBag>
</businessService>
</businessServices>
<categoryBag>
<keyedReference keyName="NAICS" keyValue="56151"
ModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"/>
</categoryBag>
</businessEntity>
Listing 13.13 is an example of a tModel for our travel reservation. Its key is specified by the tModelKey attribute of the tModel element and is referred to by the tModelKey attribute of the tModelInstanceInfo element in Listing 13.12. The tModel is metadata for the actual description梐 WSDL document, in our example. The overviewURL element specifies the WSDL document, and the categoryBag element specifies that its format is WSDL. Listing 13.13 UDDI data: tModel
<tModel authorizedName="nakamury1"
operator="kbaba2.trl.ibm.com:80/services/uddi"
tModelKey="UUID:0C0F1150-B4FC-11D5-84EB-AAA81F9305C3">
<name>
XMLBOOK2 Travel Reservation Service Interface Definition
</name>
<description xml:lang="en">
This tModel defines the service interface definition
for travel reservation
</description>
<overviewDoc>
<overviewURL>
http://demohost:8080/soap/wsdl/travel-iface.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="uddi-org:types"
keyValue="wsdlSpec"
tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"/>
</categoryBag>
</tModel>
So far we have seen four key constructs of UDDI: business entity, business service, binding template, and tModel. UDDI defines operations on the constructs to provide publish and find operations, shown in Figure 13.1. Four operation types are defined as follows:
These operation types can be combined with the constructs we described to define a complete set of operations梩hat is, find_business, save_tModel, delete_service, and so on. Also, note that the actual operation is represented in XML and is transmitted over SOAP. 13.3.2 Programming with UDDI4JHere, we develop a program to access the UDDI registry with UDDI for Java. Like WSDL4J, UDDI4J is an open source project, so you can find the source code at IBM developerWorks. First we show how to access the UDDI registry and then show the program. Accessing the UDDI RegistryMultiple public UDDI registries exist on the Internet, including those from IBM, Microsoft, and HP. Here we explain how to access one of them. With a Web browser, access the IBM Test Registry at http://www.ibm.com/services/uddi/testregistry/protect/registry.html. You will see a home page as shown in Figure 13.9. Then go to "Search UDDI Business Test Registry" in the lower-right portion of the screen. On the page "IBM UDDI Inquiry," specify "S" in the "Starting with" field, which gives you businesses that start with "S," as shown in Figure 13.10. Figure 13.9. IBM UDDI Test Registry
Figure 13.10. Business entities found at the Test Registry
We can perform the same operation with a Java client. In other words, we can send a SOAP message that includes an XML document for a find operation. Listing 13.14 shows such a SOAP message. With SOAPHttpRequestor, developed in Chapter 12, you can issue the find command as follows:[8]
R:\samples>java chap12.travel.requestor.SOAPHttpRequestor
chap13\uddi\uddi-find.xml
http://www.ibm.com/services/uddi/servlet/uddi
Listing 13.14 SOAP message for finding a business
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
<SOAP-ENV:Body>
<find_business generic="1.0" xmlns="urn:uddi-org:api" >
<name>S</name>
</find_business>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Unlike find operations, update operations, such as save and delete, require user registration in advance. Go to "First Time?" at the middle-right of the screen shown in Figure 13.9, and you will be navigated to register your ID and set up a password. (You need to keep a record of your ID and password.) Alternatively, you can install the IBM UDDI Registry server included on the CD-ROM. We encourage you to install it because accessing a public registry may cause some problems. First, you may have to set up a proxy for invoking the program shown later. Second, SSL settings can be difficult. Finally, public registries can be down. The UDDIClient ProgramThe design concept for UDDI4J is similar to WSDL4J; that is, it provides Java classes that correspond to UDDI constructs. With these classes, you can perform find, get, save, and delete operations on UDDI constructs. Here we develop a program with UDDI4J called UDDIClient. It constructs UDDI data, as in Listings 13.12 and 13.13, saves it to the UDDI registry, searches for information, and deletes it. Listing 13.15 shows the top-level functions of UDDIClient. As you can see in the main method, you can perform one of three operations by specifying an option (-create, -search, and -clear). Listing 13.15 A portion of UDDIClient.java (main() method, member variables, and constructor)
public class UDDIClient {
private UDDIProxy proxy;
private String userid;
private String password;
private static final String DUMMY_XML =
"<d:Dummy xmlns:d=\"http://example.com//dummy\">\n" +
"</d:Dummy>\n";
public static void main (String args[]) {
if (args[0].equals("-search") && args.length == 3) {
UDDIClient app = new UDDIClient(args[1], args[2]);
app.search();
} else if ((args[0].equals("-create")||
args[0].equals("-clear")) &&
args.length == 5) {
// for updating, ssl setup is required
System.setProperty(
"java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
java.security.Security.addProvider(
new com.sun.net.ssl.internal.ssl.Provider());
// main processing start here
UDDIClient app = new UDDIClient(args[1], args[2]);
app.setAuthInfo(args[3], args[4]);
if (args[0].equals("-create")) {
app.create();
System.out.println("Created successfully!!");
} else if (args[0].equals("-clear")) {
app.clear();
System.out.println("Cleared successfully!!");
}
} else {
System.out.println("Wrong parameters");
}
}
public UDDIClient(String inquiryURL, String publishURL){
proxy = new UDDIProxy();
try {
proxy.setInquiryURL(inquiryURL);
proxy.setPublishURL(publishURL);
} catch (Exception e) {
e.printStackTrace();
}
}
public void setAuthInfo(String userid, String password) {
this.userid = userid;
this.password = password;
}
This class defines three member variables. The proxy variable refers to a UDDIProxy object that is used for accessing a UDDI registry and provides utility methods such as find_Business and save_tModel. The userid and password variables are required for performing update operations, such as save and delete. They are set up by the setAuthInfo method. Note that you have to register an ID with the UDDI registry in advance. The constructor takes two parameters because a UDDI registry ordinarily provides two different URLs for search and update. In the main method, the search, create, or clear method is invoked, according to the option given. Because create and clear are required for access via SSL and HTTP Basic Authentication (see Chapter 14 for more details), the code for such secure access is embedded. Next, we look at each method (create, search, and clear) in turn. Listing 13.16 shows the create method with which the UDDI data in Listings 13.12 and 13.13 is registered in the UDDI registry. We prepare four creation methods for businessEntity, businessServices, bindingTemplates, and tModel, and they are invoked in the create method. When creating bindingTemplates, you need a key of a tModel. Therefore, in the method, we invoke createTModel first. Note that UDDIProxy.getAuthToken() returns a token that is required when you invoke update operations. Listing 13.16 Method for registering information
public void create() {
try {
AuthToken token = proxy.get_authToken(userid, password);
TModelDetail td = createTModel(token);
BusinessDetail bd = createBusiness(token);
ServiceDetail sd = createService(token, bd);
BindingDetail bndDetail = createBinding(token, sd, td);
} catch (UDDIException e) {
DispositionReport dr = e.getDispositionReport();
if (dr!=null) {
System.out.println(
"UDDIException faultCode:" + e.getFaultCode() +
"\n operator:" + dr.getOperator() +
"\n generic:" + dr.getGeneric() +
"\n errno:" + dr.getErrno() +
"\n errCode:" + dr.getErrCode() +
"\n errInfoText:" + dr.getErrInfoText());
}
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
}
Listing 13.17 shows createTModel. Within the method, we first create a TModel object, set properties on it, and register it by invoking UDDIProxy.save_tModel(). You can specify a key of the tModel with the first parameter of the TModel constructor. As shown in the code, when you specify an empty string (""), the key is assigned by the UDDI registry. We create the OverviewDoc and OverviewURL objects to add the overviewDoc and overviewURL elements. As you can see from Listing 13.13, you can specify the location of a WSDL document. Although KeyedReference is obvious, note that you have to create a Vector object and add a KeyedReference object because categoryBag can contain more than one KeyedReference object. The return value here is almost the same as for tModels in the method. The key difference is that the TModel object is now assigned a key in UUID. Listing 13.17 Method for registering a tModel
public TModelDetail createTModel(AuthToken token)
throws Exception
{
TModel tmodel =
new TModel("",
"XMLBOOK2 Travel Reservation Service " +
"Interface Definition") ;
tmodel.setDefaultDescriptionString(
"This tModel defines the service interface definition "
+ "for travel reservation");
OverviewDoc ovDoc = new OverviewDoc();
ovDoc.setOverviewURL(
new OverviewURL(
"http://demohost:8080/"+
"xmlbook2/chap13/travel-rpc-iface.wsdl"));
tmodel.setOverviewDoc(ovDoc);
CategoryBag cBag = new CategoryBag();
Vector keyRefVector = new Vector();
KeyedReference keyRef =
new KeyedReference("uddi-org:types", "wsdlSpec");
keyRef.setTModelKey(
"UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4");
keyRefVector.addElement(keyRef);
cBag.setKeyedReferenceVector(keyRefVector);
tmodel.setCategoryBag(cBag);
Vector tModels = new Vector();
tModels.addElement(tmodel);
return proxy.save_tModel(
token.getAuthInfoString(),
tModels);
}
Listing 13.18 shows the createBusiness method. First, we create a BusinessEntity object and register it with UDDIProxy.save_business(). As in TModel, the constructor of BusinessEntity takes an empty string in its first parameter, and the UDDI registry assigns a key. Because save_business is intended for registering multiple businesses, we need to create a Vector object to add the business entity. Also, CategoryBag is created to specify "Travel agency," which is referred to as 56151 in the NAICS taxonomy. Listing 13.18 Method for registering a business entity
public BusinessDetail createBusiness(AuthToken token)
throws Exception
{
Vector entities = new Vector();
BusinessEntity be =
new BusinessEntity("", "XMLBook2 Travel Agency");
be.setDefaultDescriptionString(
"Wonderful travels to Hawaii and Neighbor Islands");
entities.addElement(be);
CategoryBag cBag = new CategoryBag();
Vector keyRefVector = new Vector();
KeyedReference keyRef =
new KeyedReference("NAICS", "56151");
keyRef.setTModelKey(
"UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2");
keyRefVector.addElement(keyRef);
cBag.setKeyedReferenceVector(keyRefVector);
be.setCategoryBag(cBag);
return proxy.save_business(token.getAuthInfoString(),
entities);
}
Listing 13.19 shows the createService method. Here we create a Business Service object, set up properties, and register it with the UDDI registry. Because BusinessService requires a key of the business entity, BusinessEntity.getBusinessKey() is invoked. CategoryBag is created to specify "Travel reservation service," which is referred to as 901215 in the UNSPSC taxonomy. Listing 13.19 Method for registering a business service
public ServiceDetail createService(AuthToken token,
BusinessDetail bd)
throws Exception
{
Vector businessEntities = bd.getBusinessEntityVector();
BusinessEntity be =
(BusinessEntity)(businessEntities.elementAt(0));
BusinessServices bSvcs=new BusinessServices() ;
Vector bsVector = new Vector();
BusinessService bSvc =
new BusinessService("",
"TravelReservationService",
new BindingTemplates());
bSvc.setBusinessKey(be.getBusinessKey());
bsVector.addElement(bSvc);
bSvcs.setBusinessServiceVector(bsVector);
CategoryBag cBag = new CategoryBag();
Vector keyRefVector = new Vector();
KeyedReference keyRef =
new KeyedReference("UNSPSC", "901215");
keyRef.setTModelKey(
"UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384");
keyRefVector.addElement(keyRef);
cBag.setKeyedReferenceVector(keyRefVector);
bSvc.setCategoryBag(cBag);
return proxy.save_service(token.getAuthInfoString(),
bsVector);
}
Listing 13.20 shows createBinding, where we create a BindingTemplate object, set properties, and register it with the UDDI registry. BindingTemplate requires the keys of the business service and the TModel, and they are extracted. AccessPoint is also created to specify the access point of the service. Listing 13.20 Method for registering a binding template
public BindingDetail createBinding(AuthToken token,
ServiceDetail sd,
TModelDetail tModelDetail)
throws Exception
{
BusinessService bSvc =
(BusinessService)
sd.getBusinessServiceVector().elementAt(0);
BindingTemplates bTmps = bSvc.getBindingTemplates();
BindingTemplate bTmp = new BindingTemplate("", null);
bTmp.setAccessPoint(
new AccessPoint(
"http://demohost:8080/soap/servlet/rpcrouter",
"http"));
bSvc =
(BusinessService)sd.
getBusinessServiceVector().elementAt(0);
bTmp.setServiceKey(bSvc.getServiceKey());
TModel tmodel =
(TModel)tModelDetail.getTModelVector().elementAt(0);
Vector tModelInfoVector = new Vector();
tModelInfoVector.addElement(
new TModelInstanceInfo(tmodel.getTModelKey()));
TModelInstanceDetails tModelDetails
= new TModelInstanceDetails();
tModelDetails.setTModelInstanceInfoVector(tModelInfoVector);
bTmp.setTModelInstanceDetails(tModelDetails);
Vector btVector = new Vector();
btVector.addElement(bTmp);
bTmps.setBindingTemplateVector(btVector);
return proxy.save_binding(token.getAuthInfoString(),
btVector);
}
You can execute the create method as follows:
R:\samples>java chap13.uddi.UDDIClient -create
http://demohost/services/uddi/servlet/uddi
http://demohost/services/uddi/servlet/uddi
userid password
Listing 13.21 shows the search method, which finds the information we have registered so far. We first find BusinessInfo by a business name, get its business, and finally get BusinessDetail. BusinessDetail is a container that can include all the information in Listing 13.12. Information on TModel can be found in the same manner, and the result is contained in TModelDetail. Listing 13.21 Method for searching business and tModel information
public void search() {
try {
BusinessList bizList =
proxy.find_business(
"XMLBook2 Travel Agency", null, 100);
BusinessInfos bizInfos = bizList.getBusinessInfos();
BusinessInfo bizInfo =
(BusinessInfo)
bizInfos.getBusinessInfoVector().elementAt(0);
BusinessDetail bd =
proxy.get_businessDetail(bizInfo.getBusinessKey());
System.out.println("---- Business Detail ----");
printDetail((UDDIElement)bd);
TModelList tmodelList =
proxy.find_tModel(
"XMLBOOK2 Travel Reservation Service "+
"Interface Definition",
null, 100);
TModelInfos tmodelInfos = tmodelList.getTModelInfos();
TModelInfo tmodelInfo =
(TModelInfo)
tmodelInfos.getTModelInfoVector().elementAt(0);
TModelDetail td =
proxy.get_tModelDetail(tmodelInfo.getTModelKey());
System.out.println("\n\n---- tModel Detail ----");
printDetail((UDDIElement)td);
} catch (UDDIException e) {
DispositionReport dr = e.getDispositionReport();
if (dr!=null) {
System.out.println(
"UDDIException faultCode:" + e.getFaultCode() +
"\n operator:" + dr.getOperator() +
"\n generic:" + dr.getGeneric() +
"\n errno:" + dr.getErrno() +
"\n errCode:" + dr.getErrCode() +
"\n errInfoText:" + dr.getErrInfoText());
}
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
}
You can search as follows:
R:\samples>java chap13.uddi.UDDIClient -search
http://demohost/services/uddi/servlet/uddi
http://demohost/services/uddi/servlet/uddi
Removal of the registered information can be performed with the clear method, as shown in Listing 13.22. As for both the business and the tModel, keys are retrieved by name, and we can delete entries with the keys by invoking UDDIProxy.delete_business and UDDIProxy.delete_tModel. Listing 13.22 Method for removing business and tModel information
public void clear() {
try {
AuthToken token =
proxy.get_authToken(userid, password);
BusinessList bizList =
proxy.find_business("XMLBook2 Travel Agency",
null, 100);
BusinessInfos bizInfos = bizList.getBusinessInfos();
Vector bizInfoVector =
bizInfos.getBusinessInfoVector();
Vector bizKeyVector = new Vector();
for(int i=0; i<bizInfoVector.size(); i++) {
BusinessInfo bizInfo =
(BusinessInfo)bizInfoVector.elementAt(i);
bizKeyVector.addElement(bizInfo.getBusinessKey());
}
proxy.delete_business(
token.getAuthInfoString(), bizKeyVector);
TModelList tmodelList =
proxy.find_tModel(
"XMLBOOK2 Travel Reservation Service"+
" Interface Definition", null, 100);
TModelInfos tmodelInfos = tmodelList.getTModelInfos();
Vector tmodelInfoVector =
tmodelInfos.getTModelInfoVector();
Vector tmodelKeyVector = new Vector();
for(int i=0; i<tmodelInfoVector.size(); i++) {
TModelInfo tmodelInfo =
(TModelInfo)tmodelInfoVector.elementAt(i);
tmodelKeyVector.addElement(
tmodelInfo.getTModelKey());
}
proxy.delete_tModel(
token.getAuthInfoString(), tmodelKeyVector);
} catch (UDDIException e) {
DispositionReport dr = e.getDispositionReport();
if (dr!=null) {
System.out.println(
"UDDIException faultCode:"
+ e.getFaultCode() +
"\n operator:" + dr.getOperator() +
"\n generic:" + dr.getGeneric() +
"\n errno:" + dr.getErrno() +
"\n errCode:" + dr.getErrCode() +
"\n errInfoText:" + dr.getErrInfoText());
}
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
}
You can delete the information as follows:
R:\samples>java chap13.uddi.UDDIClient -clear
http://demohost/services/uddi/servlet/uddi
http://demohost/services/uddi/servlet/uddi userid password
We have demonstrated programming with UDDI4J, showing how to register, search, and delete information in the UDDI registry. Further information can be found on the UDDI4J home page (http://www.uddi.org). 13.3.3 Registering WSDL with the UDDI RegistryHow can we register WSDL with the UDDI registry? UDDI aims at a generic means to publish and find information on services. This indicates that UDDI is independent of any particular protocols, such as SOAP, and any services description language, such as WSDL. Accordingly, there is no description of the registration of WSDL. Instead, we show an approach as a best practice. During the client stub generation in Section 13.2.4, we did not use the service section of the WSDL document. As you can see in Listing 13.6, the access point specified in WSDL (see Listing 13.4) is not embedded in the code. Rather, it is provided as a parameter of the constructor. The motivation here is that the service provider may want to change the URL address without changing contents of the service. Or other companies could provide the travel service in the exact same way, except by publishing through a different URL. On the basis of such a motivation, WSDL tends to be divided into two parts: interface and implementation. As we mentioned, the wsdlgen tool of WSTK generates two WSDL documents along this concept. Figure 13.11 illustrates the separation of WSDL documents. The service implementation contains the service section, and the service interface contains the remaining sections. There is an interesting question about this separation: Shouldn't we put the binding section in the service implementation? In some sense, this is reasonable because this section is specialized for a particular underlying protocol, such as SOAP and CORBA. At this moment, there is no specification to prescribe the separation. Rather, some activities implicitly assume the separation shown in Figure 13.11. One example is the WSDL tools in WSTK; another is the best practices document for UDDI. Figure 13.11. Separation of WSDL
Figure 13.12 shows how the interface and implementation parts of WSDL documents are integrated into UDDI. The implementation part refers to the interface part with the import element on the WSDL side. On the UDDI side, BindingTemplate refers to TModel with the tModel key, as in the UDDI specification. Figure 13.12. Relationship between UDDI and WSDL
In the best practices document, the location of the service interface is represented as a URL, and overviewURL in the tModel can specify the location. Also, the access point of the service is specified in the accessPoint element in the binding template. With these instructions, we can provide the minimum information to invoke the service. However, there is no documented instruction on how to register the service implementation with the UDDI registry. One idea is to specify the location URL of the implementation in the tModelInstanceInfo element of the binding template. You can find such a convention when looking at entries in the IBM UDDI Registry. However, there is no agreement on this approach. For now, we encourage you to use accessPoint only. |
| [ directory ] |
|