On 12 Jun 00, at 19:57, Rickard �berg wrote:
> > Assuming that we intend to be spec-compliant, there are
> > implications of this for transactions, the naming service, security,
> > and of course we need to actually provide an IIOP proxy.
>
> No we don't. IIOP support is "recommended" for interop, and the spec
> states quite clearly that "well, it would be nice if you supported tx's
> as well, but it isn't required".
Hi Rickard,
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.
> 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 .
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, and
tools to allow the deployer to link an ejb-ref-name to an EJBHome
object's CosNaming name.
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.
-Dan
