Actually, if the services fulfill coarse-grained operations using
fine-grained method calls, why don't they use O/R mapping? Why use
entity beans to begin with?
If you want to be close to the data, get as close as you possible can
(O/R mapping). If you want to be far from the data, select a
far-reaching architecture (EJB entity beans).
arkin
"Jon Tirsén" wrote:
>
> The major problem of putting entities separated from
> the session beans is that entities typically are more
> object-oriented and communicate using fine-grained
> method-calls, while sessions are service-oriented
> using coarse-grained method-calls. The services
> fullfill their coarse-grained operations using several
> fine-grained method calls on the entities.
> This makes it necessary (for performance/scaleability)
> to put the entities and sessions in the same
> address-space (ie. using local calls).
>
> So the irony here is: For performance the entity
> should be close to the data and the session should be
> close to the entity.
>
> --- "Ananiev, Alexander"
> <[EMAIL PROTECTED]> skrev:
> > I like the idea of getting database as much to do as
> > possible in terms of
> > persistence. And I have a question in that regard.
> > I'm currently in the
> > process of evaluating Oracle JServer which is EJB
> > 1.0 application server
> > embedded in 8i database. The idea is to put entity
> > beans (even though in
> > fact current version of JServer doesn't support
> > them) or some O/R layer into
> > Jserver which would get the persistence logic as
> > close as it can get to the
> > data. On the other hand, I can still have my session
> > beans with the business
> > logic running outside of the database in some other
> > application server which
> > is supposedly more scalable. So, has anybody on the
> > board happened to
> > implement similar architecture? What do experts here
> > think about the
> > usability of "embedded" as I call them application
> > servers (I know that
> > other vendors are also putting JVMs inside their
> > databases) ? And the last
> > question: would there be a problem to propagate
> > transaction context between
> > containers from different vendors?
> >
> > Alexander "Sasha" Ananiev
> > PricewaterhouseCoopers
> >
> >
> > -----Original Message-----
> > From: Louth, William (Exchange)
> > [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, April 10, 2000 3:56 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: 'local' entity beans vs
> > dependent objects
> >
> > Hi all,
> >
> > Are we advocating that the business
> > interface, that is used for
> > local
> > objects, have RemoteExceptions listed for
> > all methods. It will have
> > to if it
> > is also to be used for the RemoteInterface.
> > This seems strange
> > considering
> > that we are now dealing with local
> > state/details objects are
> > implying that
> > they are remote. This really is going to
> > cause confusion for the
> > client side
> > developer. Maybe I am reading this wrong.
> > Maybe what people are
> > really
> > saying is that the bean and state objects
> > are implementing the
> > common
> > business interface.
> >
> > One thing to consider before moving totally
> > away from entity beans
> > and to
> > session beans with OO databases. Entity
> > beans should not be just
> > data
> > holders they should do some useful work on
> > their internal state and
> > help
> > reduce the amount of the data sent across
> > the network. This comes
> > back to a
> > previous post I made on the inprise
> > newsgroup about this area:
> >
> >
> >
> ======================================================
> > Subject: Re: Design questions
> > Date: Fri, 4 Feb 2000 10:52:25 +0100
> > From: "William Louth"
> > <[EMAIL PROTECTED]>
> > Newsgroups: inprise.public.appserver
> >
> > My last post was not so clear so let me try
> > again.
> >
> > A good starting point is the following
> > pyramid:
> >
> > / User \
> > / GUI \
> > / Session Beans \
> > / Entity Beans \
> > / Database \
> > ====================
> >
> > What the above diagram is showing is a
> > layered architecture. I use
> > this
> > diagram with new recruits to help them
> > understand how to allocate
> > processing
> > over components. In terms of designing most
> > business systems we
> > should try
> > to do as much work (processing) at each of
> > the lower layers. The
> > larger the
> > layer the more data held. The following is
> > also based on the
> > Locality
> > Principle which means moving processing
> > closer to the data or
> > objects that
> > play together should stay together. So with
> > this we see that we
> > should get
> > the database to do as much as possible since
> > it has most of the
> > data,
> > actually all of the persistent data. What
> > this mean, well getting
> > the
> > database to do the filtering (selection),
> > sorting, computation
> > (computed
> > fields) .etc of the data before moving it up
> > to the entity bean
> > layer. The
> > more work this layer does the less the
> > entity beans have to do since
> > less
> > data is possibly passed.
> >
> > Note: I am not advocating building alot of
> > business logic into the
> > DB layer
> > in fact this is something I am not in favour
> > of.
> >
> > At the entity bean layer we should then
> > provide some methods in our
> > interface which provide bulk processing of
> > our internal data for
> > clients
> > (session beans). For example the premium
> > calculations of some
> > insurance
> > policy object, our state returned in one
> > method call, etc.. In terms
> > of good
> > OO design this is better. What we are trying
> > to do is reduce the
> > amount of
> > data we pass up the pyramid i.e. to our
> > clients, by processing more
> > of it.
> > At the session bean level we should try to
> > do as much as possible to
> > the
> > entity data we have extracted before
> > returning to the client. This
> > in our
> > case manifests itself in returning objects
> > which represent customs
> > views of
> > our entity data, in most cases these views
> > do not include all the
> > objects
> > processed and their properties.
> >
> > At the user interface layer we should do
> > better tasks analysis to
> > refine the
> > information that is displayed to the user,
> > looking at what objects
> > are
> > involved, what information on these objects
> > needs to be displayed
> > and at
> > what point in the task is it best to provide
> > the information. In
> > many
> > interface designs too much data is usually
> > given to the user which
> > requires
> > them to do more processing (mind) before
> > they can get the
> > information they
> > need to peform their task efficiently.
> > ....
> >
> > With distributed computing we should be
> > logical designers who are
> > reluctant
> > physical designers.
> >
> === message truncated ===
>
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
