Folks,
I posted this in [EMAIL PROTECTED]
You may be interested in its subject matter.
For "I'd like to get involved" type comments, that mail-list would be
best joined. For disses, put downs etc, here in avalon-dev is fine :-)
- Paul
-------- Original Message --------
Subject: New Project - Alternative Java Beans
Date: Sun, 20 Jan 2002 22:03:51 +0000
From: Paul Hammant <[EMAIL PROTECTED]>
Reply-To: "Avalon Applications Developers List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Folks,
Perhaps I'm guilty of thinking of a use for AltRMI. Perhaps as has been
suggested I have some sort of compulsion to code. I've talked this
through with Gerhard and he thinks at worst it is a good design
excercise for Pheonix app construction. He thinks at best it could be
viable as a application server, though perhaps not for some time.
*Exec Summary*
An alternative to EJB. Either to be known as AltJB or AJB. Based on
Avalon-Framework lifecycle methods/interfaces. Uses AltRMI for glue
between beans, either in the same container or from/to elsewhere.
*List of Features*
Different to EJB in these ways:
a) Sitting on Phoenix (it is itself a regular SAR file app)
b) Using AltRMI (no remote or home interfaces needed)
c) Uses IoC for all actions. Most of the Avalon Framework intefaces are
just as applicable (Composable, LogEnabled, Configurable).
d) As consequence of (b) and (c) no JNDI needed for bean lookup.
e) Can use other services provided by underlying phoenix machine.
f) Lessof a distinction between session and entity beans.
The same as EJB in that:
g) beans come in jars that have xml for config.
h) beans in separate classloaders.
i) they don't actually know whether the bean they are depending on is
local or remote.
*Justification from Modelling point of View*
_Steps to build an AJB app_
Define a java-interface model of your application. Remember that
following the facade pattern in the context of EJB, we decide which
things are beans and which are "Value Objects" (is that term in common
use yet?).
interface Family {
Person addNewBorn(String name, Date dob);
Person[] getPeople();
}
interface Person {
getName();
getDOB();
getGender();
}
interface MalePerson extends Person {
getBeardColor();
}
Clearly Family would be a facade and Person (and its derivatives) would
be value objects.
Given that both EJB and Avalon advocate separation of interface and impl
we can understand without detailed explanation that the Family facade
could have multiple implementations. One could use Cornerstone's Store
or Gerhard's commons Store for persistence, another could use JDBC for
storage. These multiple implementations could share common code and
abstract the differernces away conveniently.
*What would the jar contain?*
Well along the lines of EJB, some classes, a manifest and some XML on
the same lines as ejb-jar.xml
*How does this differ to Phoenix proper?*
Good question. Both Pheonix and AJB support apps distributed in zip/jar
form mounted into a container.
My feeling is that there are some small differences :
1) Scope of hosted apps
In Phoenix the app hosting allows full server applications. The apps
have no cap on their activities. They can spawn multiple threads and
classloaders and implement any weird and wacky server concept. IETF RFC
& standard server concepts are favourite.
With AJB the bean is constrained. It should not pawn threads or mount
classloaders. It should be a simple request/reply bean that may or may
not have state and may or may not be able to persist itself.
2) Packaging
Pheonix takes sars that have jars inside. AJB has very simple jars :
MyBean.jar --->
myco/facades/Family.class
myco/impl/DefaultFamily.class
myco/shared/Person.class
myco/shared/MalePerson.class
myco/shared/FemalePerson.class
AJB-INF/ajb-jar.xml
I.e. no other jars. Simple and small. Directly mountable into a URL
classloader.
3) Life Cycle
At this stage I don't think that Framework's Startable is needed.
Methods start() and stop() don't seem to me (at this stage) to fit
application server bean. LogEnabled, Configurable, Composable all seem
to fit. Also there is need for some IoC/EJB like instructional
interfaces. Methods activate() & passivate() seem to have suitablility.
4) Replacability whilst in use.
EJB does it (in theory) and AJB should to, the bean itself should be
able to be replace/upgraded whilst in use. Pheonix will want to stop(),
<replace>, start() the app.
5) ComponenetManager
AJB would mount its own component manager. When a lookup on a role is
done by a AJB bean, then the it could be for other AJB beans (local or
remote) or for an underlying Phoenix service, like say the most
excellent Jo!
We could specify a context like prefix for the AJbeans....
Family family = (Family) mComponentManager.lookup("AJB:Family");
JoService joService = (JoService)
mComponentManager.lookup("Phoenix:JoService");
In the case of the latter, the AJB container would reroute this request
as...
return mPhoenixComponentManager.lookup("JoService");
*Unresolved questions*
Should we/I start this in <Cornerstone>/apps/ajb ?
Or should we choose SourceForge for a change (albeit with Apache license)?
Gerhard thinks it will be easier to build a community on sourceforge.
Something that others find way easier to do!
Regards,
- Paul H
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
