Hi!
Dan OConnor wrote:
> My comment should have read, "assuming that we intend to be 2.0
> spec compliant." In the draft 2.0 spec, IIOP is mandatory:
>
> <ejb 2.0 18.2>The interoperability protocols described here must
> be supported by compatible EJB products. Additional vendor-
> specific protocols may also be supported.</ejb 2.0 18.2>
>
> > As for interop:
> > Any bean in any server from any vendor will be able to call a bean in
> > jBoss. It would be just yet another client. For security interop I would
> > suggest using the RMI security being introduced in JDK 1.4,
>
> I have looked very briefly at the issues in providing a security
> implementation for jBoss (one of the e-mails your isp ate). I'm no
> expert on the topic, which is why I'm interested in it. :-) Anyway,
> could you point me to some reference on RMI security in JDK 1.4?
> I hunted around for it on Sun's web site to no avail.
Look through the J1 RMI Security session slides (from java.sun.com).
> > and for tx interop I would suggest using bean logic
> > (try/dostuff/catch->exception=setRollbackOnly). Not perfect, but
> > working.
> >
>
> This I don't really understand. The 2.0 version of the spec doesn't
> actually require a container to support the propogation of
> transactions, but... you can't really emulate it using bean logic.
> Once dostuff completes successfully, there is no way to roll it
> back, regardless of the success or failure of the method. That's
> why the 2.0 spec requires that in a scenario without
> interoperability, a business method with Supports, Required, or
> Mandatory transactional attributes must throw a RemoteException
> before even attempting to complete, if the IIOP transaction context
> is null or valid .
You are quite correct.
> Also, at the very least we need to provide some "CORBAesque"
> features in our role as a "client container," for when EJBs in jBoss
> make calls to EJBs in another application server. For instance, we
> would need to provide a JNDI CosNaming service provider,
Wouldn't this be provided by the other server?
> and
> tools to allow the deployer to link an ejb-ref-name to an EJBHome
> object's CosNaming name.
This is already in. The EJX plugin allows you to select an arbitrary
JNDI name as the link.
> My concern is that--for political reasons or whatever, it doesn't
> matter--this CORBA stuff is going to be important. If we build
> major components, such as a transaction manager or our security
> services, without taking into account things like transaction
> propogation between application servers, we might be hurting
> ourselves.
>
> Even if we are unhappy at Sun's path regarding interoperability--
> quite possibly based on politics rather than technology--how we
> respond might have serious ramifications as to our success or
> failure as a J2EE platform...
>
> ...and, of course, it might not. You seem to feel that we can ignore
> the literal spec requirements to achieve the same effects in a better
> way. This strikes me as a riskier proposition than your original
> idea on ejb-interest, which was that compliance should require
> implementation of a set of APIs that a downloaded stub could use
> for interoperable transactions, security, etc. But you might be right.
It is riskier, but it doesn't seem like the vendors want to do the right
thing (use an API-based approach). I can't understand why (and noone
seems to want to tell me), but that's the way it is.
I do not want to use RMI/IIOP as the default protocol. It just plain
sucks.
And speaking as a Telkel-employee, Telkel has no use of RMI/IIOP
integration. However, there seem to be others on this list who want
RMI/IIOP support, and I have nothing against them doing a distribution
protocol plugin for RMI/IIOP. That's why we have the plugin-based
architecture: to allow for different peoples different needs.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
