Jeff Nelson

Subscribe to Jeff Nelson: eMailAlertsEmail Alerts
Get Jeff Nelson via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java Developer Magazine

Java Developer : Article



Component software has swept through the software industry. Millions of developers now drag and drop components on a form rather than writing source code. JavaBeansª has provided an elegant component model for the Java development environment and is widely accepted in many development environments. However, JavaBeans lacks any support for distributed computing. This article explores how CORBA and JavaBeans could work together to provide an excellent distributed component model with the added benefit of the cross language interoperability that is a trademark of CORBA. A prototype of such "CorbaBeans" is demonstrated.

The past few years have seen enormous changes in the software development process. Not so long ago, implementing a client/server application meant writing raw data back and forth to a TCP/IP socket. Worse, the toolkits that were available to simplify the task of developing client/server systems were all incompatible with each other. Today, CORBA has turned this around; objects can communicate with other objects directly even if they are located in different software applications, on different hardware or in different languages.

Just as revolutionary is the move to component-based software. For the last thirty years, nearly all software has been written by typing long lists of text commands into a computer screen. Only recently has this advanced with the focus on graphical component-based development environments. Reusing components within such a graphical development environment is a simple matter of drag-and-drop. This simple and quick reuse has been quantified in some studies with the conclusion that component re-use can speed development by as much as a factor of 30.

Components are incredibly important for software development and re-use. It's safe to say that while a few of us like to write code, roughly 75 percent of the development community just drags and drops icons onto a form. Notably, even Java developers like the speed with which a complete application can be crafted using visual components. It's actually sort of a testament to the strength of Java that it has survived this long without a strong offering of component development environments. JavaBeans is what will ensure that Java can compete in that marketplace.

JavaBeans introduced component software development to Java just over a year ago. Today, JavaBeans is widely accepted in many different development environments. Most notably, Borland and Symantec have restructured their entire development environments around JavaBeans. Borland's JBuilder includes more than 150 JavaBeans which can be used and distributed royalty-free. Symantec's latest Visual Café 2.0 editions include more than 100 JavaBeans with similar royalty-free licensing.

JavaBeans has even made it into the browser market. Marc Andreessen recently announced that the Netscape browsers would be rewritten with reusable Java- Beans. For example, one bean might represent an HTML page while another would represent a newsreader. Developers could use these components to write their own software by simply importing them into their favorite software development environment and then using drag-and-drop to include the JavaBean's functionality into custom applications. In addition, Sun has recently released a JavaBean for its HotJava browser and other web browser. JavaBeans is available from small companies.

The architecture for JavaBeans is very elegant. The design of JavaBeans is based on two key architectural insights. First, any Java class can be treated as a trivial Java- Bean. Second, a technique called Reflection can be used to examine the capabilities of a JavaBean.

The first insight guarantees that creating JavaBeans is basically just as easy as making any other Java object. In fact, many Java Beans can be used just like any other Java object. The JavaBeans architecture is object-oriented from the ground up. This will be a gigantic relief to people struggling with the ugly APIs defined for other component models.

The second insight has to do with the use of a technology which is new to many of us: Reflection. The powerful capability of Reflection is that it permits objects to examine each other at runtime to discover the capabilities of objects. Java remains type-safe, but Reflection provides many of the same benefits of weak typing in allowing objects to adapt to each other at run-time rather than at compile time.

Components usually have an exposed set of properties, methods and events that interact with other components. Reflection can be used to examine what a JavaBean can do in the form of these properties, methods and events without requiring the original developer to spend hours writing code to configure the component framework, a tedious task required with less elegant component models. The tool that facilitates all of this in JavaBeans is called, appropriately, the Introspector. It provides excellent default behavior for exposing the capabilities of any component, while allowing the component developer to configure the information which is published to other components if required. However, most developers find this unnecessary for nearly all components.

One limitation that JavaBeans has traditionally had is that it is restricted to a single application. Developers can easily "wire up" some JavaBeans into an application but not into a set of distributed applications. Let's consider one concrete example: Suppose a consulting company wants to track how many hours are spent by each employee on different projects. This would be a perfect application of distributed computing, because you would want potentially hundreds or thousands of desktops to send back schedule summaries to the accounting department. JavaBeans would help you quickly and easily build the front end for each consultant and the back end for the accounting department, but then you are stuck. The JavaBeans developer would need to bring in some other technology to solve this problem. Enter: CORBA.

CORBA has done a wonderful job over the past few years of allowing objects in different programs to communicate with each other. In fact, a year ago I showed one of my managers a distributed application that I had written over the course of several years. The networking code came out to about 5,000 lines to handle several different failure conditions. however, the application still wasn't very robust. The same application, rewritten using CORBA, was just 400 lines and made use of several different fault-tolerant features built into the ORB. Furthermore, the CORBA port opened the door for migrating the front end away from C++ into Java. At the same time, while CORBA is entirely object-oriented, it currently lacks any form of component model. As we stated earlier, the trend in the software industry seems to be away from source code and in the direction of components.

So to summarize, JavaBeans has an excellent component model but no support for distributed computing. CORBA lacks a good component model but is the tool of choice for distributed computing. These differences in the two technologies beg the question: How do we bring these two wonderful technologies together to make each a more powerful tool?

The first goal of bringing the two technologies together would be to make it simple to "wire up" not just a single application with JavaBeans, but open up the possibility of creating whole systems of interacting distributed software. This goal could be realized if the wiring between JavaBeans could extend between applications.

The properties, methods and events of a JavaBean can easily be wrapped into a CORBA server by paralleling many of the key architectural designs of JavaBeans in CORBA. For example, the methods of a Java Bean can be exposed as a member method of a CORBA interface. The properties of a JavaBean can be exposed as a CORBA attribute. The events of a javaBean can be exposed using either the CORBA Event Service or by following the same naming conventions used in Java to distribute EventObjects.

Since JavaBeans can act as both CORBA servers and CORBA clients, this design provides a way to make JavaBeans itself into a distributed component architecture, perhaps called "DBeans". Each JavaBean, even Beans which have already been written by component developers, could be used in a distributed application and integrate naturally with the network. This is a powerful capability that opens the door to writing powerful distributed applications with a simple drag and drop.

Rather than just discuss it, let's jump into a working example of how CorbaBeans could be implemented. By the way, the source code for this example is available on-line, so you can grab a copy and try it out for yourself! The prototype is composed of five components with each component demonstrating a separate point.

CORBA Server as JavaBeans
HelloImpl is a JavaBean which is also a complete Corba server. This Bean demonstrates that existing CORBA servers could be wrapped inside of JavaBeans to provide powerful functionality within existing JavaBean compatible development environments. This Bean can be imported and used in any JavaBeans compatible development tool. Once the bean is instantiated, it will list itself in the Visigenic Smart Agent and begin accepting remote invocations. Since it is a JavaBean, its methods, properties, and events are also exposed through the normal mechanisms provided by the JavaBeans development environment.

A bean like this would allow JavaBeans developers to implement server applications with only a couple of drag and drop applications. Suppose you are developing a client/server ordering tracking system for use by departments in a large company. Unfortunately, as always happens, each department might have a slightly different idea about what the backend should do. One group wants it to save data to a relational database. Another department always uses object databases. Yet another group would like all transactions to be approved by a human attendant before processing them. If the server was implemented as a CorbaBean, new functionality could be plugged into the server quickly. The server could be customized with only a drag and drop operation within any JavaBeans development environment.

CORBA Clients as JavaBeans
The second part of the prototype is VHello, a JavaBean which implements a CORBA client. Many software developers might see JavaBeans clients as more useful than the above JavaBeans server. When a JavaBean implements a CORBA client, new client applications can be built with drag and drop operations. Clients often require such customization, since often the clients are the front ends of a distributed system. Front ends, user interfaces in particular, often experience a great deal of change as customers provide feedback about the human factors of an application.

Suppose you are developing a set of applications for the infrastructure of a large company, including order tracking, customer service and accounting systems. All of these individually are very successful client/server applications. However, they could work even better if they could arbitrarily be plugged together to meet the needs of different departments within the organization. Implementing the CORBA clients as JavaBeans means that making a new application into a client of one or more of the order, customer, or accounting systems is a simple matter of drag and drop.

Building CORBA With JavaBeans
The third component of the prototype is a JavaBean affectionately called CorbaBean. This name is used because this JavaBean automatically converts other JavaBeans into CORBA servers. This JavaBean uses the Introspector on other JavaBeans to discover what properties, methods, and events they support. It then generates the CORBA files required to implement a CORBA server using this JavaBean as the implementation. This would permit component developers to take their existing Beans and create servers for them automatically.

For example, suppose you are running a savvy software development organization. Your group already has written hundreds of JavaBeans to perform all of your mission critical business activities. The problem is that you want your order tracking Bean in one application to work with your account auditing Bean in another application. CorbaBean, the third portion of this prototype, demonstrates that you could automatically compile your Beans into CORBA server, and facilitate this kind of application to application communication instantly.

Component Migration
The fourth component of this prototype is not a JavaBean. Rather, this component is a C++ CORBA server written with VisiBroker for C++. This component interoperates seamlessly with the VHello component, demonstrating the following key point. One of the strengths of CORBA is that it permits different programming languages to work naturally with each other by providing a middleware for their objects to invoke each other. The CorbaBeans architecture could also make use of this benefit.

When a CORBA server is compiled from a JavaBean, the resulting CorbaBean defines a particular CORBA interface. This interface is not bound to any particular language; in fact, the implementation of this interface in Java is completely hidden by the interface. For all the user of the CorbaBean knows, the bean may have been implemented in C++, Visual Basic or Perl.

This observation opens the door to the design of a cross-language distributed component environment. While the architectural principles of JavaBeans are simple and elegant, the same architecture can be adopted and implemented in many different languages.

Any CORBA interface is a trivial CorbaBean. However, a CORBA interface can be written in any language, even COBOL. Once the CORBA interface is published and compiled into a CorbaBean, the implementation of the bean in COBOL is not important. The CorbaBean is still compatible with any JavaBeans development environment.

Conversely, the design principles behind the JavaBeans architecture could be used to implement a component model in other languages, such as C++. For example, the methods, attributes and events of a CORBA interface could be mapped into the methods, properties, and events of a component in C++. This is actually rather straightforward since the CORBA Interface Repository works in much the same way as Reflection in Java.

Due to our use of CORBA as the glue for this component architecture, CorbaBeans are inherently compatible with many different development environments. In particular, tools are already available to work with CORBA interfaces in Visual Basic, Delphi, Powerbuilder and several other development environments. Once a JavaBean is compiled into a CorbaBean, that bean could be re-used not just in Java development environments but in nearly any development environment through CORBA's powerful interoperability.

The reverse is also true. CORBA tools can convert COM interfaces into CORBA interface. If CORBA interface could be converted into CorbaBeans, existing Visual Basic OCXes could be re-used within JavaBeans development environments. This sort of interoperability provides an excellent path for component migration to JavaBeans.

Scripting is a common programming technique of writing small, useful programs in only a few lines of code, called scripts. Netscape's JavaScript is a good example of a scripting language. Using JavaScript, simple tasks, such as intelligently animating an image, can be performed by embedding a script directly in an HTML page.

One of the key requirements of a good scripting language is a simple, easy to understand API. Without this, too much time must be spent on the overhead of learning how to write the scripts, destroying the value of writing short scripts to perform useful tasks.

Component developers strive to make components which have a simple, easy to use interface within a visual development environment. One of the side effects of this is that the API usually makes sense in other contexts as well. For example, when writing an e-mail component, the component would support properties such as to, from and subject, methods to send e-mail and events to indicate when new e-mail has arrived. This simple API is also exactly what a scripting developer would want to have access to when writing scripts for e-mail.

This natural marriage of scripting with components provides benefits to CorbaBeans as well. Some scripting languages allow small scripts to be written with JavaBeans. This article has suggested that CorbaBeans are just JavaBeans with special distributed computing capabilities, so scripting languages which support JavaBeans could also be used with CorbaBeans.

JavaBeans and CORBA are both powerful development tools individually. However, the whole is greater than the sum of the parts. CorbaBeans allows JavaBeans to implement and use network services within the same JavaBeans development environments that are currently installed on your computer. CorbaBeans makes writing CORBA application a matter of drag and drop using those same tools. The cross language capabilities of CORBA mean that CorbaBeans written in one language work with components written in widely different languages. Scripting languages for JavaBeans would naturally work spectacularly well with CorbaBeans, as well.

Where to Go From Here
The prototype described in this article can be downloaded from http://www.DistributedObjects.com

Information on CORBA standards can be found at http://www.omg.org

More information on JavaBeans can be found at http://www.javasoft.com/beans/

More Stories By Jeff Nelson

Jeff Nelson is a distributed systems architect with DiaLogos Incorporated, experts in CORBA and Java Technologies (http://dialogosweb.com) and active participants in the Object Management Group. He has 8 years of experience in distributed computing and object technology. Jeff can be found on the Web at http://www.distributedobjects.com/

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.