hey Tim, see below
> -----Original Message-----
> From: Tim Shephard [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, May 16, 1999 1:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity no more expensive than Session: WAS:
> findLargeAccounts - w hy bother?
>
> Hi Jim,
>
> Do you have one or multiple interfaces to your app server? We are in the
> situtation that we will have multiple end points for our data: our client,
> third party software, other internal products which want to integrate with
> ours, etc etc.
[Frentress, James] yes, we're in the same boat. we provide some
default mechanisms into our systems as well as an api that allows
development of adapters. we're currently creating an XML adapter. the
important thing is that all access ultimately goes through the same
mechanism.
> For that reason we have felt that session beans make for a
> nice way to create "application views".
[Frentress, James] in our architecture, we allow predefined views
but we also allow runtime-defined views. we find this is more flexible and
less maintenance. we're in total agreement about the desire to present an
application view, it's just the mechanism of providing it that we're
debating and specifically whether session beans are a good general
mechanism. i believe that pooled instances look good for this but i'm not in
agreement that the best general pooled mechanism is sessionbean.
> In other words, entity beans
> provide the building blocks that session beans assemble to serve a
> particular application / consumer.
>
> The picture drawn is quite nice, but it also make sense from a performance
> point of view. Perhaps the most important point is that client
> side(FAR-OUT, in your terminology) demarcated transactions is a big no-no,
> performance wise.
[Frentress, James] by design, our transaction demarcation is never
FAR-OUT (and currently i believe it's alweys IN) whether the ultimate client
initiating it is FAR-OUT or not. we achieve this with primarily with Broker,
Queue, and Command architecture.
> > -----Original Message-----
> > From: Jim Frentress [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, May 14, 1999 12:17 PM
> > To: [EMAIL PROTECTED]
> > Subject: Entity no more expensive than Session: WAS:
> > findLargeAccounts - w hy bother?
> >
> > Imre made the statement and i must admit that i tend to agree. We use
> > Session almost exclusively for bootstrap and client state.
> >
> > I'm less fond of "wrapping" entity with session than apparently most
> > posters
> > to this list. I have a feeling that it's because ITM is using EJB in
> > production so we have to solve real-life problems rather than academic
> > ones.
> >
> > I'm perfectly willing to be enlightened as to why I'm not properly
> > educated
> > on the topic. I can say that our system does not appear to be
> constrained
> > on
> > the appserver level (eg EJB) and as far as we can see, we're scalable
> > there
> > far into the future with clustering.
> >
> > So, who out there has a non-trivial system *in production* under EJB and
> > has
> > something to say about this?
> >
> > > -----Original Message-----
> > > From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
> > > Sent: Friday, May 14, 1999 11:30 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: findLargeAccounts - why bother?
> > >
> > <snip>The
> > > idea is to treat both entities *and* collections of entities as "first
> > > class" citizens. Since entity beans are no more expensive than session
> > > beans, we use entities for the collections to take advantage of
> > > CMP/caching/sharing and to have finer control of the bean instances.
> As
> > a
> > > matter of fact, we use session beans in our customer's architectures
> > only
> > > when client (or session) info has to be maintained on the server.
> > >
> > <snip>
> >
> >
> ==========================================================================
> > =
> > 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".
