Page 1 of 2   next page »

The EJB Advocate explores various forms of loose coupling in service-oriented architecture, with a focus on when it is best to take advantage of the asynchronous processing power provided by message-driven beans.

In each column, The EJB Advocate presents the gist of a typical back-and-forth dialogue exchange with actual customers and developers in the course of recommending a solution to an interesting design issue. Any identifying details have been obscured, and no "innovative" or proprietary architectures are presented. For more information, see Introducing the EJB Advocate at the IBM developerWorks website.

Is your definition of loose coupling too tight?
Since this is the last article of 2005, this exchange about Java Platform, Enterprise Edition (Java EE) components other than session and entity beans seemed like a good way to summarize the year-long discussion conducted through this column and put the all of the components together into a complete service oriented architecture.

The problem: too much focus on sessions and entities in SOA

Dear EJB Advocate,
So far your columns have been all about session and entity EJBs for services, which is great for directly connected Java applications, like HttpServlets for Web based clients, or Swing applications for rich (we don't like to say "fat") clients. But we have heard that service-oriented architecture is all about loose coupling. Doesn't that imply using SOAP to provide language neutrality and asynchronous protocols that enable the client and server applications to run independently as much as possible? In other words, why haven't you talked much about JMS and message-driven beans?

Signed,
Feeling Disconnected

There are many aspects to loose coupling to consider
Dear Disconnected,
The EJB Advocate has focused on the services layers of the application and not much at all on the client side because I am a big believer in the old adage form follows function.

The reason is that many projects embarking on SOA fail because they get caught up in the implementation details before they have a good model for defining services in the first place.

This tendency is somewhat natural because most of the people I deal with on the subject of SOA are architects and programmers who know that the devil is always in the details and want to get down to them as quickly as possible. So, as soon as we agree that the attributes of a good service are that they are coarse grained, stateless, mediatable and adaptable (see Is it ever best to use EJB components without facades in service oriented architectures?), it seems obvious that session beans with data transfer objects will play a role in the implementation.

But that previous column leads one to question whether a session bean is necessary at all, introducing the possibility of using entity beans and their Home methods instead of session beans. Figure 1 shows both approaches being used simultaneously.

Figure 1 shows how the pure entity approach, enabled since EJB 2, has fewer components and a shorter path length when using session beans that pass through. A green box is used to represent the client, blue ones to represent various interface and facade classes. The orange box is the commonly accessed entity bean. The boxes are connected with double headed arrows labeled with the protocol used to communicate between the components; the blue ones representing Java calls in the same JVM, and the red ones representing connections that are remote (using RMI/IIOP in this case). The flow arrows are numbered to show the end-to-end flow, with A1-A10 showing the flow from the Java client through the session bean to the entity and back, and B1-B4 showing the flow from the client directly to the entity bean and back.

The programming model to retrieve the service interface used by the client is simpler too, although this is not shown in the diagram. Retrieving a session bean interface requires looking up the session Home in a JNDI context and using it to create a session; an entity Home merely needs a lookup, its methods can be directly invoked without creating a reference to an EJB Object. The following two code samples show the difference.

Figure 1 and the associated code samples show a real benefit of the Java EE programming model, whether or not you choose to use the entity Home method approach. The programming model changes incrementally and provides backwards compatability. In short, your best practices can evolve without forcing you to change existing applications. Also, the JNDI context provides a related aspect of loose coupling that should not be overlooked: implementation independence.

Remote interfaces to session or entity EJB components provide location independence. Using a remote interface makes it possible to deploy the client application and service components in the same JVM where it makes sense for the response time, throughput, and maintainability goals of the system, such as with a Web application using HttpServlets. Figure 2 shows just such a configuration, where an enterprise-quality application server, like IBM WebSphere Application Server, "short circuits" a remote interface to use Java and pass by reference when the client and service components are co-deployed (whether the service is implemented as an entity Home method or session bean). Flows A1-A6 show the use of an HttpServlet co-deployed with a service component. Flows B1-B4 show how it is reused by a remote rich client Java EE application.

But it sounds like you have decided that the most important aspects of loose coupling are language neutrality and asynchronous operations. And you are right that needing asynchronous operations will lead you towards using message-driven beans (MDBs) and JMS on the server side.

The approach that many programmers use when implementing a MDB is to invoke the EJB component representing the service through its remote interface to maximize location independence as described above.

Then, whether the service implementation is deployed remotely or locally, the purpose of the MDB is to serve as a simple adaptor, connecting an MQ layer into the EJB container where the service is hosted. JMS may be used by the asynchronous client application (if it is Java) or by the MDB (usually for the reply queue). Figure 3 shows this configuration as yet another input channel for our service implementation.

The flow C1-C2 is shown separately from D1-D6 to illustrate the independence of the client and server processes. C2 and D6 simply show an "acknowledgement" to the writer that the message was written and does not imply waiting. Listing 3 shows a typical structure of an MDB that should help clarify the processing that it must do:

The EJB Advocate would now like to get back to the issue of language neutrality that you brought up. It seems that you have tightly coupled the requirement of language neutrality with that for asynchronous processing. There is no reason that you cannot separate these concerns; the ability to parse a SOAP message and use it to invoke a session bean should be independent of whether the processing of that message is asynchronous (through MQ or another protocol over which JMS equivalent messages flow), or synchronous (such as through HTTP or even IIOP). In fact, some of the early "inventions" of Web services on Java EE applications used an HttpServlet to parse an XML message passed over HTTP. This approach eventually evolved to be SOAP/HTTP. Figure 4 shows yet another path that can be provided on top of the services implemented by an EJB component.

The Web Service Servlet and the Message Driven Bean could share the code that parses the data transfer objects from a stream extracted from the message string or HttpServletRequest. Similarly, the response or reply could share the code that generates a stream from the data transfer object (which could be an instance of Exception).

Hope this helps you understand the positioning of the Java EE components, all of which provide some form of loose coupling essential to a service-oriented architecture.

OK then,
Your EJB Advocate

Page 1 of 2   next page »