"Rickard �berg" wrote:
>
> Arkin wrote:
> > Your argument supports, in my opinion, why IIOP should not be the only
> > protocol. However, your argument assumes an environment that is very
> > favorable to RMI, not very favorable to IIOP: who gets to publish the
> > smart stubs in a distributed system? why would company A allow stubs
> > coming from company B's server?
>
> Why should it not? It could easily use the Java Security API if you want
> to constrain what the stubs can perform (if it's security you're worried
> about).
Why should it? If I offer that version in an EJB server it's a nice
implementation detail that has immediate benefits. But I don't see that
as an EJB design decision.
I don't see Java Security API as being a solution, or a widely accepted
trust policy (see ActiveX for arguments on why not).
In many environments I would like to have stock stubs connecting to
whatever skeletons are on the other side, not borrow from them. I would
like my one stub to work with 3 different remote EJB servers. And
various other scenarios where the constraint to accept a stub from a
remote server is just that, a constraint.
> > how does that play with SOAP and similar
> > interoperability standards that do not use stubs?
>
> RMI/SOAP is being developed right now I hear, which would give us
> RMI-stubs using SOAP as wire protocol.
Not my intention. SOAP, forget about RMI stubs. Why go the extra layer
when the Servlet container can talk to the EJB directly.
> True, although this is more of a problem of how to propagate data than
> anything else. If each wire-protocol wants a particular format of this
> data, then use that.
Precisely my point. Leave it to the wire protocol. Let JRMP decide how
to do it. Let IIOP decide how to do it. Let SOAP decide how to do it.
Use the generic APIs that exist today (I agree some beefing up is
necessary) to have them all work with the same container.
arkin
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.dreambean.com
> Question reality
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
