POSTS
UDDI registries and Mocking
UDDI registries provide a number of features. Primarily they are billed as governance mechanisms for enterprises running SOA environments. They also provide endpoint indirection capabilities, which are useful from a governance perspective, but can also be used for testing. This is an extension of the dependency injection pattern, which is commonly used in object oriented programming, into the distributed world. When a developer unit tests he wants to test only his component, and not necessarily the dependencies of his component. This leads to more directed testing, and means that a high level component can be developed in parallel to lower level components, or even before.
By using dependency injection, we can abstract away the dependencies of a component and replace the code that we are calling with an interface which gets updated at run time to point to the implementation that we want: either the real implementation (for production) or a testing stub implementation that suits the test that we are running. This approach is generally called Mocking and is in widespread use throughout the industry.
In the SOA world, our interfaces are WSDLs, so we don't really need to change our development practices to support dependency injection; all we need is a mechanism. Oracle's BPEL product provides a test tool that allows the developer to run his orchestration process in a special mode where any invoke/receive step can be replaced by a Mocked response. This is great, but it is not a general solution, and the testing tool has several.... well bugs.... that make it more difficult to use. UDDI registries also provide the capability to indirect endpoints, so they could equally well be used in this regard. It has the advantage of being ubiquitous. Wherever you invoke web services, you can use UDDI. Those endpoints can be changed to point to your mock services, possibly written in SoapUI. What this requires is runtime access to the UDDI server The general process for running a unit test would now be:
- Set up your UDDI registry to contain your consumed interface (the target service)
- Code and deploy your consumer service to use this UDDI service
- Run your unit test
- Start up your Mock Service
- Update the UDDI endpoint to point to the mock
- Run the test code
- Restore the UDDI key to its original value (optional)
- Report your Results
For this to work correctly your tests must have control over the UDDI server. For the duration of the tests, the endpoints must be set correctly on your UDDI server for the tests to work. If you have multiple developers all working on the same system, this means that they each need their own environment. If a common environment was used, one developer could update the key for a service that another developer was using, thus making the results inconsistent.
Now product licensing rears its ugly head. Commercial products need to be licensed to be used, and most SOA toolsets do not support free licenses for these tools. The thought is that these are enterprise tools and should be charged appropriately. This is unfortunate, as it makes dependency injection and unit testing using services very difficult. JUDDI is an open source implementation of the UDDI v2 specification. In my project we are currently evaluating whether this would be appropriate for use as a dependency injection tool. If it is, then this will be great, but I still don't think its ideal. All products are not created equal, and we will need to perform additional testing to make sure that our system supports our commercial, expensive UDDI registry as well as the free JUDDI. It also means that we are restricted to the most common denominator of functionality between the two products.
Life would be much easier if the SOA tools were freely licensed for development purposes. I'm probably hoping against hope, but to me it makes good business sense. If you let developers use your products for development, they will get used more in production.