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)
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.)