Original JavaWorld Page[1]
[IMAGE][2]
A portable hill of beans
New Java Beans API brings object-orientation's
grail of portability and reuse to the Java industry
Summary
Java is expanding so fast there's a chance it could run out of
control. Javasoft's new Java Beans application programming
interface (API) is an attempt to make a uniform interface to
applets and Java objects irrespective of the environment they
are placed in. The Java Beans API will make Java code written
for Netscape, Microsoft, or OpenDoc environments interoperable
without the need for any changes. This article previews the
highlights of Java Beans. (2,400 words)
[IMAGE]
By Rawn Shah
T his 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)[4] , Remote Method
Invocation (RMI)[5] , and Interface Definition Language (IDL)[6] . 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 were also described in "Java gets new
APIs"[7] , 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.
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 amazing
platform independent system. They cover most, if not all, areas of
software development in the current and future markets. Sun plans to
take it to the max 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 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. 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. Many 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% of the new
situations in which you may need it. 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, the same is currently true for Java interfaces to
the browser. 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, irrespective 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, browsers,
and slow speeds. The high-profile Internet users of today have to have
Shockwave and other plug-ins, as well as streaming audio, and images
that pop up faster and appear crisper.
Take 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 keeps hundreds of chickens for 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 do 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 have
to change your code now.
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 what you have to do is
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 to it. Logically, it involves
just sticking a mathematical function into the middle; in reality, this
may mean a lot of changes to your code depending upon if you are as good
a programmer as you are a farmer. 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 the chicken farming example. 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 the our shell
which makes the application whole--just as our bodies are containers
like 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:
* acomponent interface publishing and directory system
* component layout functions
* handling events to components
* 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 components which are of a visual nature have preferences for 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,
it an event is triggered. A radio button, when clicked, gets an event
which says that it has been selected. The COM system dictates how
components receive events and if 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. It's quite often that you 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 of how different components
link 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.
One 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 which are complex mathematical functions
and others which even act as browsers and plug-ins. And the good thing
is that they 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, 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, Netscape LiveConnect, are all similar in concept
yet different in practice. Microsoft has indicated that it is not too
hot on the idea of the Java Beans API. They already have their own COM
initiative in place with ActiveX and are not about to conform to a
standard from someone else. They have sufficient reason to believe that
their ActiveX initiative provides all the same features to support the
majority of the operating systems of the world (meaning Windows
systems).
At least the good news is that IBM is all behind it. Their project
Arabica is a collection of "IBM technologies" which will be implemented
as individual beans according to this new API. Particularly they are
behind the OpenDoc-Java Beans initiative with all their vested interests
supporting it. Each bean will be able to act as an OpenDoc container and
vice versa for OpenDoc components. IBM is already 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 their commitment. However, other
supporters of the new Java Beans initiative including Oracle, Netscape,
Symantec, Borland and IBM's Lotus subsidiary, have ballyhooed its
coming.
Using easy visual tools to drag and drop individual components, you can
now create applications using the next generation of Java integrated
development environments and rapid application development tools. Look
for the emergence of Java Beans where you didn't expect. That temporal
chicken coop production calculator you want may be just a step away. Now
you can count your chickens before they hatch. [][8]
About the author
Rawn Shah is vice president of RTD Systems & Networking Inc.[9] , a
network consultancy and integrator based in Tucson, AZ. He can be
reached at rawn.shah@javaworld.com
[IMAGE][10]
Resources
* See the JavaWorld article, "Distributed object computing with Joe and
NEO":
http://rwanda/javaworld/jw-06-1996/jw-06-dist.comp.html
* Java API overview:
http://www.javasoft.com/products/apiOverview.html
* Java Core API:
http://www.javasoft.com/products/apiOverview.html#core
* Java Beans API:
http://splash.javasoft.com/beans
* Java Media API:
http://www.javasoft.com/products/apiOverview.html#core
* Java server spec:
http://www.javasoft.com/products/jeeves
* Java management overview and demo:
http://www.javasoft.com/products/JavaManagement
* Java commerce spec:
http://www.javasoft.com/products/commerce
* Java Enterprise API:
* JDBC spec and early access implementation:
http://www.javasoft.com/products/JDBC/index.html
* IDL spec and early access implementation:
http://www.javasoft.com/products/JavaIDL/index.html
* * RMI spec and early access implementation:
http://chatsubo.javasoft.com/current
* Java Security API:
http://www.javasoft.com/products/apiOverview.html#security
* Java Embedded API:
http://www.javasoft.com/products/apiOverview.html#embedded
* A briefing sheet on IBM's Arabica and Java Beans:
http://ncc.hursley.ibm.com/javainfo/latest/javacomponents.html
* Everything you want to know about the movie Casablanca short of
watching the film itself. Use the keyword Casablanca:
http://us.imdb.com/search.html
[IMAGE][11]
-----------------------------------------------------------------------
[1] http://www.javaworld.com/javaworld/jw-09-1996/jw-09-javabeans.html
[2] /javaworld/icons/greenline.gif
[3] /javaworld/icons/greenline.gif
[4] /javaworld/jw-05-1996/jw-05-shah.html
[5] /javaworld/jw-06-1996/jw-06-remote.objects.html
[6] /javaworld/jw-06-1996/jw-06-remote.objects.html
[7] /javaworld/jw-07-1996/jw-07-apis-lawton.html
[8] /javaworld/icons/dingbat.gif
[9] http://www.rtd.com
[10] /javaworld/icons/greenline.gif
[11] /javaworld/icons/greenline.gif