I have been looking into the possibility of using EJB beans for a
variety of projects. It seems to me that for real life production
applications EJB is very difficult to use and to learn. Sure the simple
examples are easy and work well. In principle, EJB sounds great. The
idea of having a standard server and freeing the programmer from system
level programming issues sounds great. It seems to me that the reality
of EJB is that the programmer must still consider system level issues
and that he or she can no longer use traditional object oriented
techniques.
I''ll back this up with a concrete example. This example actually is
required for a real application but I have taken out some of the details
and changed some of the names. I know that similar things have been
discussed in other forms in various newsgroups and other EJB docs. I
have yet to see a good answer yet. The point is that using typical OO
programming this is easy, but using EJB I am forced to think of other
approaches. In this example we have to represent a certain kind of
graph called a PGraph. PGraphs have two kinds of nodes, ANodes and
TNodes. Both PGraphs, ANodes and TNodes have to be persistent. ANodes
are connected to TNodes and TNodes are connected to ANodes. The PGraph
has a distinguished ANode called the starting node. All ANodes and
TNodes added to the graph must be reachable from the starting ANode.
Using an object oriented approach I would create classes similar to what
is shown below. I have left out some details, like error checking and
exceptions.
public class PGraph
{
private ANode myStartANode;
private HashSet myAnodes;
private HashSet myTnodes;
public void PGraph(Anode a)
{
myStartANode = a;
myAnodes.add(a);
}
public void connect(ANode a, TNode t) throws NoSuchElementException
{
if(!myAnodes.contains(a))
{
throw new NoSuchElementException();
}
a.addConnectionTo(t);
myTNodes.add(t);
}
public void connect(TNode t, aNode a) throws NoSuchElementException
{
if(!myTNodes.contains(t))
{
throw new NoSuchElementException();
}
t.addConnectionTo(a);
myANodes.add(a);
}
public Collection getAnodes()
{
return myAnodes;
}
}
public class ANode
{
private Vector myTNodes;
public void addConnectionTo(TNode t)
{
myTNodes.addElement(t);
}
}
public class TNode
{
private Vector myANodes;
public void addConnectionTo(ANode a)
{
myANodes.addElement(a);
}
}
Now another important requirement is inheritance. I now want to define
something called ACNode and TRNode. ACNode inherits from ANode and
defines a number of new methods and TRNode inherits from TNode and
defines a number of new methods. From there I will inherit from TRNodes
and ACNodes to define many new classes. A PGraph will often end up
containing mixture of several types of TRNodes and ACNodes
(Polymorphism).
Using traditional object oriented programming representing this problem
is easy and I can freely use inheritance and standard classes like
Vector, HashSet etc... I can also use inheritance and refer to other
objects without difficulty.
The application I am considering needs to make the PGraph instances and
the ACNode and TRNode instances persistent. The method calls on
PGraph, ACNode and TRNode need to be synchronized since more than one
thread can call those methods at the same time. And of course the calls
will be remote calls. Adding those features will take take time. I may
also want to cache PGraphs and ACNodes and TRNodes for efficiency. That
is where EJB should help. But it seems that in order to achieve those
results I need to rethink the representations of PGraph, ACNodes and
TRNodes. It appears that I am no longer free to use classes like
Vector, HashSet etc.. Or if I choose to use those structures I will need
to do Bean Managed Persistence. And even in that case I don't think
this example will work correctly. For example, when I call getAnodes()
will I get a Collection of polymorphic types? That is essential for
this problem.
Bottom line is that I am not sure that I shouldn't just implement the
persistence, caching and multi-threading issues myself, because the EJB
approach would force a different almost unnatural implementation and
representation of the problem.
How about it? Can anyone come up with an EJB (1.0 or 1.1) approach to
this problem?
dan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
