J2EE is dead, long live Java.

J2EE™ from its inception has been plagued by two characteristic problems:

  1. A least-common-denominator approach to APIs
  2. Lack of sufficient abstraction supporting high level development

Not that there aren't plenty of abstraction layers, the number of abstraction layers is mind-boggling, but there's no layer that enables you to actually get high level work done. To work in J2EE you need additional frameworks, along with complexity mitigation via IDEs, build tools, mapping tools, runtime interpretation tools and other help. This works, but it's not efficient, so it tends to be high cost.

To deal with this high cost, many companies turn to outsourcing to take advantage of lower labor costs. So basically the API designed to sell application servers is now driving offshore development. And as you might expect, many of the companies selling application servers sell global services.

J2EE is dead

Given that standard J2EE essentially guarantees complexity, many people are actively seeking alternatives like:

In either case standard J2EE development seems dead, or at least limited to those who can afford the development. Eventually maybe incremental improvements to J2EE, the frameworks, add-on tools and IDEs will all converge into the best solution ever, but that hasn't happened yet. There are even those claiming that Java itself is toast, or limited to large enterprise server development, essentially becoming the modern day equivalent of Cobol.

Long live Java

Java is not Cobol. It has two major things going for it:

  1. The core language itself is actually quite reasonable, even great.
  2. There are APIs to connect to nearly everything you could possibly want, and adaptors for everything else.

The trick is how to make use of this raw material for both small scale and large scale development, while minimizing complexity.

Since a distributed application can easily be run on a single computer, but splitting a monolithic app across multiple computers can be hard, a unified approach would be geared towards distributed development, handling the small monolithic application as a simple degenerate case.

Message oriented architecture

How do we build distributed systems? Message oriented architectures. Message oriented applications are built from data messages that flow between application component modules. Large scale distributed systems use a messaging server, small monolithic applications can use direct procedure calls. Message oriented architecture provides a unified mechanism for software development.

Java/J2EE provides multiple APIs for messaging, depending on whether you want to connect over web services, JMS, FTP, sockets, or other mechanisms. Historically J2EE support for message-oriented architectures has been secondary to support for controlling distributed transactions, so building a message-based application can be confusing unless you lay some groundwork first:

  1. Nodes are application components that receive and generate messages.
  2. A Configuration describes the messaging "switchboard" of how messages flow between nodes.
  3. A Messager handles the actual node communications, so application code doesn't need to be concerned with the underlying messaging mechanism.

In the process of setting up these basic framework components, other design considerations will come up. Notably the data definition, which now has a runtime object form, a database form, a messaging form, and probably a user interface form. One end result of these considerations is Structs and Nodes Development (SAND).

For more information, see the FAQ, the sandev.org project, or contact us

See also: Enterprise Integration Patterns
Java and J2EE are trademarks of Sun Microsystems, Inc.
Kool-Aid is a registered trademark of KF Holdings.
Other company, product and service names may be trademarks or service marks of others.

© 2006 SAND Services Inc.