Java Development News:

Understanding Messaging for the SCEA

By George Lawton

02 Apr 2010 | TheServerSide.com

Understanding Messaging for the SCEA

Java enterprise architects unfortunately have too many choices to consider when integrating Java applications. But with a little of study, and more importantly knowing what to study, you will be well on your way to becoming a Sun Certified Enterprise Architect for Java EE.

 

There are a few important technologies to understand thoroughly and many that have been deprecated. The recently released Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition by Mark Cade and Humphrey Sheil greatly simplify the Java Messaging landscape. In chapter 5, they explain in detail which standards matter, which don’t, and why.

 

Web Services using SOAP or basic XML over HTTP is the preferred way for integration Java and other applications together or Java applications across company borders. Read Vinay’s study guide for more info on studying and working with Web Services

SOAP and RESTful (Representational State Transfer) programming patterns are the preferred design patterns for WS. SOAP adds more information, but is more complex and with more overhead. RESTful programming is simpler and has less runtime overhead. Paul Prescod provides a rather rich background on the SOAP/REST Debate. JAX-WS 2.0 and JAXB are the most important things to understand.

 

JAX-WS is the primary Java API for SOAP and RESTful web services, and is the preferred way for accessing Web services in EE. Read the official introduction to JAX-WS 2.0.

 

JAX-WS uses a variety of lower level APIs including:

JAXB, (API for XML Binding). Heavily used by JAX-WS. Without it a lot of time is spent marshalling and unmarshalling code between XML representations and Java Objects. It is heavily used by JAX-WS. Check out the SDN tips on JAXB.

SAAJ (Soap with Attachments API for Java), Read an IBM Developerworks SAAJ Tutorial.

 

JAXP (Java API for XML Parsing), Learn all about JAXP and  StAX (Streaming API for XML). The reference implementation is at Codehaus.

 

Java Messaging Service (JMS) is the core messaging alternative for Java to Java apps, and is not Web services based. It is preferred when the developer controls the message consumer and producer. It is the most important technique for messaging between Java apps, and architects should clearly understand its mechanics. It can be glommed into other apps built with .NET or legacy apps using JCA, but it breaks easy when changes are made.

 

JCA, the Java Connector Architecture is less common than WS or JMS, but it still has its place in providing a connector for legacy applications. It is more commonly used by companies to extend the life of older applications. Developerworks has a nice overview on understanding JCA Transactions.

 

Handle With Care

You just need to know why you need to avoid JAXR and JAX-RPC:

JAXR -- Java API for XML Registries. At one time people envisioned it to create system architectures on the fly to meet business requirements.  “Time has moved on and we know that people do business with people, not with web services.”

 

JAX-RPC, a Java API for XML-based Remote Procedure Call. It has already been effectively replaced by JAX-WS, which is now the primary Java API for XML-based services.  The only important thing to know is why JAX-WS is better. For a better understanding of these advantages read what Johan Eltes says about advantages of JAX-WS over JAX-RPC