John Yu wrote:
> Hi Philip,
>
> > No, you just don't let the fine-grained objects talk in a fine-grained way
> > to the client. As far as the client is concerned, you wrap them up in a
> > coarse-grained Session Bean. The fine-grained objects interact with each
> > other in the server-side code; this is presumably how MSF works too,
> > otherwise it would have the same problems with inefficient fine-grained
> > interactions over a network.
>
> Yup, I understand that if my fine-grained Entity Beans are co-located with my
> coarse-grained Session Beans and I let the clients talk to only the Session
> Beans, it should eliminate most of the network traffic overhead.
>
> But this creates a problem related to the first question I asked in my first
> post. As soon as I require *massive* scalability, I may want to distribute the
> load across multiple machines. I will end up having the Session Beans running on
> machine A and the fine-grained Entity Beans running on machine B. The remote
> call overhead comes back.
>
> Besides, when the namespace-based load balancing becomes available (ie. having
> multiple objects running on different machines bound under the same name), I can
> no longer assume the Session Beans and Entity Beans are co-located.
>
> (Wayne Stidolph told me namespace-based load balancing would be available on
> Enhydra Enterprise.)
>
> Hmm, it seems one solution is to have the namespace-based load balancing engine
> smart enough to make sure the fine-grained entity beans run with the
> coarse-grained session beans on the same VM. (Is it possible, Wayne?)
>
> After these discussions, it seems to me while the issues I raised can be
> overcome, these issues are currently not addressed by the EJB architecture.
If you require massive scalability, it is because you have a lot of concurrent
clients running. In this case, even with todays hardware and network, you will
achieve scalability, but with a high latency. Let's assume that people will come
with good algorithms and hardware/communication designs in the near future. It has
happened all the time during the last 30 years.
What I mean is that the specification is not perfect. I would say that I'm sure that
Microsoft's one is neither perfect, and in addition you cannot peek into it, or
modify it, or run it in a Linux station. But both approaches offer a state of the
art solution (I have read that EJB is better than MS, but I don't know well enough
COM to know).
When I was programming in Smalltalk, 12 years ago, I could not even dream that a
similar environment would be used for deployment of System code now (like Jonas).
What looks too slow now will be the standard way to develop in the following years.
For now, we should try to find a compromise regarding speed, without screwing up the
scalability and modularity for the future.
>
> --
> John
>
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-users".
> 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 "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
