Active Bean Space

Dmitri Kondratiev
d.i.m.a@bigfoot.com

Created : September 97
Last Modified : November 17, 97
URL of this document : http://geocities.datacellar.net/SiliconValley/Lakes/3767/abs.html

Contents

Abstract

This paper describes a partitioning model based on context hierarchy in distributed object (D-O) spaces, created with Java ORBs such as JavaSoft RMI(TM) or ObjectSpace Voyager(TM). Grouping objects by semantic contexts facilitates deployment of D-O environments considerably, providing for easy resource discovery and allows dynamic configuration of context communication and synchronization properties in run time.

Active Bean Space (ABS) described in the paper is a model of distributed context framework that conforms to Glasgow proposal for Runtime Containment and Services Protocol for JavaBeans and attempts to address the following goals :

Intro

Active Bean Space extends Context/Membership model to the distributed object space, to provide for uniform and effective communication of components (beans) in this space.

Active Bean Space is an abstraction of hierarchy of contexts containing other components (which may also be contexts) in distributed object space, that conforms to Glasgow proposal for Runtime Containment and Services Protocol for JavaBeans. Thus Active Bean Space interface extends java.beans.BeanContext interface.

Active Bean Space (ABS) - is a space of distributed, mobile and active objects - active beans.

ABS may nest the following types of components :

Active beans are mobile because bean space provides means for them to move.

Active beans are active because they are allowed to exhibit behavior in bean space by making decisions, such as to move or not if requested by Active Bean Space, as well as initiating move themselves with notification of nesting context.

In other words beans in ABS context may be cooperating agents. That's where bean persistence comes into play. When beans move from one ABS context to another they serialize their state right before they move and deserialize it at destination. Mobile bean is an agent that doesn't have his own independent execution thread but can serialize/deserialize itself and get ready to move or execute some method at destination. Active bean is an agent that can not only serialize/deserialize its state but has independent execution thread and can make decisions itself when and where to move.
Later in the text "beans" means both active and other beans.

Distributed Context Hierarchy

ABS provides a context support for nested components - active bean spaces and other beans, located on arbitrary set of network hosts. Applications may dynamically, in run time create contexts, based on arbitrary criteria to accommodate their needs. For example, context may include beans of particular type, such as distributed GUI components. Universal nature of context/member relationship can be used to describe any system resources such as "remote console server context" deployed on some server host. Every such context will nest "remote client terminal beans/contexts" of the client machines logged into that particular server.

Another example may be a protection domain context including resources (objects) currently directly accessible by some principle of trust. Contexts may be also created to reflect network topology, such as a context containing objects instantiated on some set of hosts connected to the same intranet or network. Components nested by some context may also belong (be nested) by other contexts. For example, "global" GUI beans context may be partitioned by smaller "network" contexts of GUI beans that are members of some particular network.

Active Bean Space framework abstracts from underlying network and may use RMI, Voyager or any other Java ORB to communicate component state. For a network host to participate in Active Bean Space it must have Context Distribution Protocol (CDP) installed. When installed, among other things, CDP provides access to the top level ABS context, which nests all child ABS contexts hierarchies. Later in this text "context" is used as a shorthand for Active Bean Space context.

All components (contexts and beans) in any nesting context are represented by special component proxy objects created by Proxy Generator utility at compile time from component class or source file. Component proxy class implements all public interfaces exposed by the component. In case component does not explicitly expose any public interfaces, proxy class implements only public property accessor methods conforming to Java Beans design patterns : 

// setter/getter methods for a property with :
// name :== <PropertyName>
// type :== <PropertyType>
public <PropertyType> get<PropertyName>();
public void set<PropertyName>(<PropertyType> a);

// getter method for boolean properties with :
// name :== <PropertyName>
public boolean is<PropertyName>();

// setter/getter methods for an indexed property with :
// name :== <PropertyName>
// element type :== <PropertyElement>
public <PropertyElement> get<PropertyName>(int a);
public void set<PropertyName>(int a, <PropertyElement> b);
Proxy class aggregates two distinct interfaces to access the same component locally and from remote location. Proxy instance is constructed with a reference to the component object that this proxy will represent. Thus proxy object is a wrapper of the real component in the nesting context. So, when adding some bean or context to a nesting ABS context, corresponding proxy object is added to this context instead, such as : 
ABSContextImpl absContext = new ABSContextImpl(...);
AType obj = new AType(...); //real component
absContext.add(new ATypeProxy(obj)); //add proxy to context

Every ABS context maintains his own cash of proxy classes representing members in this context. Local interface of the target proxy object is used by other objects requesting access to a target, that reside on the same host as the target object. Remote interface of the target proxy is used by components requesting access to a target, that reside in the different address space (e.g. remote host).

The only way to access nested components of ABS Context, is by means of toArray() or iterator() methods defined in java.util.Collection interface, which BeanContext extends : 

public interface java.beans.BeanContext
       extends   java.beans.BeanContextChild,
                 java.util.Collection {
...
}
public interface ABSContext extends java.beans.BeanContext {
...
}

Application iterating context member components will get an enumeration of proxy objects corresponding to this context members. When returning a reference to some proxy object, ABS first checks if proxy is bound to the local instance of the member component. If member component is currently instantiated in the address space different from the one where application is running - ABS verifies binding of the proxy to the remote instance of this component.
Note: In ABS any component may move from one address space to another while continuing to be a member of the same context. Context Distribution Protocol guarantees that component proxy is correctly "bound" to the component it represents. At any given moment this binding may be local or remote.

When new component is added to the existing nesting context, the following main steps are taken :

Membership Operations

Active Bean Space extends java.beans.BeanContext interface and provides access to nested contexts as well as other beans. Thus Active Bean Space is an abstraction of bean environment (context) and provides BeanContext functions, which are : All ABS context operations are performed by Context Distribution Protocol which is based on Horus Virtual Synchrony model.

Bean Communication Environment

ABS Context provides communication environment for its members - beans. To communicate in ABS contexts beans are not required to know anything about ABS. Thus 3rd party beans can be easily distributed. To provide for transparent bean communication, ABS Context implements event adaptor, interposed between event sources and real event listeners to deliver remote events.

Thus ABS context conforms to the particular EventListener interface expected by the event source members, and decouples the incoming event notifications on the interface from the actual listener(s).

Adding Members to Context

When new member is added to some context, ABS runtime introspects and reflects on this new member proxy object to find out : As a result of this introspection/reflection, ABS runtime internally maintains a BeanInfo object for each added component. Next, ABS runtime register itself as a listener for events that nested component generates. After receiving some event from nested component and determining this event type, ABS runtime checks if any other nested beans implement Listener interface corresponding to the received event type. If any such listeners are found, ABS runtime sends event to them.

Context and Member Policy Support

Extending BeanContext, ABS context introduces policy support for its nested components. ContextPolicy is ABS context property which in general case may have different "value" in different context instances. ContextPolicy encapsulates a collection of ABSPolicy objects that may be used to specify the following context preferences shared by all context members :

Apart from "global" context preferences shared by all members, ABS also allows context members to specify individual preferences. Individual member preferences are specified by MemberPolicy objects. MemberPolicy encapsulates a collection of ABSPolicy objects that may be used to specify the following member preferences :

Event Delivery

To send events to the listeners ABS runtime uses corresponding listener proxy objects nested by this context. First local interface delegate of the listener is requested. If local delegate is available, which means that listener object resides in the same address space as event source, then event is sent directly to the method specified in the corresponding Listener interface of the local delegate. If listener proxy object doesn't aggregate local delegate, event is sent to the remote interface delegate of this proxy object.

Event is sent to remote interface by means of a protocol specified by a protocol stack set in this context CommunicationPolicy property. When received by remote context where "real" listener object is instantiated, the event is then routed to the local delegate of the listener proxy aggregate.

Property "name-clashes" may happen in the context when several beans treat some property semantically different, while property name is the same (such as "value"). In such cases, additional contexts may be created to avoid property name-clashes.

Property Access

ABS Context provides property access support for its members. Bean properties are always accessed via method calls on local or remote delegates of member proxy aggregate object. For readable properties a getter method is used to read the property value. For writable properties a setter method is used to change the property value.

In case the object calling property access methods belongs to the same address space as a target bean does, method call is dispatched to a local interface delegate of the proxy aggregate. Otherwise remote interface delegate of the proxy object is used. Property access on remote interface are performed by CDP protocol.

For 3rd party beans, unaware of ABS context, access methods work in synchronous mode only. Beans aware of ABS context may perform asynchronous calls on other members specifying an extra argument that implements ResultListener interface. 

public interface ResultListener extends java.util.EventListener {

  public void handleResult(ResultEvent rev);
}
Thus, ABS aware components can use property accessor methods that conform to the following design patterns : 
class ResultListenerImpl implements ResultListener {
...
}

// setter/getter methods for a property with :
// name :== <PropertyName>
// property type :== <PropertyType>
// result listener type :== <ResultListenerType>
public <PropertyType> get<PropertyName>(<ResultListenerType> rl);
public void set<PropertyName>(<PropertyType> a, <ResultListenerType> rl);

// getter method for boolean properties with :
// name :== <PropertyName>
// result listener type :== <ResultListenerType>
public boolean is<PropertyName>(<ResultListenerType> rl);

// setter/getter methods for an indexed property with :
// name :== <PropertyName>
// property element type :== <PropertyElement>
// result listener type :== <ResultListenerType>
public <PropertyElement> get<PropertyName>(int a, <ResultListenerType> rl);
public void set<PropertyName>(int a, <PropertyElement> b, <ResultListenerType> rl);

Context Distribution Protocol

To distribute containers context Active Bean Space uses Active Network approach. Thus, Active Bean Space runs in the network of active nodes, simultaneously supporting a dynamically changing context hierachy. ABS extends Active Network approach from network to application layer, which allows support of different communication policies, such as Virtual Synchrony on application layer and reliable multicast on network layer, based on QOS approach.

Similar to lightweight protocol used by MIT ANTS system to transfer capsule programs incrementally from one node to another, Active Bean Space uses Context Distribution Protocol (CDP) to propagate ABS context along network of ABS nodes.

CDP functions :

TBD...


since 11 March 1998
1