Sunday, November 4, 2007

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:




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.





Friday, November 2, 2007

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?