There are plenty of good reasons for the application server to require access and communication with distributed objects outside its own framework. Indeed, the application server is an ensemble of distributed objects in and of itself, but there may still be external CORBA or COM objects that the developer wants to integrate into the application.

The purpose of this column is not to debate CORBA versus COM, OMG versus Microsoft or open standard versus dominant vendor. The bottom line is that both types of objects exist regardless. Now, you might ask, What will they do?

Many companies have been building and using distributed objects for important business logic, then housing those objects within Object Request Brokers and distributed object environments. At this writing it's certainly commonplace to find a mission-critical business application making use of such distributed objects. One common theme in the creation of CORBA or COM objects is the need for serious business logic in a middle tier, particularly when it provides an abstraction layer for data stored in legacy systems or legacy databases. Such distributed object abstraction layers are sometimes called wrappers, but I loathe the term because it's often applied too liberally - as if anything could be wrapped this way!

Given the existence of such wrapper objects and the multitude of other distinct types of distributed objects either in CORBA or COM containers, we reach the point where we must interplay these with the application server. As long as the application server itself is fluent in IIOP and DCOM, we have a place to start. Fluency in IIOP alone could suffice, however, since there are DCOM bridge products available to extend the IIOP protocol to the Microsoft realm.

Think of the application server as a community of tightly coupled distributed objects. The application server makes a bridge so external distributed objects in separate containers (ORBs, for example) can become first-class citizens of the application server framework. That's the trick. Application server vendors such as Progress Software's Apptivity and BEA's Weblogic have efficient mechanisms for making this connection, and the result is a smooth integration between the application server and the hundreds of CORBA objects that Orfali and Harkey keep reminding us to build.

So there you have it - a brief look at the three types of connectivity for the application server: JDBC, legacy systems and distributed objects. For an application server to reach its potential, these three types must be met with elegance and purpose. It's not a matter of simply "having access" to these types of elements, for Java has access to almost everything through its APIs. We're talking about a well-thought-out, integrated approach among tools, framework and the application server.

• Figure 1