(This is a repost. I have sent 5 messages in this thread, but only 4 are
in the archives. If you get this twice I apologize. The list-server
seems not to be working properly nowadays..)
Rickard �berg wrote:
> > * RMI/IIOP has technical and historical problems in the sense that
> > context propagation is not fully defined yet in that particular
> > technology, or the subset specification IIOP which it relies upon.
>
> Sorry, but this is false. The OMG's GIOP specification (of which,
> IIOP is the TCP mapping) defines how contexts are propagated. The
> OMG's OTS specification defines how transaction contexts are
> propagated (using the underlying GIOP mechanism). The only real
> issue is that there is no agreement as to how the Security
> Principal is propagated, since this is a currently a Java-ism.
You're contradicting yourself. First you say that I'm wrong when I say
that context propagation is not fully defined, and then you say I'm
right because security context propagation is not yet defined. What's it
gonna be? From your description my statement is still true. I'm not an
IIOP expert though, so I might be missing something here.
> This is not a complex issue: it basically involves reserving a
> GIOP context identifier (a 32-bit number) and then specifying the
> GIOP format of the data (which might simply be a string, which
> would allow security to be interoperable with C++ and other
> languages supporting IIOP). Let's move forward and define the
> identifier and the Security Principal format, and be done with it!
> There is nothing broken in IIOP: security context propagation has
> simply not been standardized yet.
The difference between my suggestion and yours is that with mine there
is nothing to agree upon. I propagate it my way, and everyone else uses
their own way. I really don't care how others do it.
> > * RMI/IIOP makes it much harder to get into the EJB business as it is a
> > rather complex API to support in addition to EJB. Since the multi-vendor
> > argument is important for J2EE this should not be ignored. It is not
> > desirable to have only a few big vendors, since they will only cover a
> > piece of the target market. By making it possible for smaller vendors to
> > compete the J2EE market is essentially being made larger, and considered
> > as viable in more types of projects.
>
> Sun provides a free implementation of IIOP with the JDK. Vendors are
> free to use this implementation, or to build their own implementation
> and/or partner with a vendor that provides one.
Unfortunately the RMI/IIOP implementation in the JDK does not provide
enough hooks to be able to do an intelligent, or even semi-intelligent,
EJB-implementation. If it did, I could add support in EJBoss through
that. It won't improve the server, but it would make it support IIOP.
> The goal of the EJB
> specification is NOT to make building containers easy, but to provide
> the server technology customers want.
Customers usually want servers that provide the best possible
functionality. IMO this is best done by not standardizing on a
wire-protocol, as explained in previous posting.
For example, I might want to do a EJB-implementation that uses
multicasting, or one that uses SOAP as wire-protocol. There are
instances where that would be very nice, but that wouldn't be possible
if I have to use IIOP as wire-protocol.
> > * RMI/IIOP limits the containers quality of service since it is too
> > low-level.
<snip>
> Wrong again. As you say, IIOP is simply a wire-protocol. You CAN optimize
> the wire protocol (we do this), you CAN add customer logic into stubs
> (we do this for fault-tolerance and load-balancing, for example), you
> CAN implement stubs dynamically at runtime (see the DSI/DII portion of the
> CORBA specification for details).
I'm sure you can. But I can do that too, and have a more flexible
solution.
I'm not saying that IIOP is bad, I'm just saying it's not good enough.
> > * It increases the complexity for the bean and client developers, since
> > it is necessary to use the PortableRemoteObject interface narrowing API.
> <snip>
>
> Our Beta product automatically handled the narrowing for you. Our users
> complained about this feature, and asked that we not automatically narrow
> objects, so as to comply with the EJB specification.
Wow.. people actually complained that you made their life simpler?
Interesting customers you have ;-)
> Thus, it is possible
> to avoid requiring the PRO.narrow when running on IIOP. However, our
> product currently requires the narrow because the EJB specification
> currently requires it. If the spec chooses to remove the limitation, we
> could do likewise (over IIOP, no less).
Sure, that would be great. The narrow()-API is very annoying.
> > Why API-based context extraction is a good idea:
> > * Allows custom wire protocols, which in the end allows for higher
> > quality of service.
>
> Show me a feature you cannot implement over IIOP and I will show you an
> uninspired engineer. Sorry, but IIOP does not restrict functionality,
> it simply increases interoperability.
Ok, can it work over HTTP-tunneling? If I need to talk to an EJB-server
through both client- and server-side firewalls I need to be able to
tunnel all communication through HTTP. Does IIOP support that? (I really
don't know, so if possible please point me to some docs explaining this)
> > * Simple to define. JAAS already has the security context extraction
> > part covered.
>
> This might be useful in defining the contents of the security context.
> However, this context should be propagated with IIOP. See above.
You still haven't shown why IIOP is a better alternative... "should be
propagated with IIOP"... ok, but why?
> > * IIOP based servers may still be supported. If a particular vendor
> > needs to support CORBA-clients, this is no problem. IIOP is just a wire
> > protocol as anything else.
>
> Agreed.
Good :-)
> > * Reduces complexity for client- and bean-developers since
> > PortableRemoteObject is not required.
<snip>
> Yes, it is annoying overhead, and makes my code more verbose, but
> it keeps me in mind of the fact that EJB objects are not local (or
> may not be local). But I could honestly go either way, if people
> think the PRO.narrow is so complicated!
"keep me in mind that"... oh please... ;-) I think you'll notice that
anyway. It's not complicated, it's just damn annoying, and doesn't
really add anything. If I have to do something to make it work, it would
feel much better if those extra steps actually performed something
useful. narrow() does not fall into that category IMHO.
To summarize, you have not convinced me that IIOP is the way to go for
server interoperability, but I would gladly listen to your reasons, or
some explanation as to why the solution I provided is not good.
regards,
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".
