My 2 1/2 year old son has a birth certificate on his door that says "native Texan." Now I've lived in Dallas for several more years than those he has covered in his short stint on this planet, but that doesn't make me a native Texan. I am in a strange state of flux right now. I am originally from India, have lived in Dallas for about 11 years and have a house there, am living out of Denver for a few months, and I spend five working days in Milwaukee every week. While my son is a full-compliant U.S. citizen, I can proclaim some compliance. I guess I can also call myself a Milwaukee resident.

There are varying degrees of compliance, and the definition of compliance in any environment is very much dependent on how much leeway that environment offers you. On page 6 (in this issue of JDJ), Nigel Thomas talks about how J2EE is becoming too big as a platform and how this creates unnecessary cost and complexity for assembling specialized applications. One of the steps that Sun had taken toward simplifying the complexity of the Java platform was splitting the platform into three editions - J2EE, J2SE, and J2ME. Now, J2EE is just a layer on top of J2SE and therefore is not really an autonomous edition of the platform.

The J2EE Blueprints provide a definition of what it takes to be a J2EE application. In a nutshell, if your application is comprised of J2EE components, then it is a J2EE application. And your component is a J2EE component if it runs inside a system-level enterprise entity called a J2EE container. Customization of the application is achieved by a deployment descriptor. The container can be a Web container, an EJB container, and so on. However, when you design your application, it's usually neither feasible nor desirable to convert all existing components to run in J2EE containers. After all, the majority of the systems were written before Java came along and there's no way everything will be converted into a Java component.

However, J2EE allows your application to be called a "J2EE application" in several ways. The Blueprints describe several application scenarios ranging from applications that use both the Web and EJB components, through applications that are built on only one of the two types of components, to standalone clients that use neither Web nor EJB components. If your application falls into any of these categories, it's a J2EE application. Typically, enterprises rarely use all the component types offered by J2EE. So, when an organization decides to move their legacy systems to a J2EE environment, what is it that falls under such initiatives? If they develop standalone clients that talk to legacy systems via some Java wrappers, does that make the application suite a suitable candidate to be called a "J2EE application"? Or if they develop a Web front to mainframe systems, does that constitute a J2EE application? Or if applications running a JVM communicate with legacy systems via a messaging bus (not JMS), does that make it an application worthy of the Java 2 Enterprise Edition? How much of the E in the J2EE does it really take?

From Sun's perspective, a Java drop in a non-Java ocean is a feather in the cap, and an organization is announced as another satisfied customer that has happily adopted J2EE. However, the benefits of the J2EE platform are really evident when the Java distributed object model and the Web components become a part of the platform migration.

As for Web services, obviously this new paradigm for achieving application integration has made its way to the J2EE umbrella. Hence the delay in the release of the next version of the platform. Is it time for Sun to take another stab at reducing the complexity by splitting up the J2EE platform? Is it time for a J2WSE?