HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

When I began using CORBA in 1993 I was impressed by how well (and easily) I could define an object model and express it to other developers. That, of course, is made possible through CORBA Interface Language. More fundamentally, it is achieved with a strong and inherent distinction between interface and implementation - a distinction that's often lost in programming languages. CORBA IDL is absolutely and only about interface.

After designing an object model based strictly on interface semantics, I can ensure that only the interface semantics forms the contract for other users of my objects. My users avoid building any dependencies on my implementation semantics - thus increasing both the portability of their applications and the reusability of my objects.

The other thing distinctly impressive about CORBA is its ability to scale. CORBA is about architecture and specification of programming models that are, at their very core, designed and intended to be deployed and to interoperate across distributed systems. On one hand, the CORBA specifications are focused on programming and deploying applications in a distributed system, but don't define the qualities of service supplied by any given implementation. On the other, these same specifications don't inhibit, and in fact specifically enable, high levels of quality service in particular implementations. This enables different vendors to provide lightweight technology packages for small-scale deployments and robust platforms for large, enterprise-scale deployments. The same fundamental programming model can be used across all of these deployments from one end to the other -- mostly.

I encountered Java for the first time three years ago at a CORBA conference - I was presenting the merits of CORBA, and everyone else was presenting the merits of Java. I was overwhelmed with the hype and not just a little skeptical about its applicability and durability.

Yes, Java seemed to introduce fundamental productivity gains, and yes, the idea of "write once, run everywhere" was enticing, but how could a garbage-collecting interpretive language scale? Moreover, the examples of its use were mere toys -- silly demonstrations of bouncing icons and checkers games. And, of course, there was the meteoric rise in interest in Java (remember Tickle-Me Elmo?)

But there's important synergy between Java and CORBA. Essentially, it comes down to this: Java, and more particularly Enterprise JavaBeans, provides a fully consistent programming model that can be moved between platforms supporting different levels of scalability. CORBA provides the definition of infrastructure and services that enables different levels of scalability in a distributed system. EJBs close the gap between mostly transparent and completely transparent scalability. This is achieved by removing business object developers from any dependency on the quality of service of the underlying platform. EJB developers concentrate on programming business objects that encode business function rather than information technology and infrastructure function. CORBA enables complete location transparency, so that as an application or enterprise grows, its infrastructure can be scaled up as the EJB implementation remains the same. Moreover, since EJBs don't encode quality of service assumptions, the qualities of service can be increased (or decreased) based on the evolving requirements of the business.

Java and EJB define specific mappings to CORBA services for Naming, Security and Transactions, and in both directions between Java interfaces and CORBA IDL.

The quality-of-service semantics that you can specify as EJB descriptors - including the transaction management descriptors such as TX_REQUIRED and TX_SUPPORTS as well as the run-as security descriptors such as CLIENT_IDENTITY and SYSTEM_IDENTITY - map well to semantics that are easily implemented using CORBA services and quality-of-service policies attributed to CORBA Object Adapters. As a result, CORBA and Java work well together - by design.

Java gives you portability (write once, run everywhere), not just across heterogeneous platforms as it always has but - when combined with CORBA - across different qualities of service and scaling. CORBA provides a common, consistent and interoperable specification for distributed object management and thus enables differing qualities of service and scale on which EJBs can execute. An enterprise can pick and choose a platform for its quality of service and for how well it fits into their overall computing requirements and budget, rather than on the programming model contraints it might impose. Application developers can increase productivity through the use of Java language and its corresponding Web-enablement features. They're freed from infrastructure issues and can concentrate on providing business value. Conversely, enterprises obtain the flexibility to deploy their applications in a way that fits their integrity and scalability needs gives them the interoperability assurance provided by CORBA.

About the Author
Rob High Jr. is a senior programmer inIBM Component Broker Architecture andDevelopment. He can be e-mailed at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.