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.
.........
Basically the motto is telling us all that though we should strive
to build
OO models that reflect the domain model we should bear in mind that
this is
a distributed computing system and hence our designs must also
reflect this
remoteness in some ways or we will suffer performance problems which
leads
to a failed project. For example the getDetails method on most of
our beans
just does not seem to fit with our initial model since we assume we
can just
call getName, getAddress.....
kind regards
William
AT&T
============================================================================
===
kind regards
William Louth
> -----Original Message-----
> From: Marcus Ahnve [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 10, 2000 7:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: 'local' entity beans vs dependent objects
>
> > 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.
>
> Stock standard = just the regular, right? I reread your post and I
think
> I understood it this time. If so I believe that the last part of
my last
> post did not address your question, sorry about that.
>
> What do you get by having the state objects implementing the same
> interface as the remote interface does inherit, apart of the
> changability between them and remote interfaces? To me this seems
like
> creating a proxy instead of the adapter which would allow for
greater
> flexibility.
>
> As far as life cycle goes I have this idea about having the a bean
> returning a object by value for modification on the client and
then
> updating it to the persistent storage, as I mentioned in my last
post.
> This was what we did in a non EJB environment (NetDynamics 4) when
I was
> involved in a large travel booking service where the business
rules were
> ridiculously complex. However after following what the people from
> Gemstone and Versant has had to say about this topic I'm not
certain
> that I want the entity beans at all, I'm right now more into
having it
> their suggested way with a session bean accessing a object
database.
>
> And I really think you can do the most awesome things if you put
Jini
> into the mix, for the appropriate systems of course.
>
> These are just vague thoughts though, I hope to be able to try
them out
> later.
>
> Regards,
>
> /Marcus
>
> Marcus Ahnve
> Sun Java Center
> Sweden
>
>
==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation,
solicitation,
offer or agreement or any information about any transaction,
customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
