EOB 1.1

About EOB
News & History
J2EE comparison
Bugs & Issues
Limitations of use
Info & Credits

Simple Stock Quote Servlet
People & Addresses Beans
Shopping Cart
Velocity Webapp
Clock Applet
Swing Bank Account


Hosted By
SourceForge.net Logo

EOB logo  Enterprise Object Broker

Development Direction

We've now released version 1.0.  CVS holds development version.  In there you'll find an Ant build file ; You'll need to get Ant from Apache ( http://ant.apache.org/bindownload.cgi)

Bean connection 

Beans perform a lookup on each others services with a single lookup method :
MyThing mything = (MyThing) serviceManager.lookup("MyThing");
Service Manager is passed in to the bean during its initialization.  JNDI is not used for this step.  When retrieved, the bean uses these resources as if they were local.

The current impl uses AltRMI (in beta at incubator.apache.org) to get and connect to beans.  This performs some serialization steps and thus is many times slower than direct wiring of beans. AltRMI also provides the means to lookup remote beans.  This is currently looked up in this way:
HostContext arhc = new SocketCustomStreamHostContext("", 7124);
Factory factory = new ServerSideClassFactory(false);
MyThing mything = (MyThing) factory.lookup("MyThing");
We are also planning a JNDI lookup addition to AltRMI at Apache.

Multiple Implementations.

As stated above the current bean connection impl uses AltRMI.  This is slower but allows (in one server) multiple versions of the same application & individual bean replacement while the machine is running.

We also plan on a design for local connections to use directly wired beans.  This will still support bean replacement while the machine is running but will not be so robust for situations where "common" interfaces change.  In practice even for big servers like Weblogic the support teams in question still prefer to bring down the server and re-launch with new jars.

Given that we envisage several designs for bean connection inside the machine and outside (to clients and federated servers) we plan to have multiple implementations of the core EOB "blocks".  The deployer of the application or applications would decide which implementations of the blocks to use at assembly stage (making the sar file).

Separation of a Bean's physical needs and configuration

Beans.xml in each bean jar describes its physical needs in terms of service dependencies.  Where that service is (local or remote) is not defined in that XML.  We plan a ApplicationConfiguration.xml file that describes the run time configuration aspects left out of the Beans.xml file. 

Lifecycle methods

We hope we can integrate more of Avalon's lifecycle methods into the system such that a bean can choose to implement any combination of them:

$Revision: 1.26 $ $Date: 2003/05/04 18:09:49 $