One way to solve this is to use a "copy" object. Your entity bean remote and
home interface may look like:
public interface Employee extends EJBObject {
EmployeeCopy getCopy() ...;
void updateFromCopy(EmployeeCopy copy) ...;
...
}
public interface EmployeeHome extends EJBHome {
Employee createFromCopy(EmployeeCopy copy) ...;
...
}
Here you transfer the entire state of the entity object to the client.
The "copy" object should be design to integrate well
with the data binding mechanism on the client (i.e. it can use the JavaBeans
protocols).
A variant on this is that instead of getting the copy of the *whole* object,
you get only a copy of the part of the object that is used by the particular
client use case. For example, you can define methods:
Address getAddress();
void updateAdress(Address addr);
Vlada
-----Original Message-----
From: Joel Nylund <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, June 03, 1999 3:09 PM
Subject: distributed object design question/discussion
>This question, or discussion could probably work in any distributed
>object forum, but since im encountering it in ejb I figure this will be
>as good of place as any to ask. So I appologize if its slightly off
>topic.
>*************************************
>
>In designing distributed object systems, I have learned over the years
>(as im sure most of you have) that you should try to make the
>distributed objects and methods as course grained as you can to minimize
>
>network traffic.
>
>So for example, if you have an Account object, with several instance
>variables, like name, number, balance. Instead of making distributed
>calls to setName, setNumber, setBalance, you would probably make one
>call to updateAccount(name, number, balance) or something like that.
>This way you only have one network call, instead of 3 in the other
>case.(so in the case of ejbs, the remote interface would only have 1
>method here)
>
>Now, determining what is too fined grained seems pretty easy. For
>example, if I can bundle up several requests into one then I should do
>it. The problem for me is where do you draw the line on the other end
>(when is it too course).
>
>For example, if I have a stateless server (one where each transaction
>request relies on no state from a previous request, ala Stateless
>Session bean).
>
>I could easily wrap all distributed requests in one bean, lets call it,
>MediatorBean, with one remote method, lets call it "process". The
>process method could take an argument object that is serializable, which
>
>could contain just about anything. Lets say for the example, it is a
>Data object, with a Header object, and a AppData object contained inside
>it (as an ivar).
>
>In this scenario, all client requests could be sent to this one
>distributed method, it could look at the header object, and then forward
>
>the request on to the appropriate component for processing (could be a
>bean or not, doesnt really matter). With the use of reflection, the
>MediatorBean could just load the components necessary to process given
>requests. Each component would then know how to look into the data
>object to determine how to process the request, and could inclose the
>retun data in the same object
>
>So the advantages of using this type of design are as follows:
>1. Simple distributed api, there is only one object and one method
>2. Minimul network usage, one api, could handle many transactions
>requests. (ie. I could bundle the requests, to updateAccount(),
>setBalance(), and makeTrade() all as one request).
>
>So what is the downside to this design? Well I guess that is my
>question, I think one thing is that it may be difficult to load balance
>based upon different activities (ie all account related stuff goes to
>this server, all customer related stuff goes to another, like you can do
>
>with multiple homes). It could also be difficult to use this design if
>you needed state.
>
>what do you think?
>thanks in advance
>-Joel
>
>===========================================================================
>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".
