Problem
If you have worked with Web Services or WCF Services for any amount of time you know that it can be difficult to keep WCF/ASMX client proxies up to date and if you have a large number of services the sheer number of proxy classes becomes hard to manage.
The following is an attempt to ease the deployment and maintenance of our Services Farm and to enable endpoint discovery using Microsoft UDDI 3.0 Services so that we aren’t bound to static hard coded web.config and/or app.config files for service binding information.
There is nothing more painful than having to update multiple client proxies if a service’s interface changes or to have to modify each process’s configuration files if you need to change the Uri for a service.
Overview
The following diagram depicts the process sequence for utilizing the Microsoft.UDDI.dll to retrieve the URI from Microsoft’s UDDI 3.0 Services repository for a simple WCF Service. The returned Uri and other configuration data is then passed to the GenericServiceGateWay class which builds a runtime proxy that allows the methods on the WCF Service to be utilized by the client application.
Solution
This is a simple solution that addresses our current needs. I can definitely see this expanding over time and becoming a richer solution that can handle more intricate configuration and security needs. I hope that this first step can provide value to you and I would be happy to hear suggestions on improving what we currently have.
Visual Studio 2008 Solution Setup
The following is a screenshot of the Solution setup. Notice that references are highlighted in red.
Prerequisite Setup
UDDI Setup
Microsoft UDDI Services 3.0 will need to be installed on a server in your environment to run the application documented in this article. Here is a summary of Microsoft UDDI Services 3.0 features copied from MSDN’s description.
http://msdn.microsoft.com/en-us/biztalk/dd789428.aspx
Microsoft UDDI Services 3.0 (Universal Description, Discovery, and Integration Services) ships with Microsoft BizTalk Server 2009, and conforms to the UDDI version 3.0 specification. UDDI Services 3.0 provides the following key capabilities:
• A Web service that supports UDDI version 3.0 standards-compliant interfaces for service discovery.
• Rich role-based Web UI interfaces for service searching, publishing, subscribing, and site coordination.
• Notifications of service changes.
• Custom categorization schemes for describing service providers and their Web services in your organization.
• SDK and developer tools to facilitate the development of UDDI-integrated applications.
• A rich set of administration tools to ease the management of UDDI Services.
Some of the key benefits of UDDI Services are:
• It provides a scalable solution for organizing, discovering, reusing, and managing Web services.
• It promotes service reuse.
• It facilitates loosely-coupled service hosting environments by enabling run-time selection of, and binding to, a service endpoint.
• It provides interoperability with other UDDI standards-compliant tools.
Microsoft UDDI Services 3.0 included with Microsoft® BizTalk® Server 2009. The installation instructions and system requirements can be found at the following URL:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=9d1831cc-8146-486b-b489-a06a1aa2fb5b
For some great information on how to set up a WCF Service in Microsoft UDDI Services and a good UDDI overview read Richard Seroter’s article at the following URL:
http://www.packtpub.com/article/soa-capabilities-in-biztalk-uddi
You will need to configure the location of PrototypeService in UDDI. I also recommend hosting the ProtoTypeService in IIS so that Visual Studio doesn't reassign port numbers at random :)
Below is a screen shot of the service set up in UDDI.
Client Application
I have created a simple Windows Forms client to utilize the GenericServiceGateWay class from the TJT.Prototypes.ServiceGateWays project to retrieve a runtime proxy to a simple WCF Service. Below is the client code to consume the GenericServiceGateWay:
.Net Components
The following section describes the components included in each project in the solution and includes the code.
TJT.Prototypes.Enums Project
WCFTransportTypeEnum.cs
This is just a simple enum class to help with setting the right string for the case statement in GenericServiceGateWay.cs.
TJT.Prototypes.ServiceContracts Project
IPrototypeService.cs
This is the service contract interface for the ProtoTypeService WCF Service.
TJT.Prototypes.ServiceGateWays Project
GenericServiceGateWay.cs
This class is one of the primary focuses of this article. The GetGenericFactoryChannel method returns a runtime proxy that can be used to bind to and execute methods on a WCF Service. The Dispose method is used for cleanup and should be called any time you are finished working with a service.
TJT.Prototypes.UDDI Project
UDDIHelper.cs
This class encapsulates communications with Microsoft UDDI 3.0 Services. See the section about UDDI configuration on how to set up the PrototypeService WCF Service so that you can retrieve its Uri. This class depends on a reference to the Microsoft.UDDI.dll that installs with Microsoft UDDI Services 3.0. This file can be located at %PROGRAMFILES%\Microsoft UDDI Services\SDK.
WCF Service
PrototypeService Project
This is a simple WCF service to test the functionality of the GenericServiceGateWay class. This service returns a string with the value that you passed to it appended to the end.
Conclusion
Maintaining app.config files and the related WCF binding information for clients to connect to WCF services in your enterprise can create a deployment and maintenance challenge for your organization. As the number of Services grows in your Enterprise, dealing with reconfiguring client’s configuration files as WCF binding properties change or as WCF Services are moved around Web Server Farms can quickly become a significant task
Also, leveraging Microsoft UDDI 3.0 Services is a great way to add a layer of Service Virtualization to better manage changing Uri’s for services. It allows you to change the Uri and/or Service metadata in one place and clients that query UDDI Services will pick up the changes and keep working without a configuration file change. This solution was a quick way for us to overcome this challenge in the short term and may provide value to you as you work to find solutions to similar problems.
