Apparently Sun is selling its Java Beans as Magic Beans well worth
selling the family cow for. I wonder what kind of beanstalk is going
to grow out of this, fee fie foe fum and all. I'm still not sure how
the chicken farmer anecdote below is relevant.
What IS fun though is to watch Sun make Netscape and Microsoft out to be
the bad guys (yet again) who ruined HTML for the masses, but then recoil
in their position (hey, look at all the cool things that happened when
substandard <TABLE> tags were implemented! :)
I also like how Sun appropriated the name COM for their own use.
COM is becoming quite the overloaded acronym. Speaking of overloading,
the overloaded use of the word "component" has begun, too.
In fact, when you get right down to it, Sun's Component Object Model (COM)
resembles the Infospheres model (http://www.infospheres.caltech.edu/)
more every time I hear about it:
1. COM's component interface publishing and directory system
resembles the Infosphere interface discovery model.
2. COM's component layout functions resemble the
Infosphere Djinn Generator application.
3. COM's handling events to components resemble the
Infosphere asynchronous RPC mailbox model.
4. COM's component object persistence, or the ability to save
information about the component over time, resembles the
Infosphere persistent object model.
5. COM's support for linking components into an application resembles
the Infosphere Djinn Initiator application and the
Infosphere session model. (gulp!)
6. Java Beans leverage off existing technologies -- like the Web,
Java, IDL, and RMI -- as does the Infospheres project.
Note that they even dip into the telephone analogy like the Infospheres
project does, in mentioning the metaphor for the directory service!
I think Infospheres needs to clearly distinguish itself from Java Beans
on its homepage. What is it that makes us different? :)
-- Adam
*** included stuff follows ***
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 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:
* a component 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.
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