What are JavaBeans?

Overview
JavaBeans are usual Java classes which adhere to certain coding conventions. Following are the
coding conventions I am talking about :

 Implements java.io.Serializable interface

 Provides no argument constructor
 Provides getter and setter methods for accessing it's properties

Let's now create a simple JavaBean class.

A simple JavaBean class

Create a new SimpleBean.java file and place it in the /WEB-
INF/classes/com/stardeveloper/bean/test/ folder so that the complete path is :

/WEB-INF/classes/com/stardeveloper/bean/test/SimpleBean.java

Now copy the following code and paste it into the SimpleBean.java file we created above :

package com.stardeveloper.bean.test;

public class SimpleBean implements java.io.Serializable {

/* Properties */
private String name = null;
private int age = 0;

/* Empty Constructor */
public SimpleBean() {}

/* Getter and Setter Methods */

public String getName() {
return name;
}

public void setName(String s) {

name = s;
}

public int getAge() {

return age;
}

public void setAge(int i) {

age = i;
}
}
Explanation
First line is the package statement :

package com.stardeveloper.bean.test;

Next we define our class and make it implement java.io.Serializable interface. Notice that
Serializable interface doesn't contain any method. Implementing it just flags to the compiler that
we might be serializing this class's objects.

public class SimpleBean implements java.io.Serializable {

Then we declare two variables which hold name and age of a person. These variables inside a
JavaBean are called as properties. These properties are private and are thus not directly
accessible by other classes. To make them accessible we provide getter and setter methods to get
and set their values.

private String name = null;

private int age = 0;

Next we create an empty argument constructor. Keep in mind that the only requirement to a
JavaBean is an empty "argument" constructor, not that you shouldn't use constructor at all.

public SimpleBean() {}

Explanation
The convention for writing getter and setter methods for JavaBean's properties is really simple.
All you have to do is to take the property name e.g. name. Make it's first character uppercase e.g.
Name. Now append 'get' for getter method and 'set' for setter method so that it becomes :

public String getName() {

return name;
}

public void setName(String s) {

name = s;
}

See! how easy it is. Since name variable is of type String, we set the return type of getName() to
String. Same is the case with setName() method which takes a parameter of type String because
name is of type String.

Next we added four getter and setter methods for private variables ( properties ) name and age.

public String getName() {

return name;
}

public void setName(String s) {

 name = s;
}

public int getAge() {

return age;
}

public void setAge(int i) {

age = i;
}

Now close the class.

Compiling JavaBean
You will compile JavaBean like you will compile any other Java class file. After compilation, a
SimpleBean.class file will be created.

We are now done with SimpleBean.

Summary
We learned that JavaBeans are Java classes which adhere to an extremely simple coding
convention. All you have to do is to implement java.io.Serializable interface, use a public empty
argument constructor and provide public getter and setter methods to get and set the values of
private variables ( properties ).

The JavaBeans Architecture

JavaBeans is an architecture for both using and building components in Java. This architecture
supports the features of software reuse, component models, and object orientation. One of the
most important features of JavaBeans is that it does not alter the existing Java language. If you
know how to write software in Java, you know how to use and create Beans. The strengths of
Java are built upon and extended to create the JavaBeans component architecture.

Although Beans are intended to work in a visual application development tool, they don't
necessarily have a visual representation at run-time (although many will). What this does mean is
that Beans must allow their property values to be changed through some type of visual interface,
and their methods and events should be exposed so that the development tool can write code
capable of manipulating the component when the application is executed.

Creating a Bean doesn't require any advanced concepts. So before I go any further, here is some
code that implements a simple Bean:

public class MyBean implements java.io.Serializable

{
protected int theValue;
 
 public MyBean()
{
}
 
public void setMyValue(int newValue)
{
theValue = newValue;
}
 
public int getMyValue()
{
return theValue;
}
}

This is a real Bean named MyBean that has state (the variable theValue) that will automatically
be saved and restored by the JavaBeans persistence mechanism, and it has a property named
MyValue that is usable by a visual programming environment. This Bean doesn't have any visual
representation, but that isn't a requirement for a JavaBean component.

JavaSoft is using the slogan "Write once, use everywhere." Of course "everywhere" means
everywhere the Java run-time environment is available. But this is very important. What it means
is that the entire run-time environment required by JavaBeans is part of the Java platform. No
special libraries or classes have to be distributed with your components. The JavaBeans class
libraries provide a rich set of default behaviors for simple components (such as the one shown
earlier). This means that you don't have to spend your time building a lot of support for the
Beans environment into your code.

The design goals of JavaBeans are discussed in Sun's white paper, "Java Beans: A Component
Architecture for Java." This paper can be found on the JavaSoft web site at
http://splash.javasoft.com/beans/WhitePaper.html. It might be interesting to review these goals
before we move on to the technology itself, to provide a little insight into why certain aspects of
JavaBeans are the way they are.

JavaBeans - a new component architecture

JavaBeans is a new component architecture for Sun's Java language. Like the language from which
JavaBeans draws its name, it is portable across many platforms; any environment supporting a JDK 1.1
interpreter will be capable of using JavaBeans.
Overview

For Java developers, and amateur applet authors, JavaBeans offers the ability to write
applications quickly and easily, by using a palette of components that can be assembled to form a
larger application. User-interface components, such as trees, lists, or graphical buttons can make
applications come alive, without the need for writing custom components for each and every
application. Networking protocols can be encapsulated in a component, allowing developers to
simply plug in email and web support into their applications. Literally any component you can
imagine can be written as a JavaBean, and then plugged into an application.

Features

 JavaBeans support properties, allowing an application to read and modify their values.
 JavaBeans support events, allowing vendors to create their own unique events.
 JavaBeans support the BeanInfo interface, allowing vendors to specify exactly which properties
and methods are available, and icons for beans which can be displayed on a toolbar.
 JavaBeans are highly configurable, and the state of a bean can be saved and restored through
'serialization'.

A Java Bean is a software component that has been designed to be reusable in a variety of
different environments. There is no restriction on the capability of a Bean. It may perform a
simple function, such as checking the spelling of a document, or a complex function, such as
forecasting the performance of a stock portfolio. A Bean may be visible to an end user. One
example of this is a button on a graphical user interface. A Bean may also be invisible to a user.
Software to decode a stream of multimedia information in real time is an example of this type of
building block. Finally, a Bean may be designed to work autonomously on a user's workstation
or to work in cooperation with a set of other distributed components. Software to generate a pie
chart from a set of data points is an example of a Bean that can execute locally. However, a Bean
that provides real-time price information from a stock or commodities exchange would need to
work in cooperation with other distributed software to obtain its data.

We will see shortly what specific changes a software developer must make to a class so that it is
usable as a Java Bean. However, one of the goals of the Java designers was to make it easy to use
this technology. Therefore, the code changes are minimal.

Advantages of Java Beans

A software component architecture provides standard mechanisms to deal with software building
blocks. The following list enumerates some of the specific benefits that Java technology provides
for a component developer:

 A Bean obtains all the benefits of Java's "write-once, run-anywhere" paradigm. 

 The properties, events, and methods of a Bean that are exposed to an application
builder tool can be controlled.
 A Bean may be designed to operate correctly in different locales, which makes it
useful in global markets.
  Auxiliary software can be provided to help a person configure a Bean. This software is
only needed when the design-time parameters for that component are being set. It
does not need to be included in the run-time environment.
 The configuration settings of a Bean can be saved in persistent storage and restored
at a later time.
 A Bean may register to receive events from other objects and can generate events that
are sent to other objects.

Java RMI & CORBA

A comparison of two competing technologies

With the introduction of CORBA support to Java (as of version 1.2), developers now
face the question of whether to continue to use remote method invocation (RMI), or
make a move to CORBA. The choice is made more difficult if your applications are
already written in RMI - considerable effort might have to be made to convert to
CORBA. Is it worth the move? This article discusses the pros and cons, and evaluates
the potential of these two technologies.

What is Remote Method Invocation?

Remote method invocation allows Java developers to invoke object methods, and
have them execute on remote Java Virtual Machines (JVMs). Under RMI, entire
objects can be passed and returned as parameters, unlike many remote procedure call
based mechanisms which require parameters to be either primitive data types, or
structures composed of primitive data types. That means that any Java object can be
passed as a parameter - even new objects whose class has never been encountered
before by the remote virtual machine.

This is an exciting property, because it means that new code can be sent across a
network and dynamically loaded at run-time by foreign virtual machines. Java
developers have a greater freedom when designing distributed systems, and the ability
to send and receive new classes is an incredible advantage. Developers don't have to
work within a fixed codebase - they can submit new classes to foreign virtual
machines and have them perform different tasks. When working with remote services,
RMI clients can access new versions of Java services as they are made available -
there's no need to distribute code to all the clients that might wish to connect. While
code can be accessed from a local or remote file-system, it can also be accessed via a
web server, making distribution easier. RMI also supports a registry, which allows
clients to perform lookups for a particular service. The following diagram shows the
interaction between different components of an RMI system. Clients that know about
a service can look up its location from a registry and access the service. If a new class
is required, it can be downloaded from a web server.

Client connects to a registry server, accesses a RMI service, and downloads new code as required from a web
server.

Remote method invocation has a lot of potential, from remote processing and load
sharing of CPU's to transport mechanisms for higher level tasks, such as mobile
agents which execute on remote machines (Reilly, 1998). Because of the flexibility of
remote method invocation, it has become an important tool for Java developers when
writing distributed systems. However, there are many legacy systems written in C/C+
+, Ada, Fortran, Cobol, and other exotic languages. If legacy systems need to interface
with your RMI systems, or your RMI systems need to interface with them, problems
can occur. RMI is Java specific, and you'll need to write a bridge between older
systems. Additionally, if you or your company plans on using other languages in the
future, you may also find yourself in a bind because of RMI's tie to Java - one day
Java itself may become a legacy platform. Writing interfaces to legacy systems isn't
my idea of fun programming!

What is CORBA?

Common Object Request Broker Architecture (CORBA) is a competing distributed

systems technology that offers greater portability than remote method invocation.
Unlike RMI, CORBA isn't tied to one language, and as such, can integrate with legacy
systems of the past written in older languages, as well as future languages that include
support for CORBA. CORBA isn't tied to a single platform (a property shared by
RMI), and shows great potential for use in the future. That said, for Java developers,
CORBA offers less flexibility, because it doesn't allow executable code to be sent to
remote systems.

CORBA services are described by an interface, written in the Interface Definition

Language (IDL). IDL mappings to most popular languages are available, and
mappings can be written for languages written in the future that require CORBA
support. CORBA allows objects to make requests of remote objects (invoking
methods), and allows data to be passed between two remote systems. Remote method
invocation, on the other hand, allows Java objects to be passed and returned as
parameters. This allows new classes to be passed across virtual machines for
execution (mobile code). CORBA only allows primitive data types, and structures to
be passed - not actual code.

Under communication between CORBA clients and CORBA services, method calls
are passed to Object Request Brokers (ORBs). These ORBs communicate via the
Internet Inter-ORB Protocol (IIOP). IIOP transactions can take place over TCP
streams, or via other protocols (such as HTTP), in the event that a client or server is
behind a firewall. The following diagram shows a client and a servant communicating.

CORBA client sends a request through its local ORB to a CORBA servant sends back a response to a remote ORB
remote ORB's servant

RMI vs CORBA

Comparing RMI and CORBA doesn't reveal an optimum solution - one is not "better"
than the other. The properties of these two technologies lend themselves to different
situations. A comparison of RMI and CORBA helps to highlight individual strengths
and weaknesses, but the applicability of one technology over the other depends
largely on the purposes for which it is to be used, the experience of the developers
who will design, implement and maintain the distributed system, and whether non-
Java systems are intended to access the system now or in the future.

RMI pros and cons

Remote method invocation has significant features that CORBA doesn't possess -
most notably the ability to send new objects (code and data) across a network, and for
foreign virtual machines to seamlessly handle the new objects (Reilly, D). Remote
method invocation has been available since JDK 1.02, and so many developers are
familiar with the way this technology works, and organizations may already have
systems using RMI. Its chief limitation, however, is that it is limited to Java Virtual
Machines, and cannot interface with other languages.

Remote method invocation

Pros Cons

Portable across many platforms Tied only to platforms with Java support

Can introduce new code to foreign JVMs Security threats with remote code execution, and
limitations on functionality enforced by security
restrictions

Java developers may already have experience with Learning curve for developers that have no RMI
RMI (available since JDK1.02) experience is comparable with CORBA

Existing systems may already use RMI - the cost and Can only operate with Java systems - no support for
time to convert to a new technology may be legacy systems written in C++, Ada, Fortran, Cobol,
prohibitive and others (including future languages).

CORBA pros and cons

CORBA is gaining strong support from developers, because of its ease of use,
functionality, and portability across language and platform (Reilly, D). CORBA is
particularly important in large organizations, where many systems must interact with
each other, and legacy systems can't yet be retired. CORBA provides the connection
between one language and platform and another - its only limitation is that a language
must have a CORBA implementation written for it. CORBA also appears to have a
performance increase over RMI, which makes it an attractive option for systems that
are accessed by users who require real-time interaction(Morgan, 1997).

Common Object Request Broker Architecture

Pros Cons

Services can be written in many different languages, Describing services require the use of an interface
executed on many different platforms, and accessed definition language (IDL) which must be learned.
by any language with an interface definition Implementing or using services require an IDL
language (IDL) mapping. mapping to your required language - writing one for
a language that isn't supported would take a large
amount of work.

With IDL, the interface is clearly separated from IDL to language mapping tools create code stubs
implementation, and developers can create based on the interface - some tools may not
different implementations based on the same integrate new changes with existing code.
interface.
CORBA supports primitive data types, and a wide CORBA does not support the transfer of objects, or
range of data structures, as parameters code.

CORBA is ideally suited to use with legacy systems, The future is uncertain - if CORBA fails to achieve
and to ensure that applications written now will be sufficient adoption by industry, then CORBA
accessible in the future. implementations become the legacy systems.

CORBA is an easy way to link objects and systems Some training is still required, and CORBA
together specifications are still in a state of flux.

CORBA systems may offer greater performance Not all classes of applications need real-time
performance, and speed may be traded off against
ease of use for pure Java systems.

Summary

An examination of these two technologies shows that, while they do overlap in

functionality to some degree, they each possess strengths that outshine the other for
particular tasks. A careful evaluation of the intended use of RMI or CORBA is
required, to determine which technology is the most appropriate. There aren't any hard
and fast rules that can be applied, and there is no clear victor in the battle for the
minds and hearts of developers. Time will tell which technology (if any) becomes the
more dominant, and in the immediate future both will continue to play a role.

Introduction to Java RMI

By David Reilly

Remote method invocation allows applications to call object methods located remotely,
sharing resources and processing load across systems. Unlike other systems for remote
execution which require that only simple data types or defined structures be passed to and
from methods, RMI allows any Java object type to be used - even if the client or server has
never encountered it before. RMI allows both client and server to dynamically load new
object types as required. In this article, you'll learn more about RMI.

Overview

Remote Method Invocation (RMI) facilitates object function calls between Java Virtual
Machines (JVMs). JVMs can be located on separate computers - yet one JVM can invoke
methods belonging to an object stored in another JVM. Methods can even pass objects that a
foreign virtual machine has never encountered before, allowing dynamic loading of new classes
as required. This is a powerful feature!
Consider the follow scenario :

 Developer A writes a service that performs some useful function. He regularly updates this
service, adding new features and improving existing ones.
 Developer B wishes to use the service provided by Developer A. However, it's inconvenient for A
to supply B with an update every time.

Java RMI provides a very easy solution! Since RMI can dynamically load new classes,
Developer B can let RMI handle updates automatically for him. Developer A places the new
classes in a web directory, where RMI can fetch the new updates as they are required.

Figure 1 - Connections made when client uses RMI

Figure 1 shows the connections made by the client when using RMI. Firstly, the client must
contact an RMI registry, and request the name of the service. Developer B won't know the exact
location of the RMI service, but he knows enough to contact Developer A's registry. This will
point him in the direction of the service he wants to call..

Developer A's service changes regularly, so Developer B doesn't have a copy of the class. Not to
worry, because the client automatically fetches the new subclass from a webserver where the two
developers share classes. The new class is loaded into memory, and the client is ready to use the
new class. This happens transparently for Developer B - no extra code need to be written to fetch
the class.