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".
