IIOP supports transaction propagation, RMI doesn't. That simple.
IIOP partially supports security context propagation, but that's not
good enough. Unlike transaction context, security context is complex to
deal with, if you consider that a distributed system may cross
boundaries of different environments with different security realms. So,
it's a much harder issue to deal with.
At the same time, if we can standardize on what would be the proper
credentials to pass, how to translate across security domains, I don't
see a problem with having it easily supported in IIOP.
At least Kerberos authentication over IIOP seems to be working.
arkin
Matt Kleiderman wrote:
>
> I've been reading this thread with a fair amount of interest. While I'm
> distressed at the tone the discussion has taken, I do believe that this is a
> reasonable forum for discussing different vendor's implementation of the
> standard. It provides EJB developers useful market information about the tools
> available to them, and it provides feedback to vendors and spec creators to use
> in future versions. Techies will be techies, and I expect a certain amout of
> sharp language to be used in these spaces, but it would make for a more better
> read if we could all keep a more civil tone.
>
> It seems to me that there are actually two parallel issue being debated in this
> thread. One is whether all container vendors should support a common wire
> protocol so that containers can freely inter-operate. The second is whether
> RMI/IIOP is a good protocol for a common wire protocol because of it's network
> and API characteristics.
>
> On the first I feel very strongly that containers should be able to
> inter-operate at spec levels. That is, a client shouldn't need to know the
> vendor of the container. It doesn't matter if the client is an Applet,
> application, Servlet, JSP, EJB or a daemon process. The whole thrust of a
> component standard is to permit developer's to write business logic, and permit
> the deployer to select the container that offers the features that best meet the
> situation. So, any vendor-specific extensions should in my mind be limited to
> information read from deployment descriptors, and acted upon by the container.
>
> If I have an EJB client that accesses beans, and if I have to re-write the
> client just because I've moved the bean from one container to another, then I
> think that one of those container vendors has violated the EJB design goals
> (Caveat: If I decide to make use of proprietary features that require client
> code, all bets are off).
>
> Similarly, if I need to change code in a bean class because I've moved the bean
> from one container to another, then a spec violation has occurred. This one is
> probably even more important if a market in third-party EJBs is ever going to
> develop,
>
> The conclusion I derive from this argument is that if there isn't a common wire
> protocol, I can't freely move beans around from one container to another, which
> makes containers that don't support the common wire protocol useless to me,
> IMHO. It doesn't forbid extensions that other containers can ignore.
> Conversely, the extensions must be ignoreable.
>
> As far as what the wire protocol should be, I'm a lot more agnostic about that.
> As I read Jonathan Weedon's take on the matter IIOP permits the propagation of
> transaction contexts, which simple JRMP doesn't do in a standardized manner to
> my knowledge (not that is couldn't, but that there isn't an agreed-upon standard
> for doing it), which would be a good thing. Keeping transaction and identity
> state would be an important part of interoperability. Unfortunately, it looks
> like there isn't a wire protocol that can manage that.
>
> Usually the things that drive me up a wall however are what I call "partially
> complete" implementations of a standard. That is when the salesperson first
> tells you something like: "We support IIOP", and after two sales pitchy phone
> calls, and an on-site visit you discover that there's some intresting quirk,
> like no POA support. If no vendor pulled that one on me again, I would be
> content.
>
> my $0.02,
> Matt Kleiderman
> Acurion
>
> ===========================================================================
> 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".
