Do Your EJB Do Anything?
A Note Exploring Conceptual Approaches to EJB

 
Mainstream Enterprise JavaBeans (EJB) use follows a limited set of conceptual models based on two approaches: Component or Facade. This note looks at other loosely related conceptual approaches to EJB. There is no questioning the validity of the common idiom here. In fact, the alternates presented are speculative. I offer these alternative approaches with the goal of provoking a rethink of customary practice. EJB are frequently used functionally, with a minimum of architecturally strategic consideration. The downside of this may be lost productivity or poor performance. It is a rare day that there is no downside to starting with how instead of which, and to what end. This is not a balanced analysis or a narrowly directed argument. Rather, the value proposition of these new points of view is simply in pushing the debate to what, why and if as well as how.

EJB are thought of as components or facades (process APIs) to components. The basic concepts are distinct from similar sounding prescriptive implementation patterns—concepts are a way of understanding, not a pattern for doing (though the line between the two blurs). Components are self-contained, composable units of functionality. In the concept of Component there is a subdivision between business components and services. Business components are part of the domain model. Services often support the domain model but more frequently are infrastructure oriented (e.g. a scheduling service). A Facade or Process API is an interface offering services on a domain model. Facades also come in two basic flavors: smart and dumb. In implementation, smart facades follow the Facade Pattern but also wrap in discriminating business or service logic. Dumb facades simply act as an API and pass calls through to services or objects in the domain model. However, even dumb facades commonly contain significant amounts of procedural set-up and tear-down logic.

To distinguish between Component and Facade, we will call our three alternate ways of looking at EJB:

• Container MVC
• Aspect Oriented EJB (AOE)
• Discrete Layering

These takes on EJB could be seen as ordered in terms of conceptual simplicity, from low to high, but they suggest similar degrees of functionality. EJB modeled on Component tend to be highly functional, heavy beans. Facade tends to come with lower innate functionality. Looked at another way, Component is at one extreme, followed by Facade, with these new (functionally equivalent) conceptual approaches trending further towards zero functionality. After defining the alternatives we will circle back to zero functionality as a quality of EJB implementations.

 
CONTAINER MVC

The Model View Controller (MVC) paradigm is well-known to Web application developers. Very simply, MVC structures the application response, control plane, and data separately. Structural separation simplifies design and implementation, and enables the parts to vary independently behind interface contracts. In the typical application of MVC the view is comprised of HTML generating, page-compiled code (usually .jsp). Controller code is in servlet and/or EJB. The model is either a simple Java domain model or it is a set of EJB. In either case the model is primarily a reflection of data held in some data store, usually a relational database.

With a shift of perspective we can apply the same concept to the container, As shown in Figure 1, below. The usage is loose in the sense that MVC is a GUI application paradigm and here we are taking more general path. In Container MVC the model again is a reflection of the data the application supports (in this case the application is the container). However, in this case the data is the object and state structured by the EJB descriptor files. View in Container MVC is the EJBObject proxy to the model and associated state presentment (e.g. methods like: isRollbackOnly). The controller is the container itself. Actions taken on the view are checked, transacted, and delegated back to the model.

In Container MVC the application is abstract and the focus is on the container as proxy. Whether the Java bean that takes the proxied call is the bean hosted by the EJB framework or not doesn't technically matter. However, for the sake of clear separation of concern the application may be the delegate of a pass through EJB, reinforcing the proxy concept.

Figure 1. Application MVC and Container MVC in context

 
ASPECT ORIENTED EJB (AOE)

Aspect oriented programming (AOP) comes out of the Reflection family and focuses on isolating cross cutting behaviors. A cross cutting behavior is a supporting function that is tangential to the places it appears in the codebase. One example is event generation. An event is generated to notify any observers of that an action has taken place. All event generations will utilize the same code. This event generation code is intermixed with primary function code at every point where an event may be generated. If the event generation behavior is to be changed all locations of this event generation code must be found and modified. AOP seeks to mitigate this effect by locating cross cutting concerns in aspects that are applied declaratively across the application. These declarations name join points where aspect functionality is woven into domain features.

AOE is a simple and limited, but effective, way to conceptualize AOP in an EJB context. AOE takes the container as the aspect definer. Containers define several aspects, including:

• Object distribution
• Transaction management
• Security
• Pooling

AOE is not a strong AOP concept. Join point definition may be declarative, but, without tools for one-to-many mappings, it is not generalized. Aspects available are governed by the EJB specification and the container implementer rather than the application designer. Some powerful join point definitions are not available (e.g. on exception) and others are monopolized by the container. Finally, rather than transparently applying an aspect to a set of join points in the domain model, the application developer must explicitly reference EJB in order to bring the cross cutting behavior into play. Nonetheless, for several common application behaviors EJBs offer a productive AOP option. Moreover, applying a more general AOP framework to the domain model, as needed, is straightforward and should not affect the AOE layer.

 
DISCRETE LAYERING

Discrete layering is a simple style focused on creating clear separation of concern in the vertical axis. Most applications are explicitly layered by function. The lowest functional layers are likely to be message, network and persistence oriented. The domain model usually sits on top of these along with any services. Conceptually above the domain model will be application control and presentation. In distributed applications system services are required for distribution and naming. These and other facilities can be seen as foundation services or runtime environments—as is usually the case with EJB. Alternatively, these container provided services can be set up as an optional discrete layer above the domain model and control API. As a discrete layer the EJB provide service transparently without additional business logic and using the same method signatures. The domain model and application control plane retains its premiere place in the architecture with no change. The Facade concept fits well with discrete layering by simply placing the facade out of EJB scope behind the container services layer.

The advantage to discrete layering is increased flexibility and clarity derived from greater separation of concern. It is not infrequent that an API call will spawn subsidiary API calls that need not or should not call on the container services. A simple example might be a delete call against a distributed API that before committing must make dependent delete calls through the same API. In this case there is no reason for one distributed call to beget further distributed calls. Were the original API call made against a discrete layer, the knock on calls could be directed against the next lower layer with greater efficiency. The main drawback to discrete layering is the additional complexity of one or more additional layers. Whether or not this is an issue will depend largely on the quality of the tool support available. The familiarity of the development team with EJB and the structure of the application will also be factors.

 
ZERO FUNCTIONALITY EJB (ZFE)

Each of the above alternative concepts highlights the container services of EJB rather than involvement with application code. The clear bias of each concept is separating container driven declarative functionality out from the application control code and the domain model. The logical conclusion is that a proxy model, aspect, or thin tier exists with zero innate functionality. Under whichever alternative concept, zero functionality EJB is a practical single step beyond the current Session Facade Pattern—each of the advertised benefits of which ZFE exceeds.

However the benefit of ZFE increases quantatively as well as qualitatively. For significant adoption of ZFE one of two situations must obtain: 1. development is blue sky, or 2. the benefits of ZFE are substantially greater than other approaches and outweigh the cost of change. The latter may not be a certainty, but the additional benefits of ZFE are clear and should be considered:

• Enables local entry points (API calls routed through one or more services layers or dial direct)
• Eliminates EJB lookups below services layers
• Container not needed to drive domain model
• Complexity shifted away from domain
• Architectural approaches better zoned (e.g. MVC → ZFE → AOP → DAO)
• Conceptual separation between domain model, application services, and platform (or infrastructure) services

 
SUMMARY

This note outlines a set of alternate conceptual takes on EJB. Each conceptual model emphasizes EJB services as a gateway, decoration or behavior. The underlying suggestion is that with EJB, as with many things, less is more. Zero Functionality EJB was introduced as the beneficial outcome of following these concepts to a logical conclusion. This note is in no way prescriptive, rather it is exploratory, and it does not offer a balanced analysis of these concepts. The goal was simply to provoke valuable thought around reasonable constructs. I believe this goal has been met and look forward to comments on and criticisms or continuations of this line of thinking.