Interesting indeed.
We've made a conscious decision not to push the concept that far. There were
two main reasons:
1. After giving it some serious thought, it seemed to be complex undertaking and
we're basically lazy. That's somewhat tongue-in-cheek, but it did seem to be on
the wrong side of the cost-benefit break even line.
2. We are really hoping that EJB will some day mature to the point that it
specifies a client-side bean proxy API. Then you guys can worry about building
it and I won't have to.
-Tom
-----Original Message-----
From: Chris Raber <[EMAIL PROTECTED]>
Sent: Monday, April 10, 2000 12:05 PM
To: [EMAIL PROTECTED]
Subject: Re: 'local' entity beans vs dependent objects
Tom,
Your approach mirrors what we have done in our Developer's Guide. We have
perhaps gone a step farther by prodiving for life cycle services (i.e. CRUD
operations) in the service layer as well. The service layer delegates these
responsibilities to an Entity Bean (when Entity Beans are turned on, we can
turn them off and use an OR mapping layer independent of Entity Beans if
desired).
-Chris.
> -----Original Message-----
> From: Tom Larson [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 10, 2000 9:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: 'local' entity beans vs dependent objects
>
> I've been reading this thread for days with great interest.
>
> I have some questions for Marcus or Laird about the current approach.
>
> The Setup
> ---------
> The solution you propose involves wrapping entity beans with an EJB
> independent
> interface. However, a significant part of the EJB interface involves
> entity
> bean life cycle stuff -- i.e. creation, query, mutation, and destruction
> of
> persistent objects. These functions aren't specific to EJB persistent
> objects.
> If we wrap the beans then we have to develop our own API for these
> functions.
> It seems that we'll each end up with our own EJB-like, home-grown,
> persistent
> object management layer.
>
> The Questions
> -------------
> Is this what we want? Is this worth the cost given your assessment of the
> likelihood of swapping component models?
>
> Miscellany
> ----------
> We are using what we call "state objects" to pass entity bean state to
> clients
> to avoid what would otherwise be an incredible amount of getter traffic on
> the
> net. We also have developed "business interfaces" that both the state
> objects
> and remote interfaces implement. This allows us the flexibility to change
> our
> minds about whether a client should deal with remote interfaces or state
> objects. However, when it comes to life cycle stuff, we're using the
> stock
> standard entity bean interfaces provided by EJB.
>
> Humbly requesting your thoughts...
>
> Tom Larson
> Capital One Services, Inc.
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: Laird Nelson <[EMAIL PROTECTED]>
> Sent: Friday, April 07, 2000 5:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: 'local' entity beans vs dependent objects
>
>
> Marcus Ahnve wrote:
> > The point, at least mine, is to have an independent interface, and then
> > use EJB to implement that interface. No one has mentioned not using
> > session beans, they are far too useful preventing what you are
> > mentioning. But instead of having your session bean client - applet,
> > jsp, servlet, application - make a direct call with all the
> > InitialContext.lookup etc you wrap that code with an object that has an
> > EJB independent interface. That way you are EJB independent from a
> > client point of view. And since the session bean is a client to the
> > entity bean, let it call a wrapping object too. In the end you will have
> > all layers isolated and EJB independent.
> >
> > Laird, are these your thoughts too, or am I way off?
>
> Nope, you're right on.
>
> Cheers,
> Laird
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
