J2EE is a great thing. As a rich collection of technologies to support the development and deployment of server-side business logic written in Java, it is a total marvel. Here at Cape Clear, we believe that while J2EE is great, it isn’t the answer to every problem, specifically it is overkill as an infrastructure to deploy Web Services. This article explains why.
Web Services Are from Mars, J2EE Is from Venus
Before getting into the red meat of this discussion, it is worthwhile making one key
point: J2EE is a great platform for *building* new applications. Web Services, on
the other hand, are really about solving the integration problem. Therefore, to some
extent comparing J2EE and Web Services is akin to comparing apples and oranges.
However, since the J2EE vendors insist on mixing these things up, let’s continue…
The J2EE Hegemony
The J2EE vendors have done a fantastic job of convincing the world that you can’t run a line of Java unless it runs inside a J2EE container. This is just pure bunkum. The vast majority of Java, especially server-side Java, runs inside a servlet engine. There are plenty of great servlet engines, such as Jetty (www.jboss.org), that are not only better than the servlet engines you’d find inside your typical application server, but they are also free.
J2EE is an environment with over 6,000 APIs. It is a complex environment, and getting more complex everyday (J2EE 1.4 anyone?). Now, if the problem you are trying to solve is a fundamentally difficult problem, such as the need for tight transactional guarantees among a large set of distributed business logic components, you need a complex environment to help you solve that problem.
However, over time J2EE has suffered from the traditional ailments that can best be described as “if all I have is a hammer, then everything looks like a nail”. Worse, if I have a hammer and need to put in a screw, then adding a screwdriver head onto my hammer is not a great idea. (For more on this read the JCA specification!) Unfortunately, therefore, over time J2EE has been bloated with extra APIs and functionality.
The most recent example of this is Web Services. When Web Services emerged on the scene in 2001, all of the J2EE vendors rushed to bolt on Web Services functionality. There may be some technical merit to this, however in doing so, the J2EE vendors have obscured some of the core advantages of a Web Services architecture, while simultaneously trying to convince the world that you can’t possibly imagine running a Web Service without having a full-blown J2EE environment underneath it.
The Web Services Orthodoxy
So, if for just one moment we can extract Web Services from the J2EE embrace, it becomes possible to view some key characteristics of what a Web Services architecture is all about.
At Cape Clear, we believe there are four fundamental characteristics that define a Web Services architecture:
1. A Web Service defines a business process, not a technology implementation.
Web Services are technology-neutral. They don’t impose a programming model – they can be written in .NET just as easily as in Java. By their very nature, Web Services therefore encourage people to think more closely about the business problem they are trying to solve rather than the underlying implementation technology.
2. A Web Service should not require high-end computing skills to build or to use.
The whole point of Web Services, as far as Cape Clear is concerned, is to enable rapid and simple creation and integration of “business services” by people who understand the business problem. We believe that Web Services products should be useable by the vast majority of developers, not just the few who understand the magic incantations of J2EE! Web Services are much, much more than just an XML wrapper for EJBs.
3. A Web Service resides at the “network edge”.
Web Services by definition live at the edge of the network. They are an entry point. Web Services are not where you write your core business logic. The role of the Web Service is to tie together, or orchestrate, various back-end pieces of business logic into a single business-oriented service. Therefore, because a Web Service isn’t itself hosting the core business logic, you don’t need a steam-belching J2EE container to host it. This means that you can use lighter-weight technologies, such as plain Java or server-side JavaScript, to do the “light lifting” in the Web Services tier.
4. A Web Service is “document”-oriented.
Finally, and most importantly, a Web Services architecture is predicated on the notion of documents. Most J2EE developers are familiar with programming language concepts. They tend to see everything as Java classes and Java datatypes. This is all fine when you are building back-end business logic. However, the real world, where real business problems live, is populated by documents, forms, contracts, and people. Think of SWIFT, ACORD, HL7, and so on.
Web Services is the first honest effort to build a technology that models real world entities. The power of the document model in Web Services is without doubt the most profound and subtle change to the way in which we think about building applications. And documents are one thing that J2EE isn’t set up to process.
Three Chords and the Truth
Therefore, Cape Clear believes that J2EE is great – if you have a complex problem that needs a sophisticated back-end environment to host your business logic. J2EE is the Java equivalent of a mainframe.
However, if you’re using Web Services to solve business integration problems (and most of those will involve legacy systems other than J2EE), the simple combination of Web Services standards, Java, and a servlet engine are all that you need and all that you’ll ever need.
Further Reading:
- Clear Thinking with Annra
- ‘3 Click Integration’ Webinar: Stop using EAI and J2EE for Integration
- Cape Clear Whitepapers
Annra O’Toole, CEO, Cape Clear Software
OToole drives the overall vision and corporate strategy for Cape Clear
Software http://www.capeclear.com/. He joined Cape
Clear in November 2000 to participate in the major opportunity being created
by the emergence of the Web Services technologies and the massive benefits
they could bring to the challenges of creating and
integration applications. O’Toole co-founded and served as Chief Technical
Officer of Iona Technologies, prior to joining Cape Clear. He holds an MSc
in Computer Science and an Electronic Engineering degree from Trinity
College, Dublin.
