Dan,
Your message raises a number of important points related to added
functionality that will be coming in EJB 2.0. Among the items that we
plan to address in EJB 2.0 are the need for improved support for
relationships among enterprise beans and their dependent objects;
support for subclassing of beans; and improved support for the
persistence of entity beans.
EJB 2.0 work is being conducted under the Java Community Process, and
the CAFE period for this will be starting shortly. The EJB 2.0 JSR on
the JCP web site contains a brief description of some of the items on
the agenda. See http://java.sun.com/aboutJava/communityprocess/index.html
regards,
Linda
Linda DeMichiel
Senior Staff Engineer
Java Software, Sun Microsystems
[EMAIL PROTECTED]
> X-Accept-Language: en
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Sun, 27 Jun 1999 16:56:44 -0400
> From: dan benanav <[EMAIL PROTECTED]>
> Subject: Ejb, persistance, collections, reference to other beans, etc- Too
complicated!
> To: [EMAIL PROTECTED]
>
> 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".
>
===========================================================================
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".
