Wrox Press
ASPToday
       955 Articles
  in the Solutions Library
  Log off
 
 
 
Web Developer's Conference  
 
ASPToday Subscriber's Article Chris Peiris
The UDDI Programming Model - designing an ASP.NET UDDI Browser
by Chris Peiris
Categories: .NET Framework, XML/Data Transfer
Article Rating: 4.5
Published on March 19, 2002
 
Content Related Links Discussion Comments Index Entries Downloads
 
Abstract
XML Web Services has been the toast of the .NET Framework, however, Web Services are not a .NET invention – they were available before .NET. So why are they so popular under .NET? Because the set of tools available under Microsoft .NET Framework lets the developer build sophisticated Web Services with little difficulty. Developers are embracing Web Services at an exponential rate under the .NET framework. With this popularity increase, UDDI is emerging as the preferred mechanism to discover the Web Services. This article is aimed at advanced users familiar with UDDI. You can now purchase this article for $5 as a PDF download here: http://www.pdf-download.com/default.asp?intappid=3&title=20020319&pdfid1
 
Article

UDDI Programming Model

XML Web Services has been the toast of the .NET Framework, however Web Services are not a .NET invention - they were available before .NET. So why are they so popular under .NET? Because the set of tools available under Microsoft .NET Framework lets the developer build sophisticated Web Services with little difficulty. Developers are embracing Web Services at an exponential rate under the .NET framework. With this popularity increase, UDDI is emerging as the preferred mechanism to discover the Web Services. This article is aimed at advanced users familiar with UDDI so I will be skipping the introductory lessons and dive into UDDI details from the start. In the second half of this article we will put our knowledge into use by building an ASP.NET UDDI browser using web forms.

For more information I recommend Professional C# Web Services: Building .NET Web Services with ASP .NET and .NET Remoting from Wrox Press as a great reference book that discusses UDDI in detail.

We will first explore the UDDI data structures, then we will investigate the UDDI API version 2.0, this is the most recent version of the UDDI API. The best place to find more technical details on UDDI is http://www.uddi.org/?WROXEMPTOKEN=637897ZofCyIQiiuL3IqHoE0UX.

UDDI API Data Structures

UDDI has 4 main data structures. All the information is stored as predefined XML formats. First we will try to understand the responsibilities of each structure. Then we will learn how these structures work together to create UDDI.

  • Business information ( businessEntity XML Format)
  • Service Information ( businessService XML Format)
  • Binding Information ( bindingTemplate XML Format)
  • Specifications for the services offered ( tModels XML Format)

businessEntity Data Structure

You only need a businessEntity element to publish data within a UDDI repository. The other data elements are optional. During the discovery phase, the businessEntity element serves as a handle to retrieve pertinent information about a company.

businessService Data Structure

Service information deals with technical and business descriptions. Each Web Service has one or more technical web descriptions. These technical descriptions include information to communicate with clients. Those could be:

  • URLs, addresses to communicate to child Web Services.
  • Configuration options on the host web server.
  • Prerequisite Web Services that should run before this Web Service.
  • Load Balancing information on the host web server.

bindingTemplate Data Structure

The information about invoking a Web Service is documented in a XML structure called bindingTemplate.. The bindingTemplate"binds" technical and business data to a Web Service. So what information do we bind? We need to know all the technical information for seamless integration of the Web Service. Here are some of those questions if we implement a Web Service to handle purchase orders.

  • We need to know the format of our purchase orders?
  • Are they in a specific XML format geared towards online transactions? (eg. OBI - Open Buying on Internet)
  • What are the required security implications to access purchase orders?

In order to integrate the Web Service we need to answer all these questions, therefore we need XML structures to represent this information inside the Web Service bindings. These structures are commonly referred to as "tModel".

tModel Data Structure

This is probably the most interesting data structure. UDDI draws a distinction between abstraction and implementation with its concept of tModels. The tModel structure, short for "Technology Model", represents technical fingerprints, interfaces and abstract types of metadata. Binding templates are the concrete implementation of one or more tModels. Inside a binding template, one registers the access point for a particular implementation of a tModel. tModels can be published separately from the binding templates that reference them.

Each tModel also gets a unique identifier, this will enable other applications to refer to it, these tModels make up bindingTemplate structures. The tModels represent all the integration information to consume a Web Service. The different service providers can easily build a software product to consume the Web Service as long as the tModels are compatible.

So how does all these data structures come together to create UDDI?

The Association of Data Structures

The following diagram - taken from the UDDI Technical Specification Ver 2.0 - explains how the data structures fit into each other.

Image 1

The process for discovery, lookup and invocation is as follows:

  • Use the UDDI repository to locate a businessEntity element for the appropriate business offering Web Services
  • Locate the businessService element to identify all the Web Services offered by a businessEntity. A business can have multiple business services.
  • Select a bindingTemplate element to retrieve the address of the Web Service and tModel element to ensure technical compatibility between the systems. A single business service could have multiple binding templates. A binding template could have multiple tModels associated with it.

The businessEntity will have one or many businessService instances. UDDI does allow the information contained in a businessService element to be classified further based on product, category, or a combination of both. As UDDI gets popular and the UDDI API version increases, I would assume these categorization options will expand.

A businessService element contains a bindingTemplate element that stores the technical description of the Web Service. The businessService element can contain other pertinent information such as routing options for undertaking load balancing or a description of the information needed before invoking a service.

In other words, the businessService element contains information about the Web Services being offered, but the bindingTemplate element contains the information required to invoke a Web Service.

If a bindingTemplate element was defined for a businessService element, then an accessPoint attribute would contain the address of the Web Service. Each bindingTemplate element must have a tModelInstanceDetails element that contains tModels, which are blueprints that can be used to identify compatibility between the requesting agent and the published service.

Note: These 4 are the main UDDI Data Structures. Here are some of the other data structures that are involved in the UDDI programming model. Please refer to the UDDI Data Structure specification for further details.

  • IdentifierBag XML Format
  • CategoryBag XML Format
  • tModelInstanceInfo XML Format
  • InstanceDetail XML Format
  • OverviewDoc XML Format

UDDI API interface

UDDI has an API to communicate with the registry. The UDDI API could be divided into 2 main sections.

  • Inquiry API
  • Publishers API

Both Inquiry and Publishing API calls are SOAP envelopes over HTTP that are basically Web Services calls. The Inquire API is used to read data from the UDDI registry. Thus does not need an authentication model. The Publishing API lets the publisher modify the UDDI registry.

Inquiry API

As the name suggest this API is used to query a UDDI registry. These method calls are synchronous HTTP-POST calls. These method calls are generally to do the following tasks.

  • Find businesses
  • Find details about the business and the services it offers.

There are no security implications for Inquire API in the UDDI 2.0 specification. This API is only to browse information in a "read only" fashion.

Inquire API Specification

The publicly available methods are:

Method Name Description
find_business To locate information about one or more business.
find_relatedBusinesses To locate subsidiaries, business units under a parent business. This is important to depict organization hierarchies and business partner relationships.
find_service To locate a service within a UDDI registered business.
find_tModel Finds one or more tModel structures
find_binding To locate a binding within a registered business.
get_bindingDetail To extract full binding template information in order to make service requests
get_businessDetail To extract all the businessEnitiy information
get_serviceDetail To get full details for a given registered service
get_tModelDetail To get full details of a tModel.

Publishing API

The Publishing API addresses the following issues on UDDI:

  • Register new business and services
  • Delete existing services of businesses.
  • Manage security on the business data. (UDDI registry specific)

The Publishing API needs an authentication model, which specified by the UDDI registry operator. It could be any of the following authentication methods.

  • Clear text user name and password
  • Cookie based authentication
  • Microsoft Passport Authentication

UDDI 2.0 specification does not recommend a security model. It only mentions to implement one. It is the responsibility of the registry's system admin.

Publishing API Specification

Here are the available method calls in Publishing API

Method Name Description
get_authToken: To retrieve an authentication token. This method call should be performed earlier to other API calls. Since Publishing API will alter the content of the UDDI registry we need to authenticate before we make any changes.
save_business Save a business data in the UDDI registry.
save_binding: Save binding information on a service.
save_service: Save information about a service
save_tModel: Save data about a tModel
delete_binding: Delete a specific binging
delete_business: Delete business information
delete_service: Delete Service information
delete_tModel: Delete tModel information.
get_registeredInfo: To get business and tModel data for a business

Benefits to the software industry from UDDI

So why is UDDI so important? How will the software industry benefit from UDDI? Lets take some practical applications of UDDI in the future. Here are some hypothetical case studies for UDDI.

Scenario I

Lets assume we bought a shrink wrapped software package that accepts order from the Internet. One of the strong points about buying the package is it's wide spread popularity. Our marketing department is confident that will create a common "order processing system" with our customers and suppliers.

We can use a public UDDI registry to advertise our new service (invoke Publish API in UDDI terms). Since this uses the same model, our suppliers can easily communicate with our system to alter data. In UDDI terms, the suppliers have the same tModels that binds to our end point. Since the system is sophisticated enough to do seamless integration we did not need to build new B2B system

When we install the new software, it automatically refers to a public UDDI directory and gets a list of compatible business partners (other traders with the same tModels). This will be another great opportunity to form new alliances.

Scenario II

Currently Microsoft is marketing its "Passport Authentication" model with great interest. Did you ever wonder why? Are you sick and tired of entering authentication details multiple times? A login is needed to read your mail and ten minutes after file server access requires the same authentication details. The answer to this question is "single login" mechanism. This means you login once. The tasks you associate afterwards carry the same security model. You guessed it right; MS Passport is one of those single logins. MS Passport will let you read Hotmail emails and seamlessly let you enter the Universal Subscription MSDN download site (assuming you have access to MSDN.)

Let's assume we are building a software package that requires registration of the product's users (for after-sales support procedures). Currently, after installing the system, we need to logon to a web page and enter all our company and personal details - this could be a pain. I have installed many programs over the years, but I simply skip the registration process every time. Naturally when the software malfunctions, I have to go through the whole registration process again. It will really beneficial if we can register all our details while installing the product.

If I can implement the MS Passport tModel, I will be able activate MS Passport authentication on my site. How will I get the tModel information? It is from the public UDDI directory. Microsoft can also build a subscription model to invoice me for the access of this service. I can just ask the passport authentication details (email address and password) in the installation process. The UDDI registry holder (Microsoft in the example) will be responsible for the security of the UDDI entries. Then my code will access an MS Passport Server and extract all the registration data. Therefore, the client does not need to type them in, they can just press a button and complete the registration process. The inconvenience of entering client data is addressed by this architecture.

UDDI exchange data in XML format, therefore, a Microsoft "online invoicing" tModel can seamlessly interact with a Java based "UNIX purchasing" tModel. There are no barriers with cross platform issues in UDDI - the onus is put on designing tModels wisely , the data between tModels is exchanged as predefined XML formats.

Current Available UDDI Registries

Operational UDDI Servers

Test UDDI Servers

Now we are familiar with UDDI and its API. Let's put this knowledge into use. In the following half of this article I will be guiding you through an ASP.NET UDDI Browser to access the Inquire API.

Further information on UDDI

Creating an ASP.NET UDDI Browser

I will now show you how build a UDDI Browser using C#. There are UDDI Browsers built to facilitate the public UDDI nodes (eg. http://udd.microsoft.com/?WROXEMPTOKEN=637897ZofCyIQiiuL3IqHoE0UX. The real value of UDDI resides in B2B integration systems, therefore businesses need to set up private UDDI registries and populate them with available Web Services. Then we need to build a mechanism to extract the data out of these private UDDI nodes.

Tools Available To Build UDDI Applications

We will be using the MS UDDI SDK for accessing UDDI API.

Microsoft UDDI SDK 1.76

MS UDDI SDK 1.76 is the latest version from Microsoft. This is targeted towards the released version of .NET Framework and currently does not come with a developer edition, therefore we will not be able to create a UDDI registry on our systems. This SDK implements version 1.0 of the UDDI specification, even though version 2.0 has been released by http://www.uddi,org/?WROXEMPTOKEN=637897ZofCyIQiiuL3IqHoE0UXwww.uddi.org most of the public nodes are still implementing version 1.0.

If you want to use a developer edition of UDDI SDK please download a version of UDDI SDK 1.52. This is only aimed at .NET Framework Beta 2. This does not work with the released version or released candidate. You will also need to have SQL Server 2000 installed on your machine. UDDI SDK 1.52 comes with SQL backend to store Web Services data, it also comes with a Web Service front end. This Web Service front end basically calls the "inquire API" of UDDI specification. A copy of UDDI SDK 1.52 can be found at http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/711/msdncompositedoc.xml&WROXEMPTOKEN=637897ZofCyIQiiuL3IqHoE0UX

We can access both the Inquire and Publish APIs under UDDI SDK 1.52. UDDI SDK 1.76 will only have access to the Inquire API (since there is no back end to store data, there is no Publish API.)

I will be using UDDI SDK 1.76 to guide you through this UDDI Browser implementation.

System Requirements for UDDI SDK 1.76

  • Microsoft® .NET Framework 1.0
  • Operation Systems
  • Microsoft Windows 2000 Professional with Service Pack 2.0
  • Microsoft Windows 2000 Server with Service Pack 2.0
  • Microsoft Windows 2000 Advanced Server with Service Pack 2.0
  • Microsoft Windows XP Professional
  • Microsoft Windows .NET Server Beta 3
  • Microsoft Windows .NET Advanced Server Beta 3
  • Visual Studio .NET released version for the IDE

How to explore MS UDDI SDK Capabilities?

MS UDDI SDK comes with Microsoft.UDDI.SDK.dll , this is there to make our life easier. This is also added to the Global Assembly Cache during the installation. Unfortunately there is no adequate documentation available for UDDI SDK 1.76. Therefore we need a method to 'look into' Microsoft.UDDI.SDK.dll. This is achieved by the "ILDASM" (.Net Intermediate Language Disassembler) tool in the .NET framework. Fire up ILDASM and load the Microsoft.Uddi.Sdk.dll into it and investigate the properties and methods.

Building the UDDI Web Browser in Visual Studio .NET

1) Start up Visual Studio from the programs menu and Click on File -> New Projects. Select Visual C# Projects from the Project Types pane. Select ASP.NET Application from the Templates pane.

2) Create the project on localhost. Name the project Wrox_UDDI_Browser.

3) Add the reference to the project. Select Microsoft.UDDI.SDK.dll assembly from the hard drive. The default location for the assembly will be at <drive letter>:\Program Files\Microsoft UDDI SDK\Microsoft.Uddi.Sdk.dll

For example, C:\Program Files\Microsoft UDDI SDK\Microsoft.Uddi.Sdk.dll

4) Create the web forms. Here is a description of each web form in the application.

File Name Description
Business_Search.aspx This web form will let you search by business name on a specified UDDI registry. This will be the start up ASPX page for our UDDI Browser project. The first step will let you select a UDDI Registry. I have included the currently available public UDDI nodes here. In a B2B environment it will have a list of internal UDDI nodes. You can perform the search in two ways. You can either type in the business name or do a general search starting with the business's first letter. This is to accommodate more flexibility into the application. When the user Clicks the "Search Business" button a data grid will appear with the search results. You can select a single business and navigate to the "Business.aspx" page to view the details.
Business.aspx This web form will display the business information and a list of Web Services available from it.
Service.aspx This web form will have all the details about a specific Web Service.
TModel_Search This web form is similar to "Business_Search.aspx". You will select the UDDI registry first, then have two choices. You can either search all the tModels a company implants (eg: - What are the tModels used by Microsoft?). Sometimes we may already know the unique identifier for the tModel (tModelKey) so the second option is to key in the tModelKey directly.
TModel.aspx All the tModel information is displayed on this web form

5) Compile the application and debug it.

Let's now try and understand the code in these files.

Business_Search.aspx

This page primarily uses the businessDetails data structure. We need to add the following code to get access to the UDDI namespace in the Business_Search.aspx.cs file.

using Microsoft.Uddi;

The Business_Search.aspx web form consists of the following items:

  • Drop down list box to select the UDDI registry
  • Text box to enter the business name and a drop down list box to select the first letter of the business name
  • A button to initiate the search

A user will select a UDDI registry first. Then he or she will enter the business name and click the search button. This will populate a data grid with the search results.

Here is the code to execute the search:

private void Btn_Search_Business_Click(object sender, System.EventArgs e)
{
       DataGrid_Business.Visible = true;
       DataGrid_Business.CurrentPageIndex = 0;
       DataGrid_Business.DataSource = CreateBusinessInfos();
       DataGrid_Business.DataBind();
}              
private ICollection CreateBusinessInfos()
{
       Inquire.Url = Lst_UDDI_Registry.SelectedItem.Value;
       FindBusiness BusinessEntities = new FindBusiness();
       BusinessEntities.MaxRows = 100;
       BusinessEntities.FindQualifiers.Add("sortByNameAsc");

       if(Txt_Business_Name.Text == "")
              BusinessEntities.Name = Lst_BusinessLetter.SelectedItem.Value;
       else
              BusinessEntities.Name = Txt_Business_Name.Text;
       BusinessList List = BusinessEntities.Send();
       return List.BusinessInfos;
}

The Btn_Search_Business_Click() function is very straightforward. The CreateBusinessInfos() function is bit more interesting - first we specify the UDDI registry value, then we create a BusinessEntities data structure. This is not a standard data structure in the UDDI specification. FindBusiness is a wrapper class used by the MS UDDI SDK 1.76 to implement find_business SOAP call to a UDDI registry.

We can set the maximum rows of the search result to 100. We also ask the SDK to sort the output by the ascending order of the business name. Then we do a selection construct to determine whether we selected the option to key in the business name or the "first letter selection". Depending on the selection we send a UDDI request to the UDDI registry using the BusinessEntities.Send() method. The actual SOAP envelope will look similar to this.

<?xml version='1.0' encoding='UTF-8'?>
<Envelope xmlns='http://schemas.xmlsoap.org/soap/envelope/'>
<Body>
   <find_business generic='2.0' xmlns='urn:uddi-org:api'>
          <name>Microsoft</name>
   </find_business>
</Body>
</Envelope>

The UDDI registry will return a businessEntity XML structure (referred to as the List variable in the code) that is used to populate the data grid. We also need to add the following code to activate the page navigation in the data grid.

private void DataGrid_Business_PageIndexChanged(object source, 
System.Web.UI.WebControls.DataGridPageChangedEventArgs e)
{
DataGrid_Business.CurrentPageIndex = e.NewPageIndex;
       DataGrid_Business.DataSource = CreateBusinessInfos();
       DataGrid_Business.DataBind();
} 
 

Here is a screenshot of the Business_Search.aspx page. A search has been made on the Microsoft UDDI directory for all the businesses starting with the letter "M ".

Image 2

Business.aspx

This page displays the result of a business search. We need the following references at the top of the Business_Search .aspx.cs page.

using Microsoft.Uddi;
using Microsoft.Uddi.Api;
using Microsoft.Uddi.Business;
using Microsoft.Uddi.Service;
using Microsoft.Uddi.Binding;
using Microsoft.Uddi.ServiceType;

The unique identifier for a business is called a "Business Key". The Business Key is already provided from the Business_Search.aspx. Therefore, we make another query to retrieve the business data from the UDDI registry.

GetBusinessDetail gBusinessDetails = new GetBusinessDetail();
gBusinessDetails.BusinessKeys.Add(Request.Params["BusinessKey"]);
BusinessDetail businessDetails = gBusinessDetails.Send();

GetBusinessDetail class is a UDDI wrapper class that returns BusinessDetails XML structure for a given BusinessKey. Now we can populate the server side labels with the data retuned by the UDDI registry.

Lbl_CompanyName.Text += businessDetails.BusinessEntities[0].Name +  "<br>";

Now we can dive into details about each business. Here is how we extract general information about the business (eg. Description , contacts details of the business).

foreach (Description d in businessDetails.BusinessEntities[0].Descriptions)  
Lbl_Business.Text += d.Text + "<br>";
Lbl_Business.Text += "<br>";
foreach (Contact c in businessDetails.BusinessEntities[0].Contacts ) 
{
       Lbl_Business.Text +=   c.PersonName + "<br>"; 
       foreach (Address a in c.Addresses) 
              {
                     foreach (string al in a.AddressLines) Lbl_Business.Text += al + "<br>"; 
              }
       Lbl_Business.Text += "<br>";
       foreach (Phone phone in c.Phones) Lbl_Business.Text +=  "Phone :- " + 
phone.Text  + "<br>";
       foreach (Email email in c.Emails) Lbl_Business.Text +=  "Email :- " + 
email.Text + "<br>";
}
foreach (DiscoveryUrl du in businessDetails.BusinessEntities[0].DiscoveryUrls) Lbl_Business.Text += "<a 
href='" + du.Text + "'>Discovery URL</a><br>";

Now we can dive into the collection of services offered by the business:

foreach (BusinessService bs in businessDetails.BusinessEntities[0].BusinessServices) 
{
       Lbl_Service.Text += "<a href='service.aspx?ServiceKey=" + 
bs.ServiceKey + "&BusinessKey=" + Request.Params["BusinessKey"] + "'>" + 
bs.Name + "</a><br>";
}

Here is a screenshot of the business details available for Microsoft:

Image 3

Service.aspx

This web form displays all the details about a selected Web Service. The unique identifier for a service is called the ServiceKey, which is passed on from the Business.aspx page. We use this key to query the registry. (We also need to include the namespaces at the top of the Service.aspx.cs file - Similar to Business.cs.)

GetServiceDetail gService = new GetServiceDetail();
gService.ServiceKeys.Add(Request.Params["ServiceKey"]);
ServiceDetail businessService = gService.Send();

GetServiceDetail is a wrapper class to implement find_service UDDI API call. This find_service API call will return a list of properties for a given ServiceKey. ServiceDetail data structure is an array of businessService data structures. Here is how we display the general details of the service:

Lbl_Service_Name.Text += " "+businessService.BusinessServices[0].Name ;
Lbl_Service.Text += "Description :- ";
foreach (Description d in businessService.BusinessServices[0].Descriptions )  
{
       Lbl_Service.Text += d.Text + "<br>";
}

Now we can extract the binding template information. Each binding template will have an access point to establish a connection with clients.

Lbl_Service.Text += "<H5>Binding Templates: -  "  + "</H5>";
foreach (BindingTemplate bt in businessService.BusinessServices[0].BindingTemplates)
{
       Lbl_Service.Text += "AccessPoint: " + "<a href='" + 
bt.AccessPoint.Text + "'>" + bt.AccessPoint.Text + "</a><BR>";
       foreach (Description d in bt.Descriptions)  
       {
              Lbl_Service.Text += "Description : " + d.Text + "<br>";
       }

Each binding template has one or more tModels associated with it. A user will first find the access point, they will then look for the binding template and then they will select a technology model to implement a client. This is how we display the tModel information:

if (bt.TModelInstanceDetail.TModelInstanceInfos.Count > 0)
{
       Lbl_Service.Text += "tModels : <br>";
       foreach (TModelInstanceInfo tmi in bt.TModelInstanceDetail.TModelInstanceInfos)  
       {
              Lbl_Service.Text += "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a 
href='TModel.aspx?tModelKey="  + tmi.TModelKey + "'>" + tmi.TModelKey + 
"</a>&nbsp;&nbsp;&nbsp;(<a href='" + 
tmi.InstanceDetail.OverviewDoc.OverviewURL +  "'>Overview Url</a>) <br>";
       }
}

Here is a screenshot for the "UDDI Web Sites" service available at Microsoft:

Image 4

TModel_Search.aspx

This page is very similar to the Business_Search.asp x page. The objective of this page is to search for Technology models - we can do this in two ways.

  • Sometimes we need to get a list of all the tModels implemented by a company (eg. All tModels Microsoft uses)
  • Sometimes we know the exact tModel we are after - we just need to dive into more technical details about it

Both these scenarios are supported in this page - we can either search by a company name or enter a tModel Key (unique identifier for a tModel). Unfortunately, tModels are not very well named when they are created, therefore it could be very confusing to understand a tModel by its name, so using the tModel Key is recommended.

When the Search tModels button is clicked, the data grid will populate with the search results.

First, get access to the name space. (Top of TModel_Search.aspx.cs)

using Microsoft.Uddi;

Here is the code to initiate the search:

private void Btn_TModel_Search_Click(object sender, System.EventArgs e)
{
       DataGrid_TModel.Visible = true;
       DataGrid_TModel.CurrentPageIndex = 0;
       Inquire.Url = Lst_UDDI_Registry.SelectedItem.Value;
       if(RadioButtons_Options.SelectedItem.Value == "Business")
       {
              DataGrid_TModel.DataSource = CreateTModelInfos();
       DataGrid_TModel.DataBind();
       }
       else
       {
              Response.Redirect("TModel.aspx?tModelKey=" + Txt_Search.Text);
       }
}

First we establish a connection with the specified UDDI Registry. I could have designed the browser to have a persistent connection to the UDDI registry. In reality you may need to query different UDDI registries to execute a single Web Service search - this is the case in most B2B implementations. Remember we can search MS UDDI registry for a business name and refer to the IBM UDDI registry to get the tModels the business implements. At the moment all the public nodes are synchronized every 24 hours. In the future the time delay will decrease further, therefore, creating a separate connection is a better design.

Note : Depending on the user's selection, we can either query the registry with the business name or forward the tModel Key to the tModel.aspx page to display the tModel information.

Here is the query to the registry, it is very similar to Business_Search.aspx:

private ICollection CreateTModelInfos()
{       
       FindTModel ftm = new FindTModel();
       ftm.MaxRows = 100;
       ftm.Name = Txt_Search.Text;
       ftm.FindQualifiers.Add("sortByNameAsc");
       TModelList tml = ftm.Send();
       return tml.TModelInfos;
}

Here is a screenshot for a search for all the tModels at Microsoft.

Image 5

TModel.aspx

TModel.aspx display all the details on a given tModel reference. The tModel reference (tModelKey) is passed from the tModel_Search.aspx.

First of all we need to include the namespaces at the top.

using Microsoft.Uddi;
using Microsoft.Uddi.Api;

We then get the tModel information from the registry. We also have a bit of exception handling to exit with errors in a graceful manner:

GetTModelDetail gtmd = new GetTModelDetail();
gtmd.TModelKeys.Add(Request.Params["tModelKey"]);
try
{
       TModelDetail tmd = gtmd.Send();
       Lbl_tModel_Implementation.Text = tmd.TModels[0].Name;
       Lbl_tModel.Text += "<b>tModelKey : </b>" +tmd.TModels[0].TModelKey + 
"<br>";
       foreach (Description d in tmd.TModels[0].Descriptions) 
              Lbl_tModel.Text += "<b>Description : </b>" + d.Text + "<br>";
              Lbl_tModel.Text += "<b>Overview URL : </b>" + "<a href='" + 
tmd.TModels[0].OverviewDoc.OverviewURL + "'>" + 
tmd.TModels[0].OverviewDoc.OverviewURL + "</a>";
}
catch
{
       Lbl_tModel.Text = "No tModel found";
}

Here is a screenshot for "Microsoft Geographic Taxonomy" on the MS UDDI registry.

Image 6

Notes on installing the application

All the source code for this application is available for download at the end of this article. Here are some notes to installed local copy on your system.

All the assemblies (including the Microsoft UDDI DLL) are included in the bin directory. In other words you do not need to install MS UDDI SDK 1.76 to run this application.

This is a mere demonstration of UDDI capabilities in Microsoft platform. We can build the following extensions to this application.

  • Have more exception handing
  • Implement a search for services (using Service Key and services offered by a company)
  • Implement Interfaces for the following API calls: find_relatedBusinesses , find_binding

Future of UDDI

The primary objective of UDDI is to act as a search engine to browse Web Services. UDDI Version 3 was released in September 2001. Further emphasis will be taken about managing hierarchical business organizations and trade groups. The driving goal will be interoperability of Web Services. The focus will concentrate on the integration of business-to-business seamless integration.

The UDDI specification describes an open framework to define, publish and discover information about Web Services. As Web Services emerge to become the programmatic backbone for e-commerce, businesses will use UDDI to discover services offered by other companies and to verify that those companies' services are compatible. UDDI provides the foundation necessary to create value-added services on top of the basic UDDI functionality. This could include leasing of services, subscription of services and dynamic discovery of services - UDDI.org may incorporate such technologies into future versions of the UDDI specification.

UDDI will change the way business-to-business commerce has been conducted over the Internet by giving businesses the ability to reach into the network and find better services and trading partners.

Please rate this article using the form below. By telling us what you like and dislike about it we can tailor our content to meet your needs.

Article Information
Author Chris Peiris
Technical Editors John R. Chapman, Vickie Pring
Project Manager Helen Cuthill
Reviewers Andrew Krowczyk, Sauhrab Nandu

If you have any questions or comments about this article, please contact the technical editor.

 
 
Rate this Article
How useful was this article?
Not useful Very useful
Brief Reader Comments: Read Comments
Your name (optional):
 
 
Content Related Links Discussion Comments Index Entries Downloads
 
Back to top