 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("127.0.0.1", 7124);
Factory factory = new ServerSideClassFactory(false);
factory.setHostContext(arhc);
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 $