Fixing the UI EJB Disconnect

Where I work we use Java/J2EE with the "beans and screens" model. We use JSP/struts for the user interface, backed by business layer EJBs. The business layer EJBs are backed by a database abstraction layer. We don't use entity beans - regular business layer EJB is verbose and overhead enough, thank you. We do quick HTML mockups of the UI screens before formal JSP development begins.

The beans and screens model works pretty well. Business logic is well separated from presentation. We have some solid EJB developers and some solid UI developers. I haven't done any UI myself, and that doesn't really bother me.

What can happen with beans and screens is the “UI EJB disconnect” problem. What happens is the EJB developer goes off and implements some methods as he sees fit. The UI developer later on attempts to wire the UI screens to the EJB methods. What I've seen is that the EJB developer doesn’t seem to know what signatures he needs to create. The UI developer often doesn’t have the methods that are needed to build the screens. This disconnect causes lost time on the UI side thrashing around looking for methods to build screens. Time is lost on the EJB side creating methods that are not used, and scrambling to put methods in quickly for UI requirements.

This situation is not ideal and should be resolved. The UI people should not have to thrash around looking for methods to build a screen (since the screen layout is known from the mockup). The EJB people should not be blindsided by unexpected UI method requirements.

To me it is a communication issue. Instead of going off and implementing signatures as he sees fit (trying to guess what the UI will need), it would be better if the EJB developer was told what signatures he needs to implement. This would also be communicated to the UI developer so when he codes a screen it is known in advance what the backing EJB calls will be.

The use of metaprogramming can fix the UI EJB disconnect. This is a top down approach to EJB specification where a metaprogrammer brokers the conversation between the UI and EJB developers. When one developer will need an EJB call to be provided by another developer, the metaprogrammer specifies to both developers the call signature and describes how to implement it. It is the metaprogrammer's job to anticipate the EJB calls that will be needed in advance and specify them before the client programmer gets to the point of needing to call them.

I tried this technique on a project where I was the team leader with around six developers working for me. It worked pretty well. There were no instances of a client developer being stuck needing an EJB call from someone else that hadn’t been specified yet. The UI developers seemed to like it. One thing that's important is to have fast turnaround of stub methods on the EJB side. When the metaprogrammer gives an EJB developer a method signature to create, the EJB developer needs to be required to put in place the signature and a stub implementation right away. The actual full implementation can be done later. This will avoid a situation where the EJB developer is given a signature to create, but doesn't get around to it in time, and the client developer is ready to call the stub signature that hasn't been created yet - causing delays for the UI client developer.

You may be reading this and thinking "Why not just fully specify all the EJB signatures up front as part of the design phase? Then it will be ironed out before coding starts and you won't have this problem." That's a good question. In an ideal world this would be a nice way to do it. Where I work the schedules are compressed, and doing that type of full design up front would end up consuming the entire development cycle and not leave any time to implement the code.

Also some shops are not fans of "big design up front", realizing that the built system typically differs substantially from the original feature set and design. In a more agile environment you need to be able to move quickly with short development cycles focusing on releasing new working features. So you need to advance the product in a way that is technically sound, yet requires little overhead.