William wrote:
"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."
Yes, this is one unfortunate reality of our solution. However, we convinced
ourselves that it was OK because clients had to deal with the fact that the
business object *might* be remote. Not a great justification, admittedly.
We also allow clients (our GUI in particular) to demand state objects (i.e. ask
their service session bean for them explicitly) and in so doing, avoid working
through the business interface. This relieves them of the hassle of dealing
with RemoteExceptions.
BTW: I'm not sure I'm "advocating", rather describing one working solution and
the trade-offs that led us there.
Tom Larson
Capital One Services, Inc.
804-934-8250
[EMAIL PROTECTED]
-----Original Message-----
From: "Louth; William (Exchange)" <[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".
