Given by Geoffrey Fox, Nancy McCracken, Wojtek Furmanski at Basic Information Track Computational Science Course CPS616 on Spring Semester 1999. Foils prepared May 19 99
Outside Index
Summary of Material
General Issues -- why Java Beans are important |
Some example JavaBeans |
Detailed Technologies of JavaBeans (These include some generic JDK1.1 topics and some which are JavaBean.)
|
Distributed JavaBeans for web computing and information systems |
Outside Index Summary of Material
Geoffrey Fox, Nancy McCracken, |
Wojtek Furmanski |
Syracuse University NPAC |
111 College Place Syracuse NY 13244 4100 |
3154432163 |
General Issues -- why Java Beans are important |
Some example JavaBeans |
Detailed Technologies of JavaBeans (These include some generic JDK1.1 topics and some which are JavaBean.)
|
Distributed JavaBeans for web computing and information systems |
O'Reilly: Java in a Nutshell by David Flanagan describes JavaBeans as part of extensive JDK1.1 description |
SunSoft Press Java Series: coreJava 1.1, Volume II Advanced Features by Cay Horstmann and Gary Cornell has a chapter with good programming examples on all features of JavaBeans. |
Sybex: Java 1.1 Developer's Handbook by Philip Heller, Simon Roberts, Peter Seymour and Tom McGinn is a very detailed description of JDK1.1 including JavaBeans |
O'Reilly: Developing JAVA Beans by Robert Englander is a focussed description of JavaBeans from a Java Programmers point of view |
Coriolis Group Books: Web developer's guide to javabeans by Jalal Feghhi is an interesting discussion from ComponentWare perspective. Also has CORBA DCOM ActiveX OpenDoc |
See resources listed at http://www.npac.syr.edu/projects/tutorials/JavaBeans |
including Sun's JavaBeans page http://www.javasoft.com/beans/ |
"Reusable software components that can be manipulated visually in a builder tool." |
They are Java's implementation of "component-based" visual programming |
This modern software engineering technique produces a new approach to libraries which become a "software component infrastructure(SCI)" |
There is a visual interface to discovery of and setting of values of and information about parameters used in a particular software component |
JavaBeans uses the event model of JDK1.1 to communicate between components
|
The visual interface allows inspection of and implementation of both individual beans and their linkage (events) . This visual construction of linkage allows one to form nontrivial programs with multiple communicating components |
A Java Bean component can be a simple GUI component such as a Button or a complex program with many properties and methods such as a spreadsheet. |
Apart from the event mechanism used for communication and linkage, ComponentWare (and JavaBeans in particular) "just" give a set of universal rules (needed for interoperability) for rather uncontroversial (albeit good) object-oriented and visual programming practices
|
A JavaBean is "just" a Java Object which is part of some application for the end-user, i.e. it does not implement any particular class or interface. |
JavaBeans implement the JDK1.1 event linkage mechanism for exchanging changes in values of properties and hence invoking responses to these changes. |
JavaBeans implement JDK1.1 Object Serialization to represent JavaBeans in "databases" (disk files) and hence define JavaBeans as persistent objects |
There are a set of naming conventions called the "JavaBean Framework" or "Design Patterns"
|
These patterns are "discovered" automatically by the "introspection" capability of the reflection API. |
The BeanBox is a visual interface that displays (and allows changes to be made to) the properties of a JavaBean and further allows one to see and change the linkage between JavaBeans. |
A JavaBean consists of Java Code and possible associated files such as one or more icons, an image or two, a help file etc. This collection of entities is stored in a jar file which is based on the well-known UNIX tar file concept |
JavaBeans are naturally used as distributed objects in CORBA or RMI and can be linked to both JDBC (and hence databases) and COM from Microsoft. |
JavaBeans use the same event model as the AWT to communicate between Beans. The beans communication requires that Sources of information or events be linked to Sinks, who want to use information or respond to events. (Sinks are synonymous with observers.) In Java AWT, a listener class establishes this linkage with an event handler method. |
Source Bean |
Listener |
Sink Bean |
2) Notification of need to communicate |
1) |
Source Bean |
Sink Bean |
3) Communicate |
In the simplest case when one combines sink with listener, then one typically finds cycle (with any number of sinks)
|
To a standard hello world Java class, we add a (read/write) property by defining get and set functions in the correct pattern. |
import java.awt.* |
public class HelloBean extends java.applet.Applet |
implements java.io.Serializable |
{ String sname = "World"; |
public void setName (String newname) |
{ sname = newname; } |
public String getName ( ) |
{ return sname; } |
Enables saving as Object |
Instance variable for value of property (not available outside the class) |
Get and set methods define a property called "name" with a value of type String |
Additional methods make the bean have a visualization (canvas) |
public Dimension getMinimumSize() |
{ return new Dimension (250, 70); } |
public void paint(Graphics g) |
{Font f = new Font("TimesRoman", Font.BOLD, 36); |
g.setFont(f); |
g.setColor(Color.red); |
g.drawString("Hello " + sname + "!", 5, 50); |
} |
} |
Use the paint method to draw on the canvas |
New JDK1.1 method to tell Layout manager the minimum size of the canvas - also defines a (read only) property. |
The BeanBox from Sun BDK (Bean Development Kit) is a prototype visual builder tool. It is a little flaky and not as functional as a more sophisticated commercial builder tool, but can be used to develop beans. |
To run a bean in the BeanBox, the code must be put into a JAR file: after compiling the .java file, convert the .class file to a JAR file. |
Among the archive options are
|
Run the BeanBox and it will show the Toolbox window, the Beanbox window and the Properties window. Use the Loadjar command to open your new Bean and place it in the Beanbox window. |
Use as many copies as you want, using the property editor to change the name. |
JAR stands for Java ARchive. |
It's a file format based on the popular ZIP file format and is used for aggregating many files into one. It is the Java version of the UNIX tar and zip functions. |
Jar is
|
A JAR file may contain a variety of files including .class, image, sound, HTML pages |
The JAR file is stored in compressed (zip) fashion and can also be signed using standard digital signature techniques.
|
There is a "control" file called a manifest which is used to identify any JavaBean present. It also specifies a message digest algorithm. |
JavaBeans must be stored in JAR files and must be identified in a manifest. |
JAR files can be accessed from HTML using <APPLET> tag
|
Java looks first in .jar files for requested class |
The BeanBox can also be used to make a new bean from existing beans which uses components to control another bean. The event handler of the component can call a method in the other bean. |
Consider the standard example of hooking up two buttons to start and stop the Juggler animation bean.
|
The code created for this bean can be saved as a new bean. |
Start button |
Stop button |
startJuggling method |
Juggler Bean |
BeanInfo Icon |
This is the automatically generated file for the Juggler. It is the listener class whose event handler method (which is actionPerformed for buttons) links the source of the event, the button, with the sink of the event by calling the startJuggling method of the Juggler class. package tmp.sun.beanbox; public class __Hookup_140a49964da implements java.awt.event.ActionListener, java.io.Serializable { private sunw.demo.juggler.Juggler target; public void setTarget(sunw.demo.juggler.Juggler t) { target = t; } public void actionPerformed (java.awt.event.ActionEvent arg0) { target.startJuggling(); } } |
The beans shown in the previous section were all examples of beans with a visual interface. All Java components, such as applets and buttons, are beans and any subclass may be a bean with a visual interface. |
Other Java classes may also be beans. Without a visual interface, they don't show in a builder tool such as the Beanbox, but they may have methods that are useful to be linked from other beans. |
The builder tool uses introspection to analyze the names of the methods of a class to determine its properties, methods, and events in order to be used as a bean. |
Giving a set method defines a write property, and a get method defines a read property, according to this pattern: public void set<PropertyName>(<PropertyType> value); public <PropertyType> get<PropertyName> ( ); (where the first letter of PropertyName is decapitalized.) |
Although the typical actions of the get and set methods are to get the value of and assign to one or more variables representing the property, they may have additional actions. |
If the property type is boolean, the get() method can be replaced or augmented by a method: public boolean is<PropertyName> ( ); |
Properties can also have arrays of values. This is called an indexed property, and has two pairs of get and set methods: for the entire array and for individual values. For example, you can have a property named StockList, which had an indexed collection of Strings as its value: public String [ ] getStockList ( ); public void setStockList ( String [ ] values); |
And you can give methods to access individual values: public String getStockList (int index); public void setStockList (int index, String value); |
A property is bound if a change to its value can be reported as an event to other beans. |
In general, a bean can create events of type EventNameEvent by implementing methods called public void addEventNameListener(EventNameListener e) public void removeEventNameListener(EventNameListener e) and by making an interface called EventNameListener. |
A bean with a bound property creates PropertyChange events. In addition to the above methods, it must have a method called firePropertyChange which is executed for all registered Listeners when the property value is changed, such as in the set method. |
JavaBeans has a class to which has implemented these three methods for you: public class java.beans.PropertyChangeSupport implements java.io.Serializable ... public synchronized void addPropertyChangeListener ... public synchronized void removePropertyChangeListener ... public void firePropertyChange (String propertyName, Object oldValue, Object newValue); |
This class behaves as a source of events. |
The class with the bound property creates an instance of the PropertyChangeSupport class: PropertyChangeSupport pcs = new PropertyChangeSupport(this); and uses its add and remove listener methods. |
Then the class with the bound property must call firePropertyChange whenever it changes the value of the bound property (i.e. in the set method of the property). |
Any class which wants to be notified of changes to the bound property must implement the PropertyChangeListener and supply a method propertyChange that will be called with a PropertyChangeEvent. This method can use event methods getOldValue() and getNewValue.
|
A related concept is when another bean wants to have a possible veto over a change to a property, as in, for example, requiring a number to be in a certain range. |
The set method of the property throws an exception called java.beans.PropertyVetoException. |
The object must also support (by having add and remove methods) a VetoableChangeListener, i.e. the constrained property is also bound. |
Then each bean that wants to be able to veto property changes implements VetoableChangeListener by supplying the method vetoableChange(PropertyChangeEvent e) throws PropertyVetoException |
To update a constrained property value:
|
If more than one bean wants to veto property changes, then it may be quite complicated to work out when to keep the old value or move to the new value. |
Persistence of an object implies that one can save its value to some permanent store (e.g. a disk) and read it back |
This is implemented using Serializable (default saving) or Externalizable (user defined saving) |
In saving a Java Object, we save the values of data members but assume that the entity reading back object has access to class definition so that one just needs data member values to define instance
|
One needs to flatten the hierarchical linkage of objects to any root Java object |
In diagram, one needs to output members of A, B, C and D with D only output once! |
Object A |
Object B |
Object C |
Object D |
Root object |
Leaf object |
The Serialization interface is essentially a flag as there are NO methods or data attached to this interface -- implementing Serialization implies your willingness to be saved using default Java mechanism! |
The Serialization process is typically implemented by a container (Java Applet, Application, Java Beans Container) |
Typically one serializes to an output stream and deserializes from an input stream |
DataOutput Interface describes streams that can write out data in a machine independent fashion |
ObjectOutputStream class extends DataOutput (and an ObjectOutput Interface) and defines methods to write out variables of all the primitive types with a general
|
java.awt.Component class implements the Serializable interface and any bean extending this class or any of its subclasses is automatically Serializable and hence can be persistent |
Note Object class is not Serializable and so one must inherit from a subclass of Object that is Serializable in order to automatically get this property |
One can explicitly implement the Serializable Interface by supplying writeObject() and readObject() |
Beans should store references to external Beans as transient as linkage is responsibility of BeanBox |
Externalizable Objects must implement writeExternal() and readExternal() methods for user implemented persistency |
Introspection refers to the process by which JavaBeans are inspected to discover their characteristics. This a combination of
|
The Java Core Reflection API allows one to determine information about objects at runtime.
|
The reflection API is used in two ways:
|
First one invokes for any Object obj
|
Second process instance cl of class Class, has methods
|
These return public instances only |
Thirdly process arrays like Field, Method, Constructor etc. which are in java.lang.reflect and have a whole set of methods to find out further information including
|
So far the beans we've seen have used standard patterns to expose their properties, methods, and events to a builder's tool. For more general introspection, you can proved a class specifically to describe the bean. |
This class implements the java.beans.BeanInfo interface. |
If you have a Bean class named Xyz, the its beaninfo class is named XyzBeanInfo. |
If you don't want to supply new versions of all the methods in the BeanInfo interface, you can extend the class java.beans.SimpleBeanInfo, which provide null methods. For any method which is null, a builder's tool will use the standard reflection to find standard properties, etc.
|
getAdditionalBeanInfo() This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that provide additional information on the current bean. |
getBeanDescriptor() |
getDefaultEventIndex() A bean may have a "default" event that is the event that will mostly commonly be used by people when using the bean. |
getDefaultPropertyIndex() A bean may have a "default" property that is the property that will mostly commonly be initially chosen for update by people who are customizing the bean. |
getIcon(int) This method returns an image object that can be used to represent the bean in toolboxes, toolbars, etc. |
getEventSetDescriptors() |
getMethodDescriptors() |
getPropertyDescriptors() These three methods each return an array of the descriptor objects. |
BeanInfo can supply
|
BeanDescriptor is one of entities you can get from BeanInfo and this holds overall information about the Bean |
The Property Sheet box uses default java classes to read and write any property. You can provide your own methods by implementing the java.beans.PropertyEditor class. |
To do this, you register your editor with the PropertyEditorManager. |
You must also supply a BeanInfo class in which you override the getPropertyDescriptors method. In this method, you return the array of property descriptors as in the default, but in addition, you call setPropertyEditorClass for the property that you want to supply the editor. |
A simple property editor supplies methods (for the beanbox to call to display and get properties): getValue, setValue, getAsText, setAsText, and getTags. |
In addition, if you want to do more complex design time customization of the bean, possibly involving many properties, you can implement java.beans.Customizer. You may present a panel for the user to change many properties or run other methods of the bean class. |
In the custom property editor, you must implement methods isPaintable, paintValue, supportsCustomEditor, getCustomEditor, and getJavaInitializationString. |
The first methods allow you to present a GUI interface for changing the properties. The last method returns Java code that can be used to initialize the property value.
|
Bean |
Bean |
Bean |
Bean |
JDB |
JDBC |
Java Beans Framework |
Java Server |
CORBA Server |
Database Server |
RMI |
IIOP |
Particular |
Database Protocol |
IIOP is Internet InterORB Protocol |
At the moment, the main focus in JavaBeans development is at the client side for GUI/widgets engineering |
However, the technology is applicable also at the server or middle tier (where JavaSoft calls it Enterprise JavaBeans and develops the specification) |
We are currently building new version of WebFlow (data flow computing over the web) that uses JavaBeans both for visual editing and for server-side ComponentWare |
5)Actual Data Transfer |
This involves sources, listeners and observers and is an interesting multi-tier model of linkage/communication |
One can (in some cases) merge observer and listener but not the listener and source |
Registration involves sending an object name -- termed the callback object -- from the listener to the source. |
When event occurs, the source invokes a particular (event dependent) method of the callback object |
Events can be distinguished by using different callback methods (demultiplexing) or by inspecting the argument of a more generic method. |
Sources and Listeners use a "controlled syntax" but there are no special interfaces or methods for linkage of observers and listeners as usually(often) these are combined. |
The various listeners and events are named in pairs XListener (an interface extending java.util.EventListener) and XEvent (an object extending java.util.EventObject) |
Registration involves methods for the source called
|
Such naming conventions are part of the design pattern for the JavaBean (JDK1.1) framework |
X = Component, Focus, Key, Mouse, MouseMotion, Window, Container, Text, Action, Adjustment and Item in JDK1.1 AWT |
Source of any class |
Listener implementing XListener |
Source contains method addXListener |
Source creates Event of type XEvent |
Listener contains a callback object with several methods each accepting argument of |
type XEvent |
Register |
callback |
object |
Invoke Callback |
Here we contrast the simple "A sends a message to B" model normally used in computing with the more general approach in the JavaBean Linkage model |
Define an event ADataReadyEvent with A as source and B as combined sink and listener |
A defines an instance Evtcontrol of ADataReadyEvent which has a method transferdata |
B instantiates an object Bcallback implementing interface ADataReadyListener with a method readytogo() |
B registers this listener object as a callback with A |
When A is ready to send data to B, A callbacks Bcallback.readtogo(ADataReadyEvent Evtcontrol) |
B calls back Evtcontrol.transferdata(sink information) |
Note that "control" mechanism uses powerful JavaBean approach (this is handshake) whereas one can use a totally different and faster approach to actually send data |
Traditional (in my world) mechanisms combine control and data transfer |