Dynamic Partner Links and the UDDI BC

I recently posted a basic example of Dynamic Partner Links in OpenESB here. In this post, I'll show how to use the UDDI BC to dynamically resolve a service URL at runtime and invoke it.

Without dynamic partner links and the UDDI BC, what would you do if a service you're invoking from within your process was moved? Well, you'd have to modify, rebuild, and re-deploy your Composite Application. Using what I'm about to show you, your process can react to that change automatically.

Below is the tutorial (really just some high level steps). I've also uploaded my NetBeans modules and a copy of the tutorial here.

Prerequisites:

• OpenESB Installer
  


• jUDDI (additional install tips here)
  

Tutorial:

• Step 1: Create a New BPEL Module



• Step 2: Create a New SOAP WSDL with one request-response operation, and a simple BPEL process for the backend . We'll invoke this service dynamically later on.





• Step 3: Create a New UDDI WSDL with one request-resposne operation. (UDDI BC Demos can be found here)



• Step 4: Add an External WSDL File from http://schemas.xmlsoap.org/ws/2004/08/addressing. The WS-Addressing WSDL defines the EndpointReference element that we'll need.
  
  • GOTCHA: NetBeans may add a character to the beginning of the wsdl when it imports. Make sure to remove this character. In some cases, this may be a hidden character that will only show up in an editor like VI.
  
  
  
  



• Step 5: Create another SOAP WSDL with one request-response operation. This service will provide the dynamic partner link functionality.



• Step 6: Create another BPEL Process. This process should lookup a service endpoint in UDDI and invoke the service using a dynamic partner link.





• Step 7: Clean and Build the BPEL Module.



• Step 8: Create a Composite Application and add your BPEL Module to it.



• Step 9: Clean and Build the Composite Application.



• Step 10: Correct the Composite Application's configuration using the CASA Editor.
  
  • Generated:
    
    
    
  
  
  
  
  • Corrected:
    
    
    
  
  



• Step 11: Clean, Build, and Deploy the Composite Application Again



• Step 12: Create a test case to invoke the service we've created.



• Step 13: Create another service to invoke, just as in Step 2. Make the BPEL process do something a little different so we will be able to tell which service was invoked.
  
  • This WSDL must have the same target namespace and operation to invoke as the WSDL in step 2.
    
  
  



• Step 14: Update the service endpoint in UDDI to point to the new service you created.



• Step 15: Run the testcase again. The output will show the new service was invoked.

Dynamic Partner Links in JBI

I've put together an example of using a dynamic partner link in OpenESB. This example shows the basics of assigning an EndpointReference to a partner link at runtime, and then invoking that partner link.

Below is the tutorial I've put together (really just some high level steps). I've also uploaded the tutorial and NetBeans modules I've created here.

Prerequisites:

• OpenESB Installer
  

Tutorial:

• Step 1: Create a New BPEL Module
  



• Step 2: Create a New SOAP WSDL with one request-response operation, and a simple BPEL process for the backend . We'll invoke this service dynamically later on.
  



• Step 3: Add an External WSDL File from http://schemas.xmlsoap.org/ws/2004/08/addressing. The WS-Addressing WSDL defines the EndpointReference element that we'll need.
  
  • GOTCHA: NetBeans may add a character to the beginning of the wsdl when it imports. Make sure to remove this character. In some cases, this may be a hidden character that will only show up in an editor like VI.
    
  
  



• Step 4: Create another SOAP WSDL with one request-response operation. This service will provide the dynamic partner link functionality.
  
  • Add a schema to the wsdl that defines an elment that accepts an EndpointReference and xsd:anyType.
    
  • Modify the request message accordingly
    
  
  






• Step 5: Create another BPEL Process. This process should assign the EndpointReference to a PartnerLink and invoke it.
  






• Step 6: Clean and Build the BPEL Module.
  



• Step 7: Create a Composite Application and add your BPEL Module to it.
  



• Step 8: Clean and Build the Composite Application.
  



• Step 9: Correct the Composite Application's configuration using the CASA Editor.
  
  • Generated:
    
    
  
  
  • Corrected:
    
    



• Step 10: Clean, Build, and Deploy the Composite Application Again
  



• Step 11: Create a test case to invoke the service we created in step 2.
  





• Step 12: Create another service to invoke, just as in Step 2. Make the BPEL process do something a little different so we will be able to tell which service was invoked.
  
  • This WSDL must have the same target namespace and operation to invoke as the WSDL in step 2.
    
  
  



• Step 13: Create a second test case to invoke the new service you've created.
  

Class Dependencies and the Factory Pattern

I listened to a Podcast this morning from Software Engineering Radio on Dependencies. In the context of this podcast, dependencies refers to the relationship between objects. The problem discussed was the lack of support for these object relationships in today's OO languages.

I wanted to touch on one specific topic covered in the podcast; the negative effect on dependency visibility that can come from a... misguided?... use of the Factory pattern.

Here's the problem:

Pretend you have a factory that exposes, lets say, 10 objects. And you have a class that uses the factory to obtain 3 of those objects. Without having intimate knowledge of the class or searching the class's implementation for "Factory.getXXXXXXX()", it's impossible to tell exactly what objects an instance of the class depends on. What you end up with is a spider-web like architecture. Many classes depend on the Factory which in turn depends on many classes itself.

So, what's the solution?

One possibility is to enforce a 1:1 ratio between factories, and classes using a factory. If Class A depends on instances of Class B and Class C, the factory Class, FactoryA must only expose instances of Class B and Class C. Also, Class A must only use FactoryA. Doing this provides confidence that all objects exposed by the factory are dependencies of the class.

Another possibility would be implementing Dependency Injection. If you go with constructor injection, class dependencies are visible as parameters to the constructor. If you go with setter injection, all dependencies are visible via the setter methods.

Food for Thought
1. Is Dependency Injection an alternative to Factory Pattern?
2. Does this problem also arise in the use of Service Locator?
3. What do you gain with clear dependency visibility?