| Enterprise Object Broker
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
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("127.0.0.1", 7124);
Factory factory = new ServerSideClassFactory(false);
MyThing mything = (MyThing) factory.lookup("MyThing");
We are also planning a JNDI lookup addition to AltRMI
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
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
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.
We hope we can integrate more of Avalon's lifecycle
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 $