Beans

When speaking about Sun Microsystems and components, the talk is always about beans. The currently most popular component of Java is most likely JavaBeans. Before we go into the difference between JavaBeans and Enterprise JavaBeans, we need to dive briefly into the world of componentware, without wishing to get involved in a full-blown discussion of the component paradigm. There are numerous books about components that show the variety of ways that this topic can be addressed. Here, however, we shall merely take a glance at the topic (which plays an important role with respect to Enterprise JavaBeans) in order to increase our understanding a bit.

In order to avoid misunderstandings we should mention explicitly that the intention of this book is not to give the reader instructions in how to develop good components. This book describes the component architecture of Enterprise JavaBeans, their practical application, and the requirements that components must fulfill if they are to be deployed in an EJB server.

Software Components

We would like to offer a definition of software components, cited in [6] as well as in [17], that represents a relatively neutral middle ground between the very broad and the very narrow:

A component is a piece of software that is small enough to create and maintain in one piece and big enough to offer useful and practical functionality and to justify its separate maintenance; it is equipped with standardized interfaces that allows it to cooperate with other components.

First, we simplify the view of a component by imagining it as a sort of Lego building block. The inner workings of the building block remain hidden from view. Nonetheless, one can see that it has connectors that allow it to be attached to other building blocks. A combination of suitable building blocks results in a structure that serves a particular purpose (a house, a garage, a road). Software components are also building blocks in that one cannot necessarily see inside (see Figure 2-4). Each component offers an encapsulated partial functionality (in analogy to Lego building blocks, such as the frame for a window, a stone as part of a wall, or a slab for the foundation of a house), while hiding its implementation. Its functionality can be deduced only from the public interface, which in addition to allowing it to be used, also permits linkage to other components. As with Lego building blocks, with software components the crucial property is reusability. A component that can be used in only one application scenario is not a genuine component.

Figure 2-4: Example of components in a commercial enterprise.

A component is distinguished from traditional objects or classes in a number of ways (see also [6]):

• Components must be able to be used in a variety of application scenarios and thereby be highly reusable. Traditional objects, on the other hand, are developed as a rule for a particular scenario. Furthermore, in fulfilling their appointed tasks traditional objects frequently make use of other objects and through this involvement make reusability more difficult.

• As a rule, objects are not big enough to deal with a complete task from beginning to end. They serve more for structuring and mapping to models.

• The development cost of a component is considerably greater than that of a traditional object, since with a component one must take into consideration both reusability in a variety of applications and the ability of the component to be integrated into a system.

• A component can be used only in a particular way that has been defined by the public interface. Objects can, by the process of derivation, be altered (almost) at will.

• Objects also offer the concept of the interface, which as a rule, however, is narrowly coupled to the underlying system technology and thus limits interoperability.

Undoubtedly, the close relationship between objects and components is clear. The object-oriented approach and techniques thus seem to offer the best basis for the development of components and component-oriented software.

A fundamental concept of the component paradigm is that of the interface. The interface of a component is a sort of contract whose conditions the components are obligated to fulfill. It is an interaction point with the components, documenting their features and capacities. A component can have several interfaces. Each interface represents a service provided by the component (for a detailed discussion of interfaces see, for example, [33]). Chapter 3 will show in detail how this aspect of components is transplanted into Enterprise JavaBeans.

An advantage of component-oriented software development is (as mentioned previously) in the reusability of code. A further advantage is the possibility, with the aid of completed components, of rapidly developing application prototypes (for an extensive treatment of this see [9]). The early availability of a prototype means that in the early stage of development one is already able to confront design choices; (pilot) customers or (pilot) users can be brought into the development process at an earlier stage, and so on. The reuse of code in the form of (mature) software components can lead to a shortening of development cycles and savings in development costs.

Component Architecture

As mentioned above, Enterprise JavaBeans is a component architecture. The domains of application and variety of forms of a component architecture can be quite diverse. Enterprise JavaBeans represents a quite particular variant: a component architecture for distributed, server-side, and transaction-oriented components. Thus Enterprise Beans are components that provide services to many clients on a single server. Without a framework that embeds the components into a sort of run-time environment and provides them necessary services, each component that is to be made available over a network would have to have its own server. This would make the development of such components much more difficult and if several components were deployed on one computer would result in an unnecessary strain on its resources. Even the reusability of a component could thereby become endangered, since servers must frequently be matched to the underlying platform. A component architecture such as Enterprise JavaBeans makes possible the deployment of components for distributed applications without the components themselves being significantly affected (see Figure 2-5).

Figure 2-5: Example of component architecture.

Griffel [6] gives a list of requirements that a component architecture must fulfill:

• Independence of the environment: Components should be deployable without reference to programming language, operating system, network technology, etc.

• Locational transparency: For the user of components it should make no difference whether the component offers its services in the user's local address space or in the address space of another, remote, computer. The requisite mechanisms for the transparent use of local or remote components should be made available via the component architecture.

• Separation of interface and implementation: The specification of a component should be completely independent of its implementation.

• Self-descriptive interfaces: To achieve a loose coupling of components at run time, a component should be capable of giving information about its capabilities and entry points.

• Immediate problem-free usability (Plug & Play): A component should be usable on any platform without having to be adapted in any way (which implies a binary independence of the component code).

• Capacity for integration and composition: In combination with other components, a component should be able to contribute to the creation of new, usable components.

However, Enterprise JavaBeans is not only a component architecture. The specification defines a system-technically oriented component model (for the notion of a component model, see, for example, [6]). This makes possible the implementation of various types of Enterprise Beans. It defines protocols for the management of components, for cooperation and communication of the components among themselves, and for the their use by a client.

JavaBeans Versus Enterprise JavaBeans

A JavaBean is a reusable software component that can be manipulated visually in a builder tool.

—Sun Microsystems, 1997

JavaBeans is a component model for Java produced by Sun Microsystems. A JavaBean is essentially a Java class that follows the rules laid down in the JavaBeans specification. The most important attributes of a bean are its public interface, the possibility of its being analyzed based on its composition, its adaptability to individual requirements, and its capacity for persistence (via object serialization). The public interface consists of the properties of a bean, the methods that it allows others to use, and the events that it receives or executes. A bean can be a visible (a button, for example) or an invisible component (for instance, a network service). Listing 2-1 demonstrates a valid JavaBean:

Listing 2-1: Example of a JavaBean.

 public class AValidBean implements AEventListener {     private int aProperty;     private Vector beanListeners;     public AValidBean()     {        aProperty = -1;        beanListeners = new Vector();     }     public void setAProperty(int value)     {        aProperty = value;     }     public int getAProperty()     {        return aProperty;     }     public void addBEventListener(BEventListener listener)     {        beanListeners.addElement(listener);     }     public void removeBEventListener(BEventListener listener)     {        beanListener.remove(listener);     }     private void fireBEvent() {        BEventListener l;        for(inti=0;I< beanListener.size(); i++) {            l = (BEventListener)beanListener.elementAt(i);            l.notify(new BEvent(this));        }     }     //Implementation of AEventListener Interface     public void notify(AEvent event)     {        //processing the event     } } 

This bean class is not derived from any class. It does not implement any standard interface, and is nevertheless a valid JavaBean (only visible JavaBeans must be derived from java.awt.Component). It simply follows the naming conventions established in the specification. It has the property aProperty, which can be manipulated and read by the methods setAProperty and getAProperty. Since it implements the interface AEventListener, it can react to the event AEvent. It triggers the event BEvent, for which other beans can register via addBEventListener and unregister via removeBEventListener. By exchanging events beans can pair with one another dynamically, since they can register and unregister for particular events at run time. This coupling over events is also a loose coupling, since the bean is abstracted from the actual type by means of the corresponding Listener interfaces.

With the naming convention type get property , void property (type), implements EventType Listener, void add EventType Listener(), and void remove eventTypeListener (), etc., a builder tool can, for example, analyze (introspection) the bean with the help of the Java Reflection API with respect to its properties and the possibility of binding it to events. The tool can place the user in a position to manipulate the bean visually. Thus the JavaBeans specification concentrates essentially on the description of the program interface for:

• recognizing and using properties of JavaBeans,

• adaptation of JavaBeans to particular circumstances,

• registering for events and sending then between individual JavaBeans,

• the persistence of JavaBeans components.

The Enterprise JavaBean specification, on the other hand, focuses on distributed computing and business transactions. JavaBean objects do not have a distributed character. The EJB specification describes a service framework for server-side components. Enterprise Beans are never visible server components. One may search in vain through the EJB specification for a discussion of properties and events of an Enterprise Bean, since it describes primarily the programming interface and the properties of the framework.

Of course, servers can be developed based on traditional JavaBeans. Then, however, the framework itself, which offers the components the relevant server utilities and sees to the distribution, would have to be developed. One could, however, imagine a combination of invisible JavaBeans and Enterprise Beans in which an Enterprise Bean provides a certain interface in the EJB server and delegates calls to JavaBeans (for example, by the triggering of JavaBean events).

One should not attempt to seek out too many similarities between the two models, since in spite of a superficial similarity in name, the two models are quite different in emphasis. However, JavaBeans and Enterprise Beans are not to be seen as opposing concepts, but rather as complementary.

The different viewpoints suggested by the words Enterprise, Java, and Beans will be made more concrete in the remaining chapters of this book. In Chapter 3, "Architecture of Enterprise JavaBeans," we shall investigate the extent to which the EJB specification corresponds to the viewpoint discussed in this chapter.