Re: distributed object design question/discussion

[Daniel De Luca]

Joel,

Well this sounds OK from the design point of view but what about performance (what most of the people are looking for)...
Your unique object is OK but the unique method sounds not so good from the performance point of view.
Why:

• The client as to create the header, aka, some piece of text that will be used to tell the session bean what to do with the data.
  This takes some time. It will be faster to call directly a specifc session bean's method with the data.
• At the server side, the unique method of your session bean need to first analyze the header (parsing the text) in order to know what to do with the data. Again here, the specific  session bean's method would know directly what to do with the data avoiding then the latency due to the "parsing" of the header.

Just my two euro-cents..

Daniel

Joel Nylund wrote:

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

begin:vcard
n:De Luca;Daniel
tel;fax:+ 32 2 714 42 22, +1-877-359-5506 (toll-free)
tel;work:+32 2 714 42 64 (direct), +1-877-359-5506 (toll-free)
x-mozilla-html:FALSE
url:http://www.ficsgrp.com
org:<center><a href="http://www.ficsgrp.com"><img SRC="http://www.ficsgrp.com/images/ficstop.gif" ALT="Visit FICS" NOSAVE BORDER=0 height=49 width=150></a></center>;<center>Research & Development</center>
adr:;;Excelsiorlaan, 87;Zaventem;Brussels;B-1930;Belgium
version:2.1
email;internet:[EMAIL PROTECTED]
title:</a><center>Technology Consultant</center>
note:<P><center><a href="http://www.bejug.org"><IMG SRC="http://www.bejug.org/images/gobejug.gif" ALT="Member of the Belgian Java User Group" HEIGHT=31 WIDTH=88></a><A HREF="http://www.politik-digital.de/spam/"><IMG SRC="http://www.politik-digital.de/spam/en/download/spam_h90.gif" ALT="Vote against SPAM!"  BORDER="0" WIDTH="92" HEIGHT="39"></A></center><P><B>VoiceMail/Fax (toll-free): 1-877-359-5506 <br>Private EMail: <a href=mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]</a></B><p>
fn:</a><center>Daniel De Luca</center>
end:vcard