Hi Tom,
"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."
Does this mean that you have coded your client to deal with two classes
(state and business) for every domain like object. Sorry if I am reading
this wrong.
William Louth
> -----Original Message-----
> From: Tom Larson [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 10, 2000 9:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: 'local' entity beans vs dependent objects
>
> 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".
***********************************************************************
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".
