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