The classification scheme allows like business entities to group together such that a service consumer can easily find all similar companies that provide services in the same area.

Given the familiarity of North American Industry Classification System (NAICS) in the financial industry, FITSO decides to recommend the NAICS classification scheme to classify the business entities behind the pension services. This taxonomy choice translates to using the NAICS tModel pre-loaded in the UDDI registry.

However, simply relating business entities to the NAICS classification scheme is not enough — that relation simply denotes the type of classification scheme to be used. Each business entity that uses the NAICS classification scheme should also register with the specific classification code as described by the NAICS specification. Accordingly, FITSO recommends companies handling pension funds be classified under the category “Pension fund, third party administrative services.” Grouping business entities and their services under this classification gives service consumers a predictable mechanism to discover all pension fund entities and their services.

Standardization at the business classification level is just one aspect to consider. FITSO has also decided to standardize on basic interactions as well. Service consumers would be able to develop applications that interact with the services; the vision is that applications designed to work with one service would easily interchange with another. Based on the types of interactions that are simple enough to standardize, FITSO designed a set of service interfaces for the pension fund services. For this example, we focus on the 401(k) information services specification. The functions that should be supported by a FITSO pension fund are as follows:

Recall that the service interaction specification translates into a tModel in the UDDI paradigm with a pointer to the appropriate Web Services Description Language (WSDL) document. In Section 8.3, we explain how FITSO registers the resultant tModel — TM401(k) — within the UDDI registry. This tModel represents the aforementioned interactions.

Prudentially 401(k), Inc. is a subsidiary of a global financial services conglomerate that specializes in providing pension fund management services to its clients. The company has established a large clientele through the years and it is one of the founding members of the FITSO organization.

Being one of FITSO’s most influential members, Prudentially 401(k), Inc. was naturally one of the first pension fund providers to apply for the new compliance. To be a FITSO-compliant pension fund service provider, FITSO mandates that all pension fund services embark on providing Pension Fund Web services that are registered in the stated categories and abide by the FITSO service interaction specification. In order to achieve compliance, the business planner within Prudentially 401(k), Inc. determined that the business entity and the services needed to be modeled as described in Table 8.1.

In the next three sections, we explain the mechanics behind making these modeling decisions a reality within the UDDI registry.

Refer to Chapter 7 and Appendix D for how to set up the UDDI .NET SDK packages and configure them for use. As in Chapter 7, it is important to specify the entry point URL of the registry in question.

publishURL.Items.Add("https://uddi.rte.microsoft.com/publish"); 

Recall that publish activities require user name and password for authentication and the resulting authentication token. The user name and password information is used from the file app.config as explained in Chapter 7.

Publish.AuthenticationMode = 
   AuthenticationMode.UddiAuthentication; 
Publish.Url = publishURL.Text; 
Publish.User = 
   ConfigurationSettings.AppSettings["uddiUserName"]; 
Publish.Password = 
   ConfigurationSettings.AppSettings["uddiPassword"]; 

The UDDI .NET API for registering a business entity is the SaveBusiness. Using this object and its methods, a business entity structure is populated. As seen in the following code, attributes including Names, Descriptions, DiscoveryUrls, and Contact are populated to build the business entity object. For the purpose of this example, all these attributes are populated through user input in the corresponding text boxes.

 SaveBusiness sb = new SaveBusiness(); 

// Add business information 
sb.BusinessEntities.Add(); 
sb.BusinessEntities[0].Names.Add("en", businessNameBox.Text); 
sb.BusinessEntities[0].Descriptions.Add 
   ("en", descriptionTextBox.Text); 
sb.BusinessEntities[0].DiscoveryUrls.Add 
   (URLTextBox.Text, "http"); 

//Add contact 
Contact c = new Contact(contactNameBox.Text, "Contact"); 
c.Phones.Add(contactPhoneBox.Text, ""); 
sb.BusinessEntities[0].Contacts.Add(c); 

For the human-readable description associated with any attribute, the UDDI specification allows one description per language code. The applicable language codes are defined by the Internet Engineering Task Force (IETF) standard known as Request For Comment (RFC) 1766. This code can consist of one or more parts — a primary language code and a (possibly empty) series of sub-tags for country or dialect identification. The specification for the language codes can be found at http://www.ietf.org/rfc/rfc1766.txt. This example uses the code en that denotes the English language. Chapter 10 discusses the internationalization issues where language codes can play an important role. The language tag is optional in a description and the UDDI registry operator can decide a default language code to attach in such a case.

The discovery Uniform Resource Locator (URL) associated with an entity must conform to the URL format. Each URL must be associated with its type. Table 8.2 provides a quick summary of the types supported by the UDDI specification. In this example, the URL type is assumed to be http.

Prudentially 401(k), Inc. needs to classify itself under the NAICS taxonomy and the Pension Fund classification code, 524292, because of the FITSO specification. For each classification, three data elements are required — the tModel key that is associated with the classification scheme, the key name under which the entity is classified, and the value or code associated with the key. A data structure keyedReference holds these three elements together. The UDDI specification provides another data structure categoryBag, where multiple such classifications for a given entity can be specified. For registration of the Prudentially 401(k), Inc. business entity the following values must be used:

The reference key, in this case, refers to the NAICS tModel, pre-loaded on a UDDI registry. The code for pension funds and the precise description string is provided in the NAICS specification. The Web site http://www.naics.com provides Web-based tools for searching the codes for other industries.

//Add taxonomy tModel 
KeyedReference kr = new KeyedReference(); 
kr.TModelKey = tModelUUIDBox.Text; 
kr.KeyName = classificationNameBox.Text; 
kr.KeyValue = classificationNumberBox.Text; 
sb.BusinessEntities[0].CategoryBag.Add(kr); 

Although, not used in this example, a business entity should also specify the set of identifiers, such as DUNS identifiers, that can uniquely identify the entity. Even though providing these identifiers is optional, they help in precision of a discovered entity. Like the classification scheme, the UDDI specification does not mandate any identification scheme. However, the DUNS identification system as well as the Thomas Register Supplier Code System are pre-loaded in a UDDI registry. The UDDI Programmer’s Reference Guide provides more detail on these as well as the associated tModels. The process for specifying an identifier is similar to the one for categories. The data structure identifierBag is used to hold the keyedReference elements with specific identifiers.

Finally, the business entity is published using the Send method. As discussed previously, the interaction with a UDDI registry happens through XML messages over the HTTP protocol. The Send method is responsible for this interaction. The exact XML message can be viewed through the ToString method of the SaveBusiness class.

appendToMessageWindow(sb.ToString()); 
BusinessDetail bd = sb.Send(); 

After the UDDI registry receives and processes the XML messages created by the UDDI .NET APIs, a UUID key is returned. This key is a unique identifier associated with the business entity that was registered. The response from the registry is also in XML format. Upon successful business entity registration, the response message can be parsed to display information pertaining to the registration such as the assigned key and the UDDI operator that manages the registration.

AppendToMessageWindow 
   ("

Operator:"+bd.BusinessEntities[0].Operator); 
appendToMessageWindow("
Assigned Business key:"+ 
   bd.BusinessEntities[0].BusinessKey); 

The .NET example, RegisterBusinessForm.exe, uses a windows-based information entry design. However, all the business entity registration information pertaining to Prudentially 401(k), Inc.’s registration could have just as easily been placed in a property file. The application could then have been designed to be a console application that used a property file rather than manual data entry. The Java examples are written in the console-style with property file information.

Run the RegisterBusiness.exe application and then proceed to enter the information required to register the business. Recall that the business entity model (and taxonomy model) is populated with this information. Figure 8.1 depicts the information mandated by FITSO-compliant pension service providers regarding classification of the business entity.

Figure 8.1. Business entity registration for Prudentially 401(k), Inc.

After you have entered information in all three tabs, click on Register Business. Figure 8.2 depicts the successful results of registering the Prudentially 401(k), Inc. business entity.

Figure 8.2. Successful registration of Prudentially 401(k), Inc. business entity.

We discuss the associated XML messages that were sent to the UDDI registry to carry out the business entity registration during the UDDI4J discussion.

The RegisterBusiness.java contains the application logic to register the Prudentially 401(k), Inc. business entity using the UDDI4J APIs. All the registration information is located in the property file, Prudentially401kInc.prop.

BusinessName=Prudentially401(k), Inc. 
DiscoveryURL=http://www.insidewebservices.com/Prudentially401k 
Description=Prudentially401k, Inc. is known for outstanding 
   service to its customers for their 401(k) needs. 
ContactName=John Doe 
ContactPhone=212-555-1212 
# Contact email could be added in a way similar to contact 
# phone. 
# ContactEmail= 

# Taxonomy to classify. A business entity can be classified 
#in several taxonomies at the same time. 

# NAICS (1997) 
TModelKey=uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2 
ClassificationName=Pension fund, third party administrative 
   services 
ClassificationNumber=524292 

The first steps to publishing business entity information with the UDDI registry remain similar to the .NET discussion. We need to specify the publish URL as well as obtain an authentication token via the user name and password.

proxy.setInquiryURL(p.getProperty("inquiryURL")); 
proxy.setPublishURL(p.getProperty("publishURL")); 

AuthToken token = proxy.get_authToken(p.getProperty("userid"), 
   p.getProperty("password")); 

Now we need to construct the business entity object using the properties in the property file and the UDDI4J APIs. As before, we populate the object with business entity details such as name, contact, and discovery URL, but we also need to classify the business entity. Note that the BusinessEntity object is instantiated with null key. This is a trigger for the UDDI registry to treat this as a new registration and assign a key. If a key is provided, the transaction is treated as an update of an existing entity associated with the specified key.

BusinessEntity be = new BusinessEntity("", businessName); 
be.setDiscoveryURLs(new DiscoveryURLs 
   (createBusinessURLVector(bep, "DiscoveryURL"))); 
be.setDescriptionVector(createDescriptionVector 
   (bep, "Description")); 
Contacts cs = new Contacts(); 
cs.setContactVector(createContactVector(bep)); 
be.setContacts(cs); 

The classification information is located in the property file and is based on the FITSO classification scheme. A CategoryBag object is used to store the classification information. Notice that this object, similar to the .NET objects, holds a collection of keyedReference objects.

CategoryBag cb = new CategoryBag(); 
cb.setKeyedReferenceVector(createCategoryVector(bep)); 
be.setCategoryBag(cb); 

Finally, the proxy.save_business API registers the business entity object in the UDDI registry. Successful registration results in a business key being assigned by the registry to the business entity. This information as well as the responsible operator name can be extracted from the response message.

entities.add(be); 

BusinessDetail bd = 
   proxy.save_business(token.getAuthInfoString(),entities); 
Vector businessEntities = bd.getBusinessEntityVector(); 
BusinessEntity returnedBusinessEntity = 
   (BusinessEntity)(businessEntities.elementAt(0)); 
System.out.println("

Registry-assigned Business Key : " + 
   returnedBusinessEntity.getBusinessKey()); 

To run the Java example for registering the business entity, use the command following:

c:>java RegisterBusiness Prudentially401k.prop 

When the application is successful, the business key is returned.

Registry-assigned Business Key: 
   954eb479-cdbd-445b-b7a2-de33625ac015 

The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for publishing a business entity to the UDDI registry are as follows.

Request body: 
<save_business generic="2.0" xmlns="urn:uddi-org:api_v2"> 
  <authInfo>...</authInfo> 
  <businessEntity businessKey=""> 
    <discoveryURLs> 
      <discoveryURL useType=""> 
         http://www.insidewebservices.com/Prudentially401k 
      </discoveryURL> 
    </discoveryURLs> 
    <name>Prudentially401k, Inc.</name> 
    <description>Prudentially401(k), Inc. is known for outstanding 
       service to its customers for their 401(k) needs. 
    </description> 
    <contacts> 
      <contact> 
        <personName>John Doe</personName> 
        <phone>212-555-1212</phone> 
      </contact> 
    </contacts> 
    <categoryBag> 
      <keyedReference keyName="Pension fund, third party 
         administrative services" keyValue="524292" 
         tModelKey="uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"/> 
    </categoryBag> 
  </businessEntity> 
</save_business> 

Response body: 
<businessDetail generic="2.0" operator="Microsoft Corporation" 
   truncated="false" xmlns="urn:uddi-org:api_v2"> 
  <businessEntity authorizedName="Inside Webservices" 
     businessKey="954eb479-cdbd-445b-b7a2-de33625ac015" 
     operator="Microsoft Corporation"> 
    ... 
    ... 
  </businessEntity> 
</businessDetail> 

Notice that the businessKey tag in the request message is empty, signifying a new registration. The response message contains the assigned key. This message also has an attribute authorizedName that signifies the owning account that sent the registration message.

The file RegisterTModelForm.cs contains the application logic to register the FITSO tModel with the UDDI registry. A look at the code shows that the main API is the SaveTModel class. This class is used for registering (and modifying) a tModel. As with the business entity class, described in Section 8.2, the tModel object model needs to be populated before being saved in the UDDI registry.

SaveTModel stm = new SaveTModel(); 

stm.TModels.Add(); 
stm.TModels[0].Name = tModelNameBox.Text; 
stm.TModels[0].Descriptions.Add 
   ("en", descriptionTextBox.Text); 
stm.TModels[0].OverviewDoc.OverviewURL = 
   overviewDocTextBox.Text; 

//Add category bag conditionally 
if (tModelUUIDBox.Text != "") 
{ 
stm.TModels[0].CategoryBag.Add(); 
stm.TModels[0].CategoryBag[0].TModelKey = 
   tModelUUIDBox.Text; 
stm.TModels[0].CategoryBag[0].KeyName = 
   classificationNameBox.Text; 
stm.TModels[0].CategoryBag[0].KeyValue = 
   classificationValueBox.Text; 
} 
appendToMessageWindow(stm.ToString()); 
TModelDetail tmd = stm.Send(); 

The data elements associated with tModel registration are similar to that with a business entity registration — such as name, description, and category. The data structures are also similar to those associated with business entity registration. We can access the returned tModel key as follows:

appendToMessageWindow("
Registry-assigned tModel Key: " + 
   tmd.TModels[0].TModelKey); 

The tModelKey is a unique identification key that is generated by the UDDI registry when a tModel object is registered successfully. As before, the generated UDDI XML messages are depicted in the UDDI4J discussion.

Run the RegisterTModelForm.exe and enter the values pertaining to the tModel you are registering. In our example, we continue with FITSO’s tModel registration and register the tModel for FITSO compliant services to use. Figure 8.3 depicts the process, as well as the resulting tModelkey.

Figure 8.3. Registration of FITSO tModel for 401(k) information services.

The fact that we saw the tModelKey is evidence of successful registration; however, you may also visit the UDDI Web site and ensure visually that the tModel is successfully registered.

The file RegisterTModel.java contains the application logic to register the FITSO tModel with the UDDI registry using the UDDI4J APIs. Notice again that the main API for registering the tModel with the UDDI registry is the save_tModel method of the UDDIProxy class. This method is used for registering (and modifying) a tModel with the registry.

As described in Section 8.2, the related tModel object needs to be populated before being saved in the UDDI registry. The TM401k.prop file contains the properties for the tModel to be registered. These properties are used to populate the tModel object.

Vector tModels = new Vector(); 
TModel tModel = new TModel("", TMp.getProperty("TMName")); 

tModel.setDefaultDescriptionString 
   (TMp.getProperty("TMDescription")); 
OverviewDoc od = new OverviewDoc(); 
od.setOverviewURL(TMp.getProperty("TMOverviewDoc")); 
tModel.setOverviewDoc(od); 

CategoryBag cb = new CategoryBag(); 
cb.setKeyedReferenceVector(createCategoryVector(TMp)); 
tModel.setCategoryBag(cb); 
TModelDetail tModelDetail = 
   proxy.save_tModel(token.getAuthInfoString(), tModels); 

Vector tModelVector = tModelDetail.getTModelVector(); 
TModel tModelReturned = (TModel)(tModelVector.elementAt(0)); 
System.out.println("

Registry-assigned tModel Key : " + 
   tModelReturned.getTModelKey()); 

To run the Java example for registering a tModel, use the following command:

c:>java RegisterTModel TM401k.prop 

The registry-assigned tModel key will be displayed upon successful execution of the program.

Request body: 
<save_tModel generic="2.0" xmlns="urn:uddi-org:api_v2"> 
  <authInfo>...</authInfo> 
  <tModel tModelKey=""> 
    <name>TM401k</name> 
    <description> 
       tModel defined by FITSO for 401(k) interactions 
    </description> 
    <overviewDoc> 
      <overviewURL> 
         http://www.insideWebServices/FITSO/TM401k.wsdl 
      </overviewURL> 
    </overviewDoc> 
    <categoryBag> 
      <keyedReference keyName="KEYWORD" keyValue="401(k)" 
        tModelKey="uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4"/> 
      </categoryBag> 
  </tModel> 
</save_tModel> 

Response body: 
<tModelDetail generic="2.0" operator="Microsoft Corporation" 
   truncated="false" xmlns="urn:uddi-org:api_v2"> 
  <tModel authorizedName="Inside Webservices" 
     operator="Microsoft Corporation" 
     tModelKey="uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549"> 
  ... 
  </tModel> 
</tModelDetail> 

Registry-assigned tModel Key: 
   uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549 

An authenticated application (i.e., possessing an authentication token) needs to publish service information through the publish URL. Following a similar pattern, the main API for publishing a service to the UDDI registry is SaveService using the UDDI .NET SDK. Using the SaveService class methods, the service object needs to be populated with the service details. One additional service detail to note is the field BusinessKey. The BusinessKey links the service to the responsible or publishing business entity. In this case, we link the P401Kservice to the Prundentially401(k), Inc. business entity. Hence, the BusinessKey returned when the business entity was registered should be stored. This key will also be required in establishing relationships with other business entities as we discuss in the Publisher Assertions section of Chapter 6.

SaveService ss = new SaveService(); 
ss.BusinessServices.Add(); 
ss.BusinessServices[0].Names.Add("en", serviceNameBox.Text); 
ss.BusinessServices[0].Descriptions.Add 
   ("en", descriptionTextBox.Text); 
ss.BusinessServices[0].BusinessKey = 
   parentBusinessKeyBox.Text; 

As part of registering a service, it is also important to register the service entry point and the service interface specification that the service complies with. Publishing the service entry point allows service consumers to directly access the service after discovery. Prudentially401(k)’s service complies with FITSO’s tModel (registered in the previous section). Populating the service object with this information is accomplished by providing information to another class, bindingTemplate, as part of the service object.

The bindingTemplate stores the technical fingerprint of the tModel that the service complies with. Recall that FITSO received a tModel key when it registered the service interaction specification. This key needs to be shared between the interaction specification publisher and all complying services. The following code exemplifies how to populate the binding template. The class TmodelInstanceInfo holds information about a tModel that the service complies with. Just like the taxonomies, several tModels can be complied with, by a service.

BindingTemplate bt = new BindingTemplate(); 
bt.AccessPoint = new 
   AccessPoint(Microsoft.Uddi.Api.URLType.Http, 
      accessPointBox.Text); 
TModelInstanceInfo tmii = new TModelInstanceInfo(); 
tmii.TModelKey = complianceTModelBox.Text; 
bt.TModelInstanceDetail.TModelInstanceInfos.Add(tmii); 
ss.BusinessServices[0].BindingTemplates.Add(bt); 

Similar to registering a business entity, it is also important to classify the service in the same fashion that we further classified the business entity, i.e.,for ease of use. This service is further classified under general_keywords taxonomy. This is a preloaded tModel that is available in the UDDI registry. It allows you to associate a keyword with your service. Upon publishing, we link this service to the keyword 401k. The process is very similar to what we did when we registered the business entity. The classification name used in the example is KEYWORD and the value associated with it is 401k.

KeyedReference kr = new KeyedReference(); 
kr.TModelKey = tModelUUIDBox.Text; 
kr.KeyName = classificationNameBox.Text; 
kr.KeyValue = classificationValueBox.Text; 
ss.BusinessServices[0].CategoryBag.Add(kr); 

Finally, the returned ServiceKey is displayed. As is the case with other unique identifiers, it is good practice to store this information. It could be used in the future, for example, in Chapter 10, we see how it is used for reference caching.

appendToMessageWindow("
Regisry-assigned Service key:"+ 
   sd.BusinessServices[0].ServiceKey); 

In the final example in this chapter, RegisterBusiness.exe, we enter the details that are required to register the service. The notable difference in publishing a service as compared to the other resources is the binding information. In Figure 8.4 we show the information required to publish the P401kService in the UDDI registry. Note the compliance tModel Key. This is the tModel key for the FITSO service interaction specification registered previously. The access point is also denoted in this example.

Figure 8.4. Binding information for service.

The Taxonomy tab contains the general_keyword taxonomy information that will allow the service to be discovered using the 401k keyword. Finally, the Service Details tab contains basic service information and the business key information, which links the service, its responsible business entity. Thus, when a service consumer discovers the service, it can also review the responsible business entity to learn more about the entity providing the discovered service. Figure 8.5 depicts the successful execution of this application.

Figure 8.5. Successful service publication.

Notice that a service key is returned in this case as well. The UDDI registry returns any errors in the execution; these are displayed in the text box. Appendix C contains information about errors and some basic troubleshooting techniques for the UDDI registry.

The UDDI4J APIs for publishing a service to the UDDI registry are very similar to the UDDI .NET SDK APIs. The procedure to publish a service using the UDDI4J APIs requires a similar service object to be populated with the service details, binding information, and taxonomy details. As is the case with other UDDI4J examples, a property file contains the specifics on the service to be published. In this case, Prudentially401(k), Inc. publishes a service with the property file P401kService.prop.

As is the case with the UDDI .NET SDK example, the BindingTemplate needs to be populated with the service access point as well as the appropriate tModel. The code below builds the BindingTemplate object.

public static Vector createBindingTemplateVector(Properties p) 
{ 
Vector resultVector = new Vector(); 
BindingTemplate bt = new BindingTemplate(); 
bt.setAccessPoint(new 
   AccessPoint(p.getProperty("AccessPoint"), "http")); 
bt.setBindingKey(""); 
TModelInstanceDetails tmid = new TModelInstanceDetails(); 
tmid.setTModelInstanceInfoVector 
   (createTModelInstanceInfoVector(p)); 
bt.setTModelInstanceDetails(tmid); 
resultVector.add(bt); 
return resultVector; 
} 

The CategoryBag needs to be populated with the classification scheme as well. From the property file, you will notice that this service is being further classified in the general_keyword taxonomy; this will allow it to be classified by keyword 401k as well.

public static Vector createCategoryVector(Properties p) 
{ 
Vector resultVector = new Vector(); 
KeyedReference kr = new 
   KeyedReference(p.getProperty 
   ("ClassificationName"), p.getProperty("ClassificationValue")); 
kr.setTModelKey(p.getProperty("CategoryTModelKey")); 
resultVector.add(kr); 
return resultVector; 
} 

Finally, the objects are put together to build the services object, which contains all the information required to publish the service. The UDDIProxy.save_service method publishes the service to the UDDI registry. Recall again that the authentication token is required for any publishing to the registry.

ServiceDetail sd = 
   proxy.save_service(token.getAuthInfoString(),services); 

A service key is returned to the application upon successful registration. However, it is also important to store the key as it may be used for subsequent transactions. In this case, we display the key for verification that the publish attempt was successful.

BusinessService bsReturned = 
   (BusinessService)(businessServices.elementAt(0)); 
String serviceKey = bsReturned.getServiceKey(); 
System.out.println("

Registry-assigned Service Key : " + 
   bsReturned.getServiceKey()); 

To run the Java example for publishing the P401kService, use the following command:

c:>java RegisterService P401kService.prop 

The XML request and response messages exchanged during the service registration process are as follows:

Request body: 
<save_service generic="2.0" xmlns="urn:uddi-org:api_v2"> 
  <authInfo>...</authInfo> 
  <businessService 
     businessKey="954eb479-cdbd-445b-b7a2-de33625ac015" 
        serviceKey=""> 
    <name>P401kServiceJava</name> 
    <description> 
     401(k) management service by Prudentially401(k), Inc. abiding 
      by the FITSO TM401k tModel 
    </description> 
    <bindingTemplates> 
      <bindingTemplate bindingKey=""> 
        <accessPoint URLType="http"> 
          http://www.insidewebservices.com/Prudentially401k/ 
             P401kService 
        </accessPoint> 
        <tModelInstanceDetails> 
          <tModelInstanceInfo 
            tModelKey="uuid:587a1d4f-d94e-4aa0-949c-
                cf527ed45328"/> 
        </tModelInstanceDetails> 
      </bindingTemplate> 
    </bindingTemplates> 
    <categoryBag> 
      <keyedReference keyName="KEYWORD" 
         keyValue="401(k)" 
          tModelKey="uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4"/> 
    </categoryBag> 
  </businessService> 
</save_service> 

Response body: 
<serviceDetail generic="2.0" operator="Microsoft Corporation" 
   truncated="false" xmlns="urn:uddi-org:api_v2"> 
  <businessService 
      businessKey="954eb479-cdbd-445b-b7a2-de33625ac015" 
      serviceKey="c33b39e7-7054-45f2-986e-413db139fb38"> 
    ... 
  </businessService> 
</serviceDetail> 

The Service Key that is returned should be stored locally. More importantly, the unique key is proof that the service was published successfully and that it is now ready for service consumers to discover it.

Registry-assigned Service Key: 
   c33b39e7-7054-45f2-986e-413db139fb38 

The class DeleteService handles deletion of a service. The chief piece of information required to delete a resource, such as the service, is its unique identifier key.

//Prepare the DeleteService object 
DeleteService ds = new DeleteService(); 
ds.ServiceKeys.Add(serviceKeyBox.Text); 

Once the DeleteService class is initialized, the delete request can be sent through the Send method. Unlike other APIs discussed so far, the deletion APIs return an XML message that generally provides information on any errors during the transaction. The class dispositionReport holds any such messages. Upon successful deletion, however, this class object returns a single message signaling successful execution. The success code as defined in the UDDI specification is E_success.

DispositionReport dr = ds.Send(); 

//Check if the service was successfully deleted 
if(dr.Results[0].ErrInfo.ErrCode.Equals("E_success")) 
{ 
   appendToMessageWindow("Service deleted successfully"); 
} 
else 
{ 
   appendToMessageWindow("Error in service deletion. 
      Error text follows ..."); 
   appendToMessageWindow(dr.Results[0].ToString()); 
} 

Run the program DeleteServiceForm.exe and enter the service key for the service that needs to be deleted after choosing the publish URL. Once the Delete Service button is clicked, the status of the request is shown in the text box at the bottom of the window. Figure 8.6 shows the successful deletion of a service.

Figure 8.6. Deleting a service.

UDDI4J also provides similar APIs for deleting a resource. Providing the authentication token and the identifier key is required to delete a resource from the UDDI registry. Typically, the UDDI4J APIs for deleting a resource take the form of delete_resource. The property file DeleteService.prop stores the identification key of the resource to be deleted. The code from the example below demonstrates the use of the delete_service API.

DispositionReport dr = 
   proxy.delete_service(token.getAuthInfoString(), 
   dsp.getProperty("ServiceKey")); 

Successful deletion of the resource returned by the registry.

Use the following command to run the Java example to delete a service:

c:>java DeleteService DeleteService.prop 

The UDDI XML messages that are generated by the UDDI4J APIs are very similar to the XML messages generated by the UDDI .NET SDK APIs. The following XML messages are generated for deleting a service from the UDDI registry.

Request body: 
<delete_service generic="2.0" xmlns="urn:uddi-org:api_v2"> 
  <authInfo>...</authInfo> 
  <serviceKey> 
     c33b39e7-7054-45f2-986e-413db139fb38 
  </serviceKey> 
</delete_service> 

Response body: 
<dispositionReport generic="2.0" operator="Microsoft Corporation" 
xmlns="urn:uddi-org:api_v2"> 
  <result errno="0"> 
    <errInfo errCode="E_success"/> 
  </result> 
</dispositionReport> 

If this deletes successfully, a confirmation note is displayed:

Service deleted successfully 

The containment principle, used for UDDI data structure design, defines how different resources are related to each other. For example, a business entity structure can have several service structures contained within it. In essence, containment defines the parent–child relationships between the resources and corresponding data structures.

As a design principle, no single instance of a core data structure is contained by more than one parent data structure. Thus, only a business entity structure will ever contain information about a specific service instance.

Although data structures for the UDDI resources can contain several data elements, not all of them are necessary to instantiate (register) a resource within the UDDI registry. In the examples in this chapter, we have used only a subset of the data elements to describe the resources such as business entities and services. Of course, some of the data elements are mandatory. The XML schema associated with the data structure provides information on which fields are optional and which are mandatory. For example, the business entity structure schema is as follows:

<element name = "businessEntity"> 
  <complexType> 
    <sequence> 
      <element ref = "discoveryURLs" minOccurs = "0"/> 
      <element ref = "name" maxOccurs = "unbounded"/> 
      <element ref = "description" minOccurs = "0" 
         maxOccurs = "unbounded"/> 
      <element ref = "contacts" minOccurs = "0"/> 
      <element ref = "businessServices" minOccurs = "0"/> 
      <element ref = "identifierBag" minOccurs = "0"/> 
      <element ref = "categoryBag" minOccurs = "0"/> 
    </sequence> 
    <attribute ref = "businessKey" use = "required"/> 
    <attribute ref = "operator"/> 
    <attribute ref = "authorizedName"> 
  </complexType> 
</element> 

As can be seen from the schema, the element Name is required to register a business entity, while description is optional. The UDDI Version 2.0 Data Structure Reference specifies the XML schemas for all the resources used in this chapter. During registration, the UDDI registry checks for the data sufficiency for a resource being registered.

In the next chapter, we discuss inquiry APIs in detail.