Ed, as usual you're right on target because..
>For example, a local inter-bean call could be a lightweight call that was:
>* in-process
>* used pass-by-reference
>* had no stub, nor skeleton
>* had a very thin EJB object that did not add a great deal of middleware to
>the call, such as security checks (After all, why would you ever need to do
>a security check when an Order calls a LineItem? You'd want that security
>check to happen when the client calls the Order, but not when the Order
>calls the LineItem).
.. <vendor>E*Boss 2.0 will support all of the above. You're absolutely correct</vendor>
>A remote inter-bean call could be:
>* out-of-process
>* used pass-by-value
>* had a stub and skeleton
>* have a thick EJB object with a great deal of middleware, such as
>transactions, security, and other middleware checks.
You're correct, except <vendor>E*Boss 1.0+ never have thick EJB objects or
stubs/skeletons. We just stick with thin, or non-existent really, and that works just
great in all cases :-) </vendor>
>As I understand it, the Inprise Application Server as well as others allow
>you to optimize inter-bean communications in a similar way to the above
>proposal. Would this not allow the application developer to make a more
>fine-grained object model?
Absolutely, although to my knowledge <vendor>E*Boss is the only EJB container that
supports the intra-vm optimizations as well as them very thin EJB-objects thing
</vendor>.
>There are problems I can see with this proposed approach. The ones most
>obvious to me are:
>
>* I do realize that Inprise has done this in a proprietary way, and there is
>no standard from Sun for a local verses a remote bean.
Well, there are two points here. If you do call-by-reference that's going to change
semantics, but if you only bypass the network layer and have the thin EJB-object thing
in both cases then there really are no issues.
And, as a coincidence, <vendor>E*Boss supports that</vendor>.
>* RMI marshalling semantics are not preserved when a developer writes an
>application that:
> * Leverages local inter-bean calls
Not necessarily. You can do intra-vm optimizations and still do pass-by-copy.
<vendor>We do that by defult, but have the option to skip the copying.</vendor>
> * Relies on RMI pass-by-reference semantics
True, although relying on it would be bad programming style anyway.. (I mean, the bean
being called shouldn't modify the parameters!)
> * And then, that bean is then redeployed into a container that does not
>support local inter-bean calls, violating the pass-by-reference semantics,
>and changing the application
See above.
>But if Sun standardized on a formal way of controlling local vs remote
>inter-bean calls, then both these issues would be solved. For example:
<vendor>
Well... in our case we:
1. Always have thin EJB-objects=cheap to do EntityBeans
2. Can set call semantics on a bean basis. If you're doing it right then you're ok,
but if not, you can still benefit from skipping the RMI-stack.
</vendor>
>This technique would solve both the problems I eluded to earlier with
>dependent objects:
>
>1) You can access a 'local' bean without going through its parent, since a
>'local' bean is still an entity bean. Not true for dependent objects.
>
>2) You can promote a 'local' bean to a 'remote' bean without changing its
>clients, since both are entity beans. Not true for dependent objects.
>
>What do you think?
<vendor>As above. In E*Boss there really is no penalty for doing it, so.. we don't
care really. :-) </vendor>
/Rickard
ps. Sorry about the extreme <vendor> thing, but I'm at a conference and am all worked
up and excited about it, ok..!! :-)))
pps. The url is http://www.ejboss.org, soon to be http://www.eboss.org
ppps. Did I mention it's OpenSource (=Free!)? Ok, well, it is.
===========================================================================
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".
