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.
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 ".
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:
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 += " <a
href='TModel.aspx?tModelKey=" + tmi.TModelKey + "'>" + tmi.TModelKey +
"</a> (<a href='" +
tmi.InstanceDetail.OverviewDoc.OverviewURL + "'>Overview Url</a>) <br>";
}
}
Here is a screenshot for the "UDDI Web Sites" service available
at Microsoft:
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.
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.
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. |