A portable hill of beans

New Java Beans API brings object-orientation's
grail of portability and reuse to the Java industry

This month we are kicking off exciting new plan to describe the entire family of Java APIs. We plan to bring you a continuing series of articles on each member of the Java API family with as much information as possible both before and after the release of the API itself. This way you will know what to expect in the world of Java in the coming months, and when the new APIs are finally out there, you will get the lowdown on Java Beans' actual implementation. First we need to view the members of this new family. JavaSoft has outlined the following API sets, each covering a different area but all working together within the Java framework.

  • Java Core API
  • Java Beans API
  • Java Media API (2-D, 3-D, Telephony, Animation, Media Framework, Collaborative)
  • Java Server API
  • Java Management API
  • Java Commerce API (Java Wallet)
  • Java Enterprise API (JDBC, IDL, RMI)
  • Java Security API
  • Java Embedded API

We have already covered some of these APIs in their early stages, specifically Java Database Connectivity (JDBC), Remote Method Invocation (RMI), and Interface Definition Language (IDL). The Java Core API constitutes all the classes and libraries used for everyday Java development such as the input/output routines, abstract windowing toolkit (AWT), the networking libraries, the utility library, and the applet library. These also were described in "Java gets new APIs", in the July issue of JavaWorld.

Java Beans is the API set for interoperability with non-Java object systems and portability mechanisms. Multimedia programmers are waiting for the Java Media API, which will help them build applications as amazing as the popular packages of today, such as Adobe Photoshop and Premiere and Macromedia Director.

The Java Server API is a toolset to help you create server-based applications to continue in the networked vision of Java. Likewise the Management API will help create network and software management tools.

The Java Commerce API will be an implementation and toolset for creating online commercial systems for transactions over the local network as well as the Internet. The group of Enterprise APIs help to integrate distributed computing and database systems into your applications. The security API provides tools for cryptography and secure communications within and beyond your applications. Finally, the Embedded API is a special set for implementing the Java environment within embedded circuits and systems such as telephones, manufacturing control systems, intelligent video and home entertainment systems, and maybe even the Talkie Toaster of Tomorrow.

Together these API sets form the future direction of Sun's platform-independent system. They cover most, if not all, areas of software development in the current and future markets. Sun plans to take Java to new heights, and CEO Scott McNealy's vision of Java-based components in every intelligent appliance of the future stands behind this. We begin humbly in this issue with a preview of the Java Beans API.

A portable hill of beans

When Bogart said to Bergman in Casablanca: "The problems of two people don't amount to a hill of beans in this crazy world," he could not have been more incorrect. Of course, he probably wasn't talking about the problem of software portability in the computer industry. Off the silver screen, the problem of taking a piece of code in one situation and applying it to another presents a world of problems. Unlike movies such as Universal Pictures' Sneakers, in which one magical little box could decode just about any applied cryptographic techniques in existence, in the real world we have to deal with taking software black boxes, evaluating their code and capacity for reuse, and most probably writing a lot of new code to make them work in a different context.

At least I do have a piece of good news when it comes to the world of Java. Software portability may just be around the bend with the announcement and development of the new Java Beans APIs. This set of APIs creates a uniform interface to code and Java classes, making them portable to new software environments. JavaSoft is planning to release this piece of magic toward the end of this year and into the beginning of next year. Read on to find out more about what this new API set can do and how it can be applied.

Portability and reuse

It isn't easy to understand the problems inherent in software portability unless you get into a porting situation. Novice programmers often end up rewriting much of the same code over and over again before it strikes them as redundant. Then the real issue arises: how to make a piece of code that can be used in at least 75 percent of the new projects in which similar function is needed. In pure software engineering, where the constructs of abstract data types are well defined, this may not be much of an issue. This is why it is often easy to find object classes for lists, queues, stacks, and all their relatives. However, when it comes to interfacing with other applications and with APIs, you often hit a brick wall.

For example, as you can see in the "privatization" of HTML tags with certain Web browsers, some code cannot be properly interpreted by some browsers. The same problem arises with Java interfaces to browsers. Rather than having to deal with the whims of Netscape or Microsoft, perhaps the world should have just stuck to the set of HTML tags as originally approved with the browsers of 1993. But of course then we wouldn't be able to do all the nifty things that the browsers of today can do.

Proprietary extensions are an even bigger problem when it comes to the issue of Java code. If we want to encourage people to use Java, we would do best to build our applets so that they can communicate with others uniformly, regardless of the environment we put them in. This would allow applets to communicate their needs to different browsers in the same manner.

Code reuse is a slightly different problem. Instead of dealing with the issue of compatibility in different environments at the same time, you have the dilemma of compatibility in different environments at different times. Over time, the need for a piece of code evolves. For example, early Internet users were satisfied with clunky interfaces, immature browsers, and slow speeds. The high-profile Internet users of today insist on using Shockwave and other plug-ins, as well as streaming audio, and images that pop up faster and appear crisper.

Consider the piece of software that decodes a data file and presents it to you. You see those almost every time you look at a graph of some kind. Let's say you're a farmer who relies on hundreds of chickens to produce eggs and has a monitoring device for each of the different rows of chicken coops and the eggs produced by all your hens. This monitoring device is triggered each time a hen lays an egg, which is deposited in a bin for collection. Each count is then sent to your computer and entered into a database. You have a special applet that displays the number of eggs produced by each row of chicken coops within your browser. Other than the fact that you're probably the most high-tech chicken farmer I know of, like most farmers, you want to know how much is produced each day.

Now let's say a few months down the road, several new grocery stores are opening up and want to know your capacity for providing them with fresh eggs on a regular basis; you realize that you need to know your production not just on a daily basis through your browser. Luckily you saved all the information from your daily gross in your database and now want to analyze growth charts to examine the level of production from the new rows of coops you have been adding over the past few months. To help you decide if you need more new coops to keep up with your success, you now have to change your code.

Previously, the code was simply doing a few things: taking the value from the database, processing the information of production by row, and displaying this information on your screen. Now you want to tally the daily production of each row of coops averaged over a certain time period and then display this information. As a multi- talented farmer who also happens to be a Java programmer, you want to change your code to add this new function. Logically, it involves just inserting a mathematical function into the program; in reality, this may mean a lot of changes to your code. If your code is properly reusable, this won't be a problem; if not, well, at least you have a successful chicken farm, right?

COMing to a store near you

Enough about chickens. To understand how Java Beans does its magic, you have to know a little about the component object model (COM). This is actually a generic name describing a system whereby an object can be described in a set of APIs such that each software component can be dynamically connected with others to create a useful application.

Components are put together inside a container. This forms our shell which makes the application whole -- just as our bodies are containers that hold organs, muscles, and bones. Containers can also be components; each one of us in physical and mental form is a component in the container of our society.

There are many kinds of COMs, but most share the following basic characteristics:

  • a component interface publishing and directory system
  • component layout functions
  • an ability to handle events
  • component object persistence, or the ability to save information about the component over time
  • support for linking components into an application

The publishing system allows components to find out where others are and how to communicate with them -- sort of like a combined telephone directory and English-to-Spanish translator.

Many visual components have preferences that help define how they are laid out with others. For example, radio buttons are very basic components. In most cases, they exist in groups so you can select one option from several or many. With these layout functions, you can specify how groups of radio buttons are laid out on the screen.

All components handle events. When you pass information to a component, an event is triggered. A radio button, when clicked, gets an event that says that it has been selected. The COM system dictates how components receive events and whether other components are to be triggered with events as well.

Object persistence isn't absolutely necessary with every single component but is important in many cases. Quite often you may wish to store the current state of the component. The COM provides the necessary services to automatically or directly save state at any point in time.

Finally, the COM describes the architecture that links different components together. This is where portability really becomes an issue. Without a universal brokerage system like a COM, each component becomes its own proprietary format designed and implemented by its creator.

Individual components created in the Java Beans framework are known simply as beans. All beans, however, are not necessarily very simple ones like buttons, text labels, and images that you find with most visual development systems. You can have small beans and large beans. A small bean, like we said, might be a button object or a simple picture. A big bean might be a portable text editor that pops up for any piece of text and provides the functions of a full-sized word processor. Similarly, you could have beans that are complex mathematical functions and others that even act as browsers and plug-ins. The beauty of this paradigm is that these beans will work wherever you take them, as long as the environment holds true to the Java Beans API, Java Virtual Machine, and standard libraries.

Java Beans makes use of the IDL and RMI system we described in earlier issues of JavaWorld. This allows beans to send data or execute methods of other beans on the same or even a remote computer. With coming releases of new APIs for electronic commerce, embedded computing, and server and application development, Java Beans forms the base level from which new applications will be built in the future.

Bean me up, Scottie

The Java Beans API implements all the above-mentioned features. In the real world, there are different types of COMs. For example, Microsoft OLE/COM/DCOM, OpenDoc, and Netscape LiveConnect all are similar in concept yet different in practice. Microsoft has indicated that it is not too hot on the idea of the Java Beans API. The company already has its own COM initiative in place with ActiveX and is not about to conform to a standard from someone else. Microsoft has sufficient reason to believe that its ActiveX initiative provides all the same features to support the majority of the operating systems of the world (meaning Windows systems).

At least IBM is behind the Java Beans initiative. IBM's Arabica project involves a collection of "IBM technologies" that will be implemented as individual beans according to this new API. Particularly IBM is behind the OpenDoc-Java Beans initiative with all its vested interests supporting it. Each bean will be able to act as an OpenDoc container and vice versa for OpenDoc components. IBM already is committed to taking Java to the AIX and OS/2 platforms. IBMs partner in crime for OpenDoc has not yet made an announcement as to its commitment. However, other supporters of the new Java Beans initiative, including Oracle, Netscape, Symantec, Borland and IBM's Lotus subsidiary, have ballyhooed its coming.

Related:
1 2 Page 1
Page 1 of 2