What Is Right for Me-JAXM or JAX-RPC?

A question commonly asked by architects while developing distributed applications is centered around the guidelines for using synchronous/asynchronous communication or JAX-RPC/JAXM. Typically, this mutates into the traditional and unproductive RPC-versus-MOM argument. In reality, neither messaging nor RPC is better. Each plays a different but significant role and is relevant to Web services architecture.

A successful realization of the tightly coupled RPC-driven model is n-tier architecture, where the presentation tier (e.g., a servlet) communicates using RPC with the business tier (e.g., an EJB), which communicates with the EIS resources on the backend. Microsoft's DNA is architecturally similar to ASPs and COM+. In essence, RPC systems are coupled, synchronous, and usually deal with multiple fine-grained operations (remember, a single SOAP message can contain only a single RPC call). However, this does not mean that everything synchronous can be implemented only with JAX-RPC. Recall how point-to-point messaging is synchronous.

A fundamental concept in messaging is that communication between applications is asynchronous and via some middleware. Once a message is dispatched, the sender can continue about its business; the middlware takes care of delivery. The reply to that message, if any, arrives asynchronously and possibly much later.

Another aspect needed for successful communication is reliability though guaranteed delivery. The store-and-forward mechanism, where a provider persists the message until it has been successfully delivered, offers high availability and quality of service capabilities for business applications. This does not mean all asynchronous applications have to use messaging. In Chapter 10, we saw how one-way invocations can be dispatched and how asynchronous systems can be built (with some work).

Also, the underlying transport and the communication styles are mutually independent. JAX-RPC-based blocking or nonblocking invocations (either encoded or document style) as well as JAX-M-based blocking and nonblocking messaging can be implemented over both synchronous transports, such as HTTP, and asynchronous transports, such as SMTP.

We have discussed synchronous messaging and asynchronous messaging with JAXM earlier. In Chapter 10, we also discussed synchronous and one-way invocation and how to implement asynchronous communication using compound messages. Both APIs support SOAP 1.1 with Attachments.

So, what should architects use? In general, we believe the following guidelines to be appropriate for developing Web services with the Java API today:

1. At present, JAX-RPC should be a primary choice for application design, especially if more than one of the criteria below is met:

   • The application design is based around synchronous behavior.

   • The application design can support a blocking call.

   • File-and-forget invocation can suffice.

   • The service must be exposed and published in registries. JAXM now and by itself offers no support in this area.

   • Multiple recipients for a single invocation are not required.

   • Document-centric communication is required. Given the current state of various choreography and orchestration specifications, vendor support, and the assumption that most service consumers will reside in J2EE-capable containers that are themselves capable of hosting JAX-RPC endpoints, we believe applications-based compound message exchanges can be architected with JAX-RPC using attachments. There is no doubt that doing so involves a greater degree of complexity and design.

2. Use JAXM with a messaging profile such as ebXML when

   • Asynchronous messaging is required and the message exchange in a business context is closely associated with reliability and guaranteed delivery, possibly to multiple recipients. Applications can be architected with JAX-RPC for asynchronous behavior using compound messages, but the store-and-forward services offered by a messaging profile-provider combination must be developed by architects. In Chapter 10, we briefly discussed a server-side architecture that used such an approach.

   • The application design is centered around callbacks, long-lived business transactions (e.g., spanning days), or a conversational message exchange model.

3. Using JAXM without a provider.

   • We do not believe this is a viable deployment for applications (on the client or server role), because it dictates synchronous behavior for which JAX-RPC is better suited.

4. Using JAXM as an interface to JMS.

   • One approach to achieving reliable, asynchronous messaging is to provide a reliable messaging protocol at the SOAP level, such as ebXML. (See Figure 11.38.) Another approach is to use a higher level of abstraction, such as JMS, for its guaranteed delivery semantics. We discussed SOAP over JMS earlier in the chapter. In fact, the first generation of JAXM implementations are from JMS vendors such as Sun ONE MQ, BEA, and Sonic MQ, who have chosen the logical route of exposing their existing JMS messaging bus and infrastructure, using one of the following techniques from a high level:

     • Using SAAJ and enhancing the transport layer to support HTTP. This combination gives service consumers asynchronous capabilities. It also provides JMS benefits, such as guaranteed delivery, reliability, and scalability of the MOM transport, and works around the firewall issue.

     • Exposing JMS destinations as SOAP services and using the JAX-RPC Call API to invoke them asynchronously from the clients.

     
     Figure 11.38: JMS providers using SOAP

In the former approach, the wire-level message format and service implementation are specific to the vendor implementation. The latter is closer to the JAXM model, in that even though the server role is tied to a particular vendor implementation, the clients are not, and the service can be described as a traditional JAX-RPC service using WSDL.