Exit Condition

Water in my apartment comes in one of exactly two temperatures; prolonged exposure to either requires medical attention. See, it’s an old building and the ancient plumbing isn’t great at the even distribution of flow to each unit. So I simply cannot shower; I must run a bath and manually regulate the heat levels coming out the faucet.

My landlords tell me there’s not much that can be done - stripping out the internals is just not cost-effective. It’s better for them to let me suffer. Were I a shrewd businessman, I’d understand.

But I’m a programmer, and I have a heart.

There’s perfectly good hot water down there. Mother January in NYC gives us unlimited cold water. And ain’t nothing wrong with my tap. It’s the transport. The damn plumbing. Once you install plumbing, you’re married to it. And divorce is expensive.

Incredible how much of the same is true in Web Application Development. Most Enterprise Applications take advantage of at least one Service-Oriented Architecture exposing its API in platform- or language-agnostic mechanisms. The “M” of MVC. This is Good.

Also Good is the wide variety of templating options available to handle the “V” of MVC. JSP/JSTL, Facelets, Velocity, XSL…all are pretty swappable.

The “C” word, as we always knew, is Bad.

Oh, Controller, responsible for parsing a request, determining an appropriate action based on its content, delegating to the correct processor, and passing the result onto the view. Historically it was identified that this common concern should be addressed in a generic fashion, and every programmer began his own proprietary solution to the problem. Soon after, Struts, and in the years following, The Framework Wars.

The AJAX Movement has not made this any easier, as often the “MVC within an MVC” pattern is applied; one each for the client- and server-side.

When I look over some of the greatest architectural decisions I’ve made in the past few years, the common thread has been my heavy use of the “delete” button. Removing entire layers of code. No more transfer/value objects. No more Business Delegates.

Now I want to get rid of the Web Tier in many cases. I love you Tomcat, but we’re doing you a disservice through abuse and overuse.

It’s time to expose our EJBs directly to our frontend teams. Asynchronous JS calls can so easily hook into business logic, and there’d be no more custom Servlet code inbetween. RPC for JS.

Not that this is unchartered territory, but all solutions I’ve encountered involve a webapp (Framework) to be deployed inside a Servlet Container, and I want to avoid the extra dependencies, glue code/configs, and unnecessary traffic over those channels.

I want JavaScript that reads:

EjbRequest request = new EjbRequest("com.alrubinger.BusinessInterfaceName","methodName","arg1","arg2","argX");
request.setResponseHandler = myResponseHandlerFunction;
request.send();


The beauty of this is that aside from the required import of a JavaScript library, theres no imposition on the application inbetween.

And behind the scenes, beyond the worry of either the frontend or application developer:

• Request is sent (as JSON, XML, etc)
• Received by separate, slim, non-blocking server as JCA Resource Adaptor.
• JS > Java Object Mapping
• Sent to “onMessage” of MDB
• Dispatched to specified EJB, JNDI lookups transparent
• Invocation
• Result sent to Response Queue
• Unwrapping, Java Object > JS Mapping
• Write the response

I think back to all the occassions I’ve been asked to expose some method to my UI guys, and its horrifying the amount of time I’d spent (and errors introduced) simply getting well-tested data from points A to B. Stopping actual development to build a pipe. It makes me feel dirty.

So now I need a bath.

S,
ALR