Rickard,
<vendor>
What cool functionality are you saying that will be restricted?, With
IIOP, we (and other vendors) can provide transparent load balancing and
failover??? I'm interested in why you think that RMI-IIOP *may* be a bad
thing.... Which highly optimized protocol does WLS server use that performs
"better"?
It is far more efficient if a common protocol is used rather than bridging
between protocols. IIOP can be wrapped with SSL and layered on top of HTTP.
</vendor>
regards,
-Robert
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
Sent: Monday, February 14, 2000 12:15 AM
To: [EMAIL PROTECTED]
Subject: RMI-IIOP only? was Re: How to get a container to know what
Principal iscalling it?
> The solution is not to find a work around for WLS, but to ask Weblogic
> to move to
> RMI-IIOP thus avoiding sending security context through JNDI evry
> times the
> servlet calls the bean.
> Servlets use RMI-IIOP to access EJB servers and like Evan Ireland says
> in the
> isCallerInRole()-thread, use IIOP to exchange security and transaction
> context
> between ejb clients and servers.
This touches upon an interesting subject:
Is it possible to deploy a bean and make it accessible through many
protocols? If not, then any server that uses a protocol that is more
optimized than IIOP, such as WLS, will have degraded performance if
RMI-IIOP is mandated.
IMHO I don't think it's possible to make a bean accessible through
several protocols simultaneously. Why not? Because, what would be the
result of the Handle.getEJBObject and *Context.getEJBObject()? Should
the stubs returned be able to support several protocols? If not, which
one should it be: the native one or a stub that supports IIOP? Either
way you run into trouble.
IMHO a better way to introduce interoperability is to have API's that
lets a stub figure out which security id and tx id is associated with
the current thread. This way that information can be extracted and
forwarded in any way it pleases. The only requirement is that the client
has installed the packages needed to support the stubs of the server.
This will of course make it troublesome to be able to call a server from
a C++ client, but in those cases I would simply use a server that indeed
uses IIOP as protocol. We would still have interoperability between EJB
servers.
Comments? If RMI-IIOP is mandated *and* my fear that it is only possible
to have one protocol at a time, EJB-servers will be severely restricted
in the ways it may provide cool functionality, such as transparent
fault-tolerance and load-balancing.
/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".
===========================================================================
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".
