Web service standards have made outstanding progress. However, let's take a quick step backwards to examine an older standard called Universal Description, Discovery and Integration of Web services (UDDI). The UDDI specification defines a SOAP-based Web service for locating Web services and programmable resources on a network. It offers a foundation for sharing information about internal services across the enterprise and public services on the Internet.1
It is not my intention to give you an overview of UDDI itself, nor how to interact with it. This article explains how to query UDDI in order to pull out details regarding specific services. (For information on UDDI's purpose and use, see http://www.uddi.org/ or http://msdn.microsoft.com/uddi.). For the remainder of this article, I will assume a good working knowledge of UDDI and will also offer limited detail about setting up Visual Studio .NET to consume a Web Service (adding a Web reference, etc.).
Let's begin by creating a simple Web service and distributing it to our redundant end points. Next, we will run through how to register and relate these end points within UDDI, paying attention to two specific items that need to be noted. Lastly, we will bring it all together with some code that will show how to leverage UDDI to consume the redundant end points when there is a failure.
This Web service has only one method, which takes no parameters, and returns only a single string, a globally unique identifier (GUID). This simple service will not be too complicated and will allow us to focus more on how to interact with UDDI and use it to add the redundancy. Figure 1.1 is the complete source for the service.
Figure 1.1 Our GUID Generation Service
<%@ Webservice Language="C#" class="GuidGenerator" %>
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService(Namespace="http://www.15seconds.com/articles/robchartier/guid",
Description="Generate a GUID, to be used with UDDI for failover example")]
public class GuidGenerator {
[WebMethod(Description="Generate the GUID")]
public string GetGuid() {
return System.Guid.NewGuid().ToString();
}
}
Copy the code into a text file named guid.asmx and save it on your server. The Web service can be tested in your Web browser. Allow it to generate a GUID. Then copy the Asp.Net Web Service (ASMX) file onto any other public access points that you may have. Since that is the focus of this article, make at least one replication of the end point or simply use the ones I have created.
UDDI
First-time users of UDDI must follow the registration process to validate an e-mail address. For this article I have chosen to use the public Microsoft UDDI node found at https://uddi.microsoft.com. Once registered, publishing begins simply by clicking the "Publish" link on the left navigation.
The first thing we will create is a tModel. On the tree to the left is the "My UDDI" node. When clicked three tabs will appear to the right. Click on the "tModels" tab. This page allows you to Add, View, or Delete tModels. To review, a tModel is used to represent a "description of an interface." It allows you to describe the features and requirements of the service. Since we are defining an interface, anything that we say conforms to that interface must exhibit its behavior. This allows use to group together a collection of actual end points that we can depend on to be the same. This is really the core of the ability to add redundancy to our Web services. Since they all are defined to be the same, we can depend on that heavily and treat them all in the same manner. This should be a fairly easy concept for those familiar with an interface within the Object Orientated Programming (OOP) context.
The interface, or grouping of these services, can be represented with a tModel. With the UDDI SDK we can make direct queries for a given tModel based on its tModel key. I have added a new tModel, "GuidGenerator", and the system has automatically assigned a tModel key for me. View this on the "Details" tab within the new node on the left, right under the tModels node. This is the first piece of information we must make note of -- the tModel key.
Now that we have a tModel (our interface description), we must bind the actual end points to it. This is done through the Providers section. Create a new Provider for your given organization, and within that Provider create a service named "Guid Generator." Remember that a "Service" within UDDI is the logical representation of a service that your organization provides and is not specifically related to a single end point. Also, the UDDI allows many bindings or URLs to be indicated, or the actual physical end points to your Web services on the network. Once you add the new service, you will be assigned a new "Service key." This is the second and last piece of information to note.
Each binding now can be added to each end point. Notice the option to change the URL type (HTTP being the default). Use HTTP" for our purposes. When adding the first binding, notice the "Instance Info" tab. This is where we will be actually relating the tModel we created to the specific binding of the service. Clicking the "Add Instance Info" button, prompts a search. Type in the name of the tModel we added, "GuidGenerator", and hit the search button. Your specific tModel should be shown, and by clicking it, it will add that tModel interface to the new binding for the service. Take time now to complete all of the bindings for your service.
Now that we have our service and tModel stored within UDDI, and we have recorded both unique identifiers, we can begin to make queries against UDDI using the SDK.
Redundancy
In my new C# ASP.NET Web application, I created a Web reference to the default end points. Some small functionality also was added to the project, which can be reviewed by downloading the sample solution included in the ZIP file. This section covers the important sections of that code.
The first portion of code is the bare bones needed to consume the Web service, which I have encapsulated in a function given below.
Figure 1.2 Encapsulating the Web Service Call
public string ExecuteService(string url) {
//no exception handling done here,
//let the parent handle it so it can handle a list of items
GuidGeneratorService.GuidGenerator guidGene
= new GuidGeneratorService.GuidGenerator();
guidGene.Url=url;
return guidGene.GetGuid();
}
It's important to notice that I am passing in the URL for the Web service end point. This will become clearer later when we query UDDI for the list of URLs that we will be using to call the service.
The next portion of code that I felt was necessary gives us the ability to specify a list of URLs and have it automatically call the end points in that list until it receives a response. When it does, it will return the actual response, including the end point it used. Figure 1.3 demonstrates this.
Figure 1.3 Executing a List of End Points
public string[] ExecuteService(string[] urllist) {
string result ="";
for(int x=0;x<=urllist.Length;x++) {
try {
result = ExecuteService(urllist[x]);
}catch(Exception) {}
if(result!="") {
return new string[]{result, urllist[x]};
break;
}
}
return null;
}
Notice the try{}catch{} block is only around the call to our "ExecuteService" method. So if that single method does not fail, we can assume a good return from the service, and return our values.
Now that we can execute a single end point, or a list of end points, we will need to be able to query UDDI in order to get that list of end points when our default fails. Keep in mind that we would only want to query UDDI if our default end point has failed. Querying UDDI requires the two keys generated earlier and the single UDDI inquire end point. Here are my values:
Figure 1.4 My Service Key, tModel Key, an UDDI Inquire End Point
All of these are defined at class scope so they are available to the entire class. Figure 1.5 below shows how we can query UDDI using these pieces of information.
Figure 1.5 Querying UDDI
private string[] GetHttpUrlsForTModel(string servicekey, string tmodelkey) {
//set the inquire URL to our class defined location
Microsoft.Uddi.Inquire.Url = UddiInquireUrl;
//create a new binding searcher
Microsoft.Uddi.FindBinding bindingSearcher = new
Microsoft.Uddi.FindBinding();
//load up with our service key and add the tModel key
bindingSearcher.ServiceKey=servicekey;
bindingSearcher.TModelKeys.Add(tmodelkey);
//send the search
Microsoft.Uddi.BindingDetail details = bindingSearcher.Send();
string[] urllist=new string[details.BindingTemplates.Count];
//loop on all the results, and gather all of the HTTP end points
for(int x=0;x<details.BindingTemplates.Count;x++) {
if(details.BindingTemplates[x].AccessPoint.URLType==Microsoft.Uddi.Api.URL
Type.Http ||details.BindingTemplates[x].AccessPoint.URLType==Microsoft.Uddi.Api.URLType.Ht
tps) {
urllist[x] = details.BindingTemplates[x].AccessPoint.Text;
if(breakurls) if(x<details.BindingTemplates.Count-1)
urllist[x] = urllist[x].Replace(".asmx", "BROKEN");
}
}
//send back the list of URLs
return urllist;
}
Take a few seconds now to review that portion of code and pay attention to the comments. It is pretty self-explanatory. Given a Service key and a tModel key, it will return a string list of the HTTP end points we set up in UDDI.
The last section of code we need to take a close look at is how we put all of these methods together to create the calls to the end point, or to UDDI, if we need to. Figure 1.6 below is the portion that handles this.
Figure 1.6 Calling the Service and Using UDDI to Handle Redundancy
private void anySourceGuidButton_Click(object sender, System.EventArgs e) {
//set the default URL to be the URL we will try first
string usedUrl=defaultUrl;
string newguid="Nothing Generated";
try {
//try to execute the service, with the default URL
newguid = ExecuteService(usedUrl);
}catch(Exception executionException) {
//we got an error, so now connect to UDDI to grab a list of
alternative URL end points to test from
string[] urllist = GetHttpUrlsForTModel(ServiceKey, TModelKey);
string[] results = ExecuteService(urllist);
if(results==null) {
//no results from any service, set defaults to display this
newguid="No Valid EndPoint found.";
usedUrl="No Valid EndPoint found.";
} else {
//load up our variables with the results
newguid=results[0];
usedUrl=results[1];
}
}
//set values in the labels in the form
this.guidLabel.Text=newguid;
this.sourceURLLabel.Text=usedUrl;
}
Again, the code should be pretty easy to follow by reviewing the comments. Notice that we first try to call the ExecuteService() call with the default URL before we even touch UDDI. This will avoid the extra hit to the UDDI service and the additional overhead associated with that.
In the downloadable solution, notice the added functionality that breaks all but the last end point that we receive in UDDI. Use it to test out the application to ensure that it is taking advantage of UDDI to make the calls to the other end points. It will fail on the initial call and then move on to query UDDI for the list of URLs as expected.
Conclusion
This article shows how easy it is to leverage public UDDI nodes to create redundancy in public Web services. This could be a very important issue when dealing with end points or networks that are just not very reliable. I think we will see more focus on the quality we will be getting out of Web services, with special attention around Service Level Agreements between the publishers and subscribers. As more organizations are publishing their products and services over Web services, they will need to ensure reliability, and this article demonstrates just how to add to your own reliability.
Don't just think of UDDI in the public sense. We are beginning to see more and more internal implementations of UDDI nodes within the corporation. IT managers are beginning to see the long-term advantages of having an internal UDDI implementation within their own organization and firewalls. One idea that comes to mind is the ability to allow UDDI to be the host for all of a specific services' end points, which a central server (head office) could query in order to get this list and then hit each service. For example, if you had branch offices that needed to communicate with the central server's daily sales data, you could easily have each branch register itself to your organization's UDDI node. And then when the head office is ready to download all of the data, it can query each end point for its data, downloading and logging each result. This will grant users greater control over when the data will be captured, etc.
I hope your eyes are opened to some of the potential of UDDI. If you have any questions, feel free to contact me at any time.
About the Author
Robert Chartier has developed IT solutions for more than nine years with a diverse background in both software and hardware development. He is internationally recognized as an innovative thinker and leading IT architect with frequent speaking engagements showcasing his expertise. He's been an integral part of many open forums on cutting-edge technology, including the .NET Framework and Web Services. His current position as vice president of technology for Santra Technology (http://www.santra.com) has allowed him to focus on innovation within the Web Services market space.
He uses expertise with many Microsoft technologies, including .NET, and a strong background in Oracle, BEA Systems, Inc.'s BEA WebLogic, IBM, Java 2 Platform Enterprise Edition (J2EE), and similar technologies to support his award-winning writing. He frequently publishes to many of the leading developer and industry support Web sites and publications. He has a bachelor's degree in Computer Information Systems.
In the second article of his series on Indigo web services, Chris Peiris explains how to host an Indigo web service and examines the IIS, self hosting, and Windows Activation Service hosting options. He then provides step-by-step instructions and sample code for an IIS-hosted and self-hosted Indigo web service. [Read This Article][Top]
In the first part of his series on Microsoft Indigo, Chris Peiris examines the basics of SOA, explains how Indigo fits into the picture and the problems it solves. He then introduces Indigo's programming model and finishes by building a sample Indigo web service using the Microsoft .Net Framework 2.0. [Read This Article][Top]
Adnan Masood concludes his discussion of Microsoft SQL Server Analysis services and Microsoft SQL Server Reporting services. In the final part, he discusses Reporting Server web services and using custom code in reports. [Read This Article][Top]
This article explains the features of the IE Web service behavior and shows how to asynchronously communicate with an ASP.NET Web service directly from the client.
[Read This Article][Top]
Calvin Luttrell shows how to validate e-mail addresses stored in Excel 2003 and
provides a special function for solving that pesky problem Yahoo! mail servers cause. [Read This Article][Top]
This short article describes a quick and easy way to provide some security to an ASP.NET Web service by modifying its associated documentation file. [Read This Article][Top]
Kerberos authentication is the cornerstone of Windows operating system authentication architecture. Web Services Enhancement 2.0 (WSE 2.0) extends Kerberos support to ASP.NET Web services. Chris Peiris explains the support for this new feature in WSE 2.0. [Read This Article][Top]
Chip Irek examines the architectural issues and component design issues of building a .NET application in a service-oriented architecture. [Read This Article][Top]
Thiru Thangarathinam shows how to use asynchronous Web services, Windows
Service applications, server-based timer components and .NET XML API classes to create high-performance, scalable, and flexible applications. [Read This Article][Top]
Part one showed how to transform XML data into HTML by using an XSL stylesheet from within a .NET application. This part explains how to make use of XSLT Extension objects and invoke a C# class method from an XSL stylesheet. [Read This Article][Top]
Mailing List
Want to receive email when the next article is published? Just Click Here to sign up.
