Enterprise Project
About Enhydra Enterprise
Project Mail Lists
Working Groups
FAQs

Software
Downloads
Documentation
CVS Repositories
Task List
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

Jay-too-who-eee?

By Brett McLaughlin

OK, ok, ok. You've backed me into a corner, bullied me, pushed me, and prodded me. I give in. I'm going to write what you want me to write about. You see, each month I spend about three weeks thinking about what I'm going to write my "Making Waves" column about, and about a week writing it (and yes, I do a lot more than this column, but you get the idea ;-) ). Usually I try to think of unique topics, things that might catch you by surprise, or up-and-coming Enhydra projects that I want to raise your awareness about. For example, I talked about open source last month, and tried to cast it in a whole new light; talk about what it really means to you, rather than to those guys watching the tech stocks. But this month, I'm writing about something that everyone who has my email address seems to want to hear about. I'm writing about J2EE.

If you're not sure why I might feel pressured to fire the laptop up for a J2EE article, you might want to read what I'll call the "opening act" to this little drama over at the O'Reilly webiste. It's an article I wrote about three months ago, where I made some pretty strong statements about J2EE; check it out here. I received more feedback, more public comments, more email (some of it pretty nice, and one where someone actually took a shot ay my mom!), and more general buzz than you would believe. Of course, this is a good thing(TM); I wanted to create a stir. But, I've seen enough people completely miss the point, or misunderstand what I said, that it has warranted me following the article up here. So read (or re-read) the first article, and come back and read the rest of this one.

So here's what we are going to do. Instead of just trying to answer all of the questions that folks asked me, which would be confusing at best, I'm going to start fresh, and try and attack this topic from a different point of view. Hopefully, seeing it from the O'Reilly article's perspective and then this one will help you zero in on what I'm saying. So first, I'm going to spend some time talking about what exactly J2EE is. Understanding the difference between J2EE, the platform, and the APIs that make up the platform, is critical to using J2EE and getting the point of the article. Second, we'll focus on exactly who J2EE is for; is it for developers, for vendors, for Sun? We'll take a hard look at this, and see what J2EE can do for you (and, of course, what it can't). At the end, hopefully you'll have a little better idea about the platform you're hearing so much about.

J2EE: The Platform
J2EE, or the Java 2, Enterprise Edition, is what is defined as a platform. What that means is that J2EE is more than just a collection of APIs. In fact, J2EE is itself much more than just an API. It is a complete programming model, and set of software. Currently, it consists of about 10 APIs developed independently, including JMS, JSP, servlets, EJB, JNDI, JavaMail, JTA, and so on. Now keep in mind that when you talk about J2EE, you aren't necessarily talking about these APIs. Confused yet? I can understand. Let's try and clarify.

If I'm using EJB, I'm not using J2EE. If I'm using servlets that talk to a database through JDBC, and send out messages with JavaMail, I'm not using J2EE. In fact, I can write an application using each of the APIs that J2EE subsumes, in the exact way that Sun recommends you use them, and still not be using J2EE. Doesn't seem to make much sense, does it? That's because you are still thinking about technology, and APIs, and software. J2EE is more than that; it's a platform. For me to be using J2EE, I have to go out and download or purchase a J2EE product, like Lutris Enhydra or BEA Weblogic. These are J2EE products if they have signed Sun's SCSL license, paid some fees, and are "official" J2EE licensees. Use a product like this, and you are finally using J2EE. So what's the magic? What's different about using all these APIs on your own from getting them from somewhere else? It's the control that Sun exerts over what you get.

Now I'm not going to go into a big rant about Sun being greedy and trying to take over the world. That's not what I'm talking about when I say control. What I'm saying is that Sun can guarantee, by virtue of the SCSL license, that the J2EE platform is made available in a particular way: each of the required APIs are included, at a certain versioning level, with a certain number of unchangeable interfaces and implementations. This ensures that every J2EE platform behaves the same way, no matter who you get it from. Now there are certainly add-ons, such as management consoles, deployment tools, and the rest. But these don't affect the core platform. This level of control also mandates what can "hook into" the J2EE platform. EJBs have established ways, through the ENC context, for example, to access other Enterprise JavaBeans, or a JMS queue. They don't, though, have a means of interacting with, say, a SOAP service. The ENC context does not provide an automatic mapping for this type of service, while it does for JDBC DataSources and JavaMail sessions. The result, again, is a guarantee of how application components interact. But we'll get back to this a little later. Suffice it to say that the J2EE platform is a snapshot of certain APIs, at a certain time, that are tied together through a vendor.

However, many of the APIs in the J2EE platform are available separately. For example, you can get the Jarkata Tomcat servlet engine and use it without ever touching J2EE; in fact, that's precisely what Enhydra Standard, the 3.x versions of Enhydra, do. They provide a programming model that is immensely useful for many, many applications that don't need J2EE. And it provides support for servlets, for JDBC, for JSP (heaven forbid! But that's another article.), and more. Did you get that? You can use these APIs without using J2EE! Even more importantly, a choice to not use J2EE is not neccessarily a choice to not use some, most, or all of the APIs that are a part of the J2EE platform. So when we go on to look at the many times that J2EE isn't appropriate in this article, as well as the times I pointed out in the O'Reilly article where it doesn't make sense, they are not knocks on JSP, servlets, or even enterprise technologies like EJB or JMS. Instead, it is a warning against the J2EE platform, and the snapshot that it allows you to work with. If you are starting to have some red flags raise about using J2EE, then I'm beginning to get my point across. Before I drive it home, let's look at who gains the most from the J2EE platform.

Well, let's get right to it. J2EE does not offer a benefit to the user, in a long-lasting way. The marketeers will tell you that the J2EE platform offers you all the APIs that you need to build enterprise applications; in fact, it usually offers more than you need! But you could get those APIs individually if you really wanted to, as we already discussed. So what you gain from J2EE is, apparantly, a bundled set of APIs. But what does this "gift" actually come wrapped in? Well, just as it is a nice, neat, bundle, it is also a rigid, constraining, bundle. If you're an EJB guy, you're probably anxiously awaiting EJB 2.0. The new spec details tremendous improvements in CMP entity beans and in JMS integration. So let's say EJB 2.0 comes out in January of 2001. Does this mean you can use it in your J2EE applications? Absolutely not! You have to wait for the next release of J2EE (1.3 or greater), or you violate the agreement you have with your vendor, and the agreement that vendor has with Sun. You see, J2EE is not a set of legos that fit perfectly well with other lego sets. You can't buy the moon base and the exploration buggy and combine them to add a helipad onto your moon base. The bundle that you get in J2EE is not one you can change. You wait for the platform to upgrade, or you must abandon J2EE. Of course, you probably just spent 15 or 20 grand per processor (unless you got smart and went with Enhydra 4.0!), so that's not really feasible, is it?

So who's benefiting here? Well, it's not the small application server vendors. The SCSL license and J2EE in general is still that bundle, remember? Now you don't have the option, as a J2EE licensee, to hold off on version 1.3 of the spec, and hone your 1.2 implementation. You see, once a new version of the spec is out, you cannot continue to update, patch, test, or even brand your older version of the implementation! It stays untouched (with all the problems that even the finest tuned software will have), or it no longer can be called J2EE; if you want to have a J2EE product with bug fixes, you must move on up to the latest specification version, at start there. Not too flexible, is it? So now you have to abandon all efforts, at least temporarily, on things like SOAP, BXXP, data binding, and the rest to push forward on the next J2EE release. Otherwise, well, you're in legal-land, which nobody wants to stay in very long. Again, it's all about control - once you sign on to J2EE, you're on a very inflexible road, one that may wind and twist, but that you can't step off of without huge penalties.

Well, who's left? Big server vendors (one of which, by the way, is iPlanet, and we all know who owns iPlanet along with Netscape, don't we?). These companies aren't driven by user-need or adding value to their product, they just roll out version after version of the J2EE platform. Spec upgrade? No problem; we aren't adding things to our platform, so we've got plenty of people sitting around ready to upgrade our product. Join these newsgroups, or mailing lists; the most common reply is either "Contact support" or "That's not in the specification, so we don't support it." Of course not; they're too busy keeping up with the next version of the specification!

J2EE: The Point
Do you see that the platform makes the developer the ultimate loser? While perhaps you are happy with J2EE now, what about when you need something not in the platform? How about a SOAP implementation that you can have tight interaction with from your EJBs? What about a logging service shared across all server components? What about timing across multiple servers in a cluster? What about a project like Enhydra? This is what it boils down to. We can focus on adding SOAP, XML-RPC, BXXP, logging, timing, data binding, and a huge number of services to the Enhydra platform. But in the background, we're getting pushed, prodded, and stretched on the rack that is the J2EE platform. You see, we can serve you, the user, or serve J2EE, the platform. Right now we walk the tightrope of giving you a top-notch J2EE release and services, but those value-adds, those services, take a much longer time because of the concentration on J2EE. And that's fine; we know you want J2EE. But we, as developers, need to start letting Sun know that the premise that J2EE was built upon, flexbility, seems to have been forgotten. Is this about developers getting the tools they need, any tools (even if not developed by Sun), or about big companies getting big servers with big price tags that don't do anything well, but dadgum it, they adhere to that J2EE platform! You have to make that choice, as I do. And I choose to use the parts of J2EE that make sense, but use them very cautiously; and more importantly, I continue to try and educate people, in the hopes that it begins to filter back to Sun. I want a platform that is based purely on the notion that services, be it EJB, JMS, data binding, SOAP, or anything else, no matter who comes up with them, are key. A framework that supports those services, and allows me to add, remove, and update services when I want; now that's a platform! Soon we'll be sharing tremendous strides that we are making towards Enhydra being that platform; but for now, think long and hard about J2EE. What it is, what it isn't, and the price: both the visible one, and the hidden one. I hope I've made you think; see you online!

Brett McLaughlin is the author of Java And XML, published by O'Reilly. He currently specializes in building application infrastructure using Java and Java-related technologies. He has spent the last several years implementing these infrastructures at Nextel Communications and Allegiance Telecom, Inc. Brett is one of the co-founders of the Java Apache project Turbine, which builds a reusable component architecture for web application development using Java servlets. He also contributes to the EJBoss Project, an Open Source EJB application server, and Cocoon, an Open source XML web-publishing engine. His projects all focus on XML and the J2EE platform in mission-critical, high-performance distributed systems. Brett has recently been appointed Enhydra Strategist at Lutris Technologies.