JavaDev'06: ESBs Will Turn Devs into Integrators

Beginning this week, Integration Developer News begins our countdown to JavaOne 2004 with a series that poses the question: "What changes are coming for the career Java developer in the next two years?" This week, Dave Chappell, one of Java's foremost experts on JMS and integration, spells out why Java devs needs to think "outside the stack," to learn skills that will better tie Java into .NET and other non-Java platforms. The Enterprise Service Bus, he says, will transform how Java devs think about APIs, data sharing and workflow.

Tags: Java, Integration, ESB, Chappell, Standards, Developer, Bus,

by Vance McCarthy
Dave Chappell, as one of the industry's prominent JMS visionaries and hands-on architects, and chief technology evangelist at Sonic Software, says now is the time for Java/J2EE developers to think "outside the J2EE stack" and get acquainted with what will be the next step in Java-to-non-Java integration.

"One-hundred-percent portability is getting more difficult to achieve, as Java is fragmenting already," Chappell said. "And while there is still a core set of [Java standards] that depend on the JCP, engineers can become more marketable if they can understand how Java can work in a cross-platform, service-oriented integration environment."

The solution, Chappell says, is the Enterprise Service Bus.

This summer, Chappell's book Enterprise Service Bus (to be published in June 2004 by O'Reilly) will offer architects and senior developers their first definitive look at how the ESB may change their company, and their careers. While emerging specifications for interoperability continue to evolve, Chappell says J2EE devs should keep a close eye on ESBs, and get ready to exploit them and the technologies they use and connect to (including XML, XPath, SOAP, JMS and even C#).

"If a developer focuses on making sure his silo is the best in the enterprise, and he's not also focused on making sure that his silo is built to integrate, then," Chappell told Integration Developer News,"he's headed for problems because new applications that are being built today should be built to integrate using standards-based interfaces."

Chappell says Java devs who want to avoid a stall in their career should set their sights on becoming "integration architects." This new high-visibility, high-reward job will shake Java devs out of their silos, helping them blend their current Java talents with new web services skills that can link Java and non-Java assets (app logic, data and business rules).

In that vein, Chappell also sees that ESBs may actually provide a way for the Java community to get back to core basics, by offloading current and future complex functionality from the baseline J2EE spec.

"The future of the J2EE stack today can't continue to grow and advance as well as it once did," Chappell says, "if everything that gets added to it has to be part of that stack, it takes too much time. The stack is too heavy and rigid, , which makes the certification process only attainable to a handful of vendors. This doesn't necessarily provide a fertile environment for fostering innovation.

Inside the "Developer-as-Integration Architect"
The word "integration" can raise the hackles -- and anxieties -- of many of today's Java developers. But Chappell says that ESBs will provide Java devs an easier way to perform complex integration tasks without making them learn every nuance about every back-end system (Java or non-Java) they need to connect with.

The ESB, as Chappell envisions it, is a powerful "enterprise architecture for a highly distributed integration network," encompassing a wide range of integration capabilities including routing, data transformation, loosely-coupled data exchange, and the separation of application logic from business processing rules.

Further, ESB will likely not even be built up from 100% Java code, Chappell said. While ESBs will leverage some new Java standards, such as JSR 208 [for Java Business Integration], they'll be built on core cross-platform standards such as XML, WSDL, XSLT, and various security standards. But, Chappell adds, no matter how much core Java code makes up the ESB, the focus of the ESB will be Java-outward, rather than deeper and deeper knowledge of Java/J2EE APIs, Chappell said. And, he added, it's a shift in thinking outside the Java silo will benefit Java devs.

ESBs Update Pure Java-Driven Integration
Chappell says that the standards and technologies that will comprise an ESB have matured enough that it's safe for Java devs to begin thinking about leaving 100% Java-driven integration behind.

Traditional Java messaging and middleware approaches, he says, focus on "one point-to-one-point" or "one-to-many" data transfers. These approaches do not easily upgrade to a services-oriented architecture "many-to-many" approach for sharing data, as well as higher-level application and business logic as services.

Chappell cites five (5) reasons why CIOs will consider using ESBs, and shift away from traditional integration approaches: