Ok I realize that the EJB front-end is really powerful. I think that with the new AOP design we can do frontend like stuff... let's try this as an excercise.
So
StatelessBean
JNDI.lookup(name);
home.create();
AOP Stateless
o = new MyObject();
since we pointcut the constructors we can completely bypass the creation in one VM. For the remoteness we have a slightly more complicated problem which reads "how do you get at the remote object". But inVM this is a trivial problem so the whole category of inVM persistent objects with cache can be done with these.
Same for stateful.
For entity.
Home home= jndi.lookup();
object = home.findByPrimaryKey(Pk);
or
object = home.findByQuery(query);
In the case of AOP on JBoss we would do
((AOP) new MyObject()).findByPrimaryKey(pk)
would return the entity instance identified by the PK (Pk in the sense of JDO or CMP2.0).
or
((AOP) new MyObject()).findByQuery(query)
would return the instance or collection. This needs a little bit more thought and should get inspiration from the EJB model on XML definition of return values.
The trick is to expose the home methods in the Object itself. I have a question for static methods. It seems clear to me that some of the AOP paradygm breaks for static methods somehow. I mean let's imagine we would have defined the finders as 'static' methods in the new class by adding the AOP interface. Syntactically I have a problem I can't say
MyObject.findByPK() as it won't compile, the class is enhanced at deployment time not compile time.
I could say
AOP.findByPK(class,pk); or AOP.findByPK(pk);
and the second one forces us to keep the mapping with the class that actually needs to be returned in the persistence layer somewhere. The first one explicitely says "use this class to do your work". EJB's do that implicitely as you are talking to a particular EJB class.
finders are some of the most powerful features of EJB, it is going to be tricky to copy them. Interesting.
