The WebPreferiscoPreferisco Blog
Home Services Portfolio Blog Contact Casa dei due Mori

What is J2EE 1.4 all About Then?

First published in SpiritSoft Digital Newsletter, September 2002


Now that we have a final J2EE 1.4 specification - though the reference implementation won't be ready until early 2003 - it's worth identifying some of the key themes behind the new version. The inclusion of Web services and enhancements to the J2EE Connector Architecture make J2EE 1.4 a key component in distributed application development, and there is a renewed emphasis on messaging (using JMS and SOAP) and loosely coupled architectures. This article explains why these themes are so important for businesses and developers needing to deliver reliable, available and secure business systems; it updates the J2EE versus .NET scorecard, and anticipates some future directions for the platform.

Loosely-coupled integration

The first thing to appreciate is that it is impossible to overstate the importance of adding loosely-coupled component based integration.

Tightly coupled synchronous integration - whether RMI, XML-RPC or any other mechanism - causes client and server to be close-coupled or "brittle". Changes to the server interface have to be reflected in the client; problems accessing the server cause the client to block. As systems grow larger and more complex, it's harder and harder to scale up this approach.

A service-oriented architecture imposes clean fire-breaks between islands of functionality. Asynchronous "document-centric" message-based integration offers separation of application components - each of which can be owned, developed and deployed autonomously - either because different organizations are involved, or simply because the best of breed application components used to construct a single business application may use different technology platforms.

Different document centric components can have different development life-cycles, languages, platforms. So you can mix and match your 30 year old mainframe systems - using MQSeries to kick off CICS transactions - with your J2EE/Unix, Windows/.NET and any other legacy processing.

Using message-oriented middleware, it's easy to plug these components together. And because it's easier, that makes it cheaper too. Interfaces tend to be simpler and cleaner - that discourages the spaghetti interconnections typical of multi-threaded programming and drives towards a true loose-coupled approach. You can assemble systems from best of breed pieces, which may be hosted in different departments or even companies. Management of each component is autonomous - each can be separately scaled, replicated, or replaced. Easier integration also promotes more frequent re-use rather than redevelopment of components.

Web services and J2EE Connector Architecture

J2EE 1.4 finally adopts Web services and enhances the J2EE Connector Architecture (JCA) to make application integration within and between enterprises much more straightforward - and scalable.

As we all know, the basic Web services technology - SOAP, WSDL and UDDI - supports straightforward integration using XML based remote procedure calls between functionality on all kinds of platforms - Java (whether Micro, Standard, or Enterprise), .NET, and any kind of legacy system from Adabas to Z/OS, IBM's renamed OS/390.

But as well as that, SOAP supports document-based interactions - asynchronous XML messaging between organization units. This brings all the benefits of loosely coupled document-centric processing to inter-organization integration, whether between businesses, or simply between different departments. And now the two parties to a conversation don't need to agree on a specific vendor, or even on a technology platform. They only need to agree on lowest common denominators - HTTP for the transport, and XML for the format so that systems at each end are protected against evolution to document contents.

J2EE now combines document-centric Web services with JMS and so offers a complete end-to-end messaging and integration backbone, supported by standards based routing and filtering components - which can be based around Servlets and JSP.

J2EE Connector Architecture 1.5

Meanwhile, the latest version of JCA provides support for bi-directional, asynchronous interactions between a J2EE server and resource adapters. Resource adapters give access to "Enterprise Information Systems" - typically packaged applications like PeopleSoft, SAP and Siebel. Now J2EE itself - rather than proprietary stand-alone EAI tools or "added value" integration components - provides the basic message-based integration framework - layered over JMS - and the slots for EIS-specific adaptors.

And of course the JCA adaptors can themselves be exposed beyond the J2EE platform using Web services technology - so that the integration framework can be extended beyond the single application server to other departments and business partners.

Is J2EE 1.4 ready for prime time?

Although there have been delays in bringing J2EE 1.4 to market - the final release is not expected until next year - at least vendors have been bringing many of the key components to market to jump start adoption - at least for those pieces which can be retrofitted into J2EE 1.3 app servers. This does involve a small risk for early adopters - what if the interfaces change substantially? Nevertheless, the early release of final specifications from the Java Community Process should minimize future compatibility problems. We just have to be a little careful about some of the vendor specific developer tools - not covered by standards - that are being used in some cases to help drive this early adoption.

How's the J2EE vs .NET scorecard?

As J2EE 1.4 components hit the streets, we can begin to see a change in the balance between Java/J2EE and Microsoft .NET. Not only is J2EE catching up on the Web services front - one aspect of .NET that helped it gain early mind share - it is continuing to lead as a server platform, while there is increasing confusion over .NET hype versus reality. J2EE's management standards based around JMX will make it even easier to coordinate enterprise systems across multiple vendor, global systems. And J2EE provides the full range of enterprise class facilities - along with reliability, availability, security and most of all scalability.

Where Next?

What we still need from J2EE is increased standardization in application development and initial deployment - to remove the ever-present danger of vendor lock-in - and improvement in the ease of use of development frameworks. Whenever developers gather together to discuss Microsoft and .NET, it's the user experience - especially for less experienced developers - that is most seductive. Let's hope that efforts like Eclipse - all outside the J2EE program - will soon bring the Java world to the same level of productivity in system development tasks.

And perhaps Sun should give some thought to breaking up J2EE development into smaller chunks. Aggregating so many new and improved standards into a single release does tend to slow progress to the pace of the slowest. Sure, some of the standards are interdependent, but others aren't; perhaps next time the J2EE process can learn from Extreme Programming practices and organize a series of easier to control "sprints" rather than another 18-24 month marathon.

Copyright © 2000-2013 Nigel Thomas, Preferisco Limited. Last modified [an error occurred while processing this directive].