They say no man is an island. For J2EE I would say no platform is the universe. Sometimes folks misunderstand the promise of J2EE. It won't replace every other development paradigm. J2EE application servers won't make all other deployment and runtime environments obsolete. And Java won't be the only language people program in. Java's strength is facilitating development, but it isn't the first and last thing of the programming world. You can use J2EE to build enterprise applications, but you can't use it to build the enterprise itself.

The distinction is important. When you write enterprise applications, you model a portion of the enterprise. You basically take your organization/division/group's core technology offering, identify the section of an enterprise's business process that you choose to model, and then go about building the application.

If J2EE is your platform of choice, and I hope it is, you build the business components and the application logic using a J2EE application server and J2EE APIs. However, this application provides a piece of the bigger puzzle. The rest of the application environments you connect to may use J2EE too, or a portion of it, or be totally independent of J2EE.

So how do you connect to non-J2EE environments? Well, depending on the boundaries of the "J2EE box" you've identified, you define the integration points. You then use a combination of the facilities offered by the J2EE platform and other cross-platform technologies to talk to the outside world.

At the front end these technologies could include servlets and XML. These APIs allow you to present to the client in a platform-neutral way. At the back end J2EE offers connectivity to third-party systems through various technologies. J2EE provides connectivity to enterprise information systems (EIS) through the recently released Java Connector Architecture (JCA).

With JCA your application can step outside the J2EE box to conduct business with third-party legacy systems. The vision of JCA is that standard connectors will be developed that allow Java environments at one end to communicate with legacy environments at the other end. However, JCA implementations are still immature and the resource adapters still need to grow up. JCA currently competes with more offerings from mature vendors - such as WebMethods and Tibco - that directly connect to ERP systems and already have sets of predefined adapters. The only catch is that when you use these vendors' offerings, you also end up using their proprietary execution environments.

The term proprietary is relative. The moment you choose a particular application-server vendor and a particular resource-adapter provider, you end up using particular implementations. But, as an enterprise developer, the good news is you continue to develop using standard Java APIs that can apply across different vendors.

Since the J2EE application-server vendors are extending their containers to support connectivity via JCA, we can hope that a couple of years later the connectivity layer to EIS becomes a standard commodity. The actual realization of this promise, of course, will take a bit of work. Plus it will be a hard sell for a company to bundle both vendors' offerings to a single customer.

An interesting development in the marketplace is the partnerships emerging between the J2EE application-server vendors and the EIS connectivity providers. One of the primary partnerships recently announced was the one between WebMethods and BEA that allows Java applications executing on BEA's application servers to connect to EIS resources through JCA connectivity to WebMethod's adapters. It's obvious that both companies compete in the application-execution space; however, it's testimony to the promise of JCA that they chose to partner in the connectivity arena.

The J2EE platform allows us to properly define the boundaries of our application box, but the actual definition depends on the environment, your company's core competency, and your faith in the J2EE vision.