In this article I’d like to talk about the importance of the business delegate pattern which for me has been invaluable in achieving manageable budgets and risk on systems that needed to be significantly upgraded or enhanced.
Firstly what is it?
The tech specs of this pattern can be found here. (note this link has changed and will be updated soon)
http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
In short the business delegate pattern provides a pattern to decouple interfaces from actual business services.
In the J2EE world in particular, it has been common practice for developers to tie business services directly to EJBs. That is you cannot use a business service unless your willing to access it using an EJB call. Although modern frameworks have moved us on from this design, the reality is those systems are not that old and are regularly requiring re-architecture and this becomes a problem point for the architect and therefore for the business.
I’m posting this blog to highlight the importance and value of this particular design pattern in dealing with re-architecture challenges of these types of older systems (particularly EJB 2.0 and older and in those bad old days when EJBs were split into remote and local implementations that demanded different interfaces just because the container was not smart enough to manage this itself.)
In previous work I’ve identified this pattern as provided a way to re-design existing systems to create a decoupling between business services and the remote interfaces used by the system.
Why this this important? Because when asked to re-architect a system to support new functionality the biggest problem is assessing the quality of the code and ensuring nothing “breaks” when you add new functionality to it. If you cannot assess this you cannot reduce risk and therefore projects blow out in cost and time.
One of the safest ways to deal with this issue is to increase (or introduce) test coverage into the system to provide an automatically verified statement of functionality through regression test suites that confirm what the system does before changing anything! The BIG problem with these older systems is you cannot introduce test coverage because there are too many layers in the application (the deeper the layers the more impossible it becomes to create quality tests). A single business service test goes through not only the business service code but the remote interface and potentially persistence / database layers as well as usually some basic dependency injection logic (prior to bijection things were pretty messy). When a test that goes through this many layers fails your no better off than before as its not possible to isolate the exact cause of failure easily, therefore defeating the purpose of automated testing.
The business delegate pattern offers an approach by rewriting the business service end points to decouple them from the EJB (or other) layer. This makes the interface testable outside of an EJB container. Yes you still need to deal with decoupling the database and other services but these come more naturally once the back of the problem is broken which is the remote services.
In the past I’ve attempted to implement the delegate pattern using custom code leveraging technology such as cglib and simple IOC frameworks like HiveMind. This had mixed results.
The killer framework for this pattern turned out to be the Spring Framework, which by design implements the delegate pattern extremely well. The use of IOC is fundamental to the design of the Spring Framework and once a business service is rewritten its simply a matter of providing a XML configuration to switch its interface from say an EJB to a POJO method call and more. This means you can easily write unit tests around the business service POJO method and run it out-of-container then for the real system switch back in the EJB calls. There are still challenges such as propagation of error messages through the interfaces but again once the key problem is solved the project becomes much more manageable.
Here is an example of how an interface is defined in XML
<bean id="myComponent"> <property name="jndiName" value="ejb/myBean"/> <property name="businessInterface" value="com.mycom.MyComponent"/> </bean> <bean id="myController"> <property name="myComponent" ref="myComponent"/> </bean>
Each service is defined like this can can be changed. Take a look over the Spring documentation to get a better understanding.
My recommendation is therefore to give consideration to decoupling your business services using Spring and this pattern as part of a first step to updating the architecture of an old application so that an increase in test coverage can be achieved before major refactoring.
This has been a successful approach for me in the past in taking what appeared to be an unmanageable job of reworking an existing large scale system to being something I could plan and even estimate on without having to necessarily throw out the existing system to achieve manageable risk and budget.