Skip to main content

Explicit vs. Implicit Programming Models for J2EE

Posted by monsonhaefel on December 16, 2003 at 9:03 PM PST

Over the past four years the various J2EE APIs (EJB, Servlets, JDBC, etc.) have become more and more sophisticated and, unfortunately, more complicated. As a result the learning curve has become ridiculously steep – for every API in J2EE there are dozens of types and hundreds of methods and a bazillion books designed to make them easier to understand. The increase in sophistication is necessary because enterprise software is inherently complicated, but do the APIs need to reflect the complexity of the underlying systems or should they hide the complexity? I argue that the J2EE APIs should reflect complexity as well as hide it by offering both implicit and explicit programming models.

An explicit programming model, by my definition, is one that reflects the complexity of the underlying system by offering developer very precise fine-grained control. An example of an explicit programming model is EJB, which gives developers a lot of control over how enterprise beans interact with their container system and serve requests. EJB is explicit, because it exposes a lot detail about the underlying system to the developer. An explicit programming model like EJB offers developers a lot of control, and therefore flexibility, but at a cost. Explicit programming models tend to be complex and difficult to master.

An implicit programming model, also by my definition, is one that hides the complexity of the underlying system. I can't think of any good examples of implicit programming models in J2EE today. All the standard J2EE APIs are pretty much explicit. Something that comes close, IMO, is the JAX-RPC Service Endpoint (JSE) component, which is really just a POJO (plain old Java object). The JSE allows you to develop sophisticated Web services but doesn't require familiarity with SOAP, http, or even the Servlet APIs. Its not prefect: You still have to know about the JNDI Environment Naming Context to do something useful, but it’s a start in the right direction.

Personally, I would like to see all of the J2EE components and APIs offer a simpler, optional, programming model. One that can be easily mastered by novices but allows users to incrementally leverage more sophisticated features as needed.