see below
Daniel De Luca wrote:
> 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.
>
agreed, this takes some time, although its just putting some basic info
in the header like package/class/method names along with a couple other
things, 3 or 4 java assignments are pretty quick compared to even 1
distributed method call. So if I bundle a couple of requests ive already
made this time up.
>
> * 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.
>
agree here, this is also a tiny bit slower, although it would be just a
hash table lookup based on things in the header, and the object
servicing the request may need to do a cast.
thanks for the comments, I do agree that this method is slightly slower
than doing all direct calls, but im going to do some time testing to see
how much, I actually expect that its less than 2 or 3 % (of total time)
slower in the case of simple transactions. But in the case where I have
multiple requests bundled, I think this way can actually do better.
-Joel
> *
>
> 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".
>
===========================================================================
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".
