sumesh wrote:
>
> hi jkw,
> I accept what u said.I mentioned COBOL only as an example...
> What i intended to say was that since ejb 1.1 requires the use of RMI-IIOP reference
> and argument types,
> and IIOP being part of the CORBA standard, it is not advisable to use casting because
> CORBA doesn't
> support casting at all(as far as i know).I hope this is clear
Even when using RMI-IIOP, the JNDI provider (vendor-specific implementation
of javax.naming.Context) can do the narrow implicitly.
> regards,
> sumesh
>
> "Jonathan K. Weedon" wrote:
>
> > Sumesh,
> >
> > I am not sure if you were disagreeing with me or not. But if you
> > were, then I might point out that COBOL is not relevant for RMI-
> > over-IIOP. I fully agree (and previously stated) that there are
> > needs for the narrow operation in CORBA, but in the case of RMI-
> > over-IIOP (which is, by definition, a Java only case) the narrow
> > should not be required. The fact that the current EJB spec requires
> > it is an oversight.
> >
> > -jkw (the original developer of VisiBroker for Java)
> >
> > sumesh wrote:
> > >
> > > the javax.naming.Context.lookup() will return an Object.
> > > In ejb1.0 it ws enough to cast it as teh protocol used was RMI .
> > > but in ejb1.1 it is required that it be compatible with RMI-IIOP..
> > > Since CORBA is programming language independent it is not possible to use
> > > casting. Because of the fact that some languages doesn't have the concept of
> > > polymorphism or inheritance(like COBOL) implicit casting is not at all aceptable
> > >
> > > "Jonathan K. Weedon" wrote:
> > >
> > > > Tibo,
> > > >
> > > > Although your answer is 100% correct, I thought it would be useful
> > > > to reiterate Evan's comment:
> > > >
> > > > > Actually nothing prevents a vendor from supporting a simple cast even when
> > > > > using IIOP (I know that because we implemented it in Sybase EAServer and it
> > > > > was easy).
> > > >
> > > > <vendor>
> > > > I second the fact that this is possible. In fact, an early version
> > > > of Borland AppServer also did the "automagic" casting, over IIOP. But
> > > > our users complained about non-compliance with the spec, and asked
> > > > that we require the narrow by default, thereby forcing users to write
> > > > portable code.
> > > > </vendor>
> > > >
> > > > So, strictly speaking, the narrow is not required for the EJB use
> > > > case of RMI-over-IIOP (although there are some very obscure pure-CORBA
> > > > use cases that do require the narrow).
> > > >
> > > > As such, I would love to see a future version of the EJB spec lift
> > > > this rather bothersome requirement, although until that happens we
> > > > will require users to write portable EJB code.
> > > >
> > > > -jkw
> > > >
> > > > Thibault Cuvillier wrote:
> > > > > narrow is a CORBAism, which cannot be hidden by the RMI API.
> > > > > To understand the narrow method, you need to understand how CORBA proxies
> > > > > are managed.
> > > > >
> > > > > CORBA proxies
> > > > > -------------
> > > > >
> > > > > Example:
> > > > > The remote interface B extends the remote interface A
> > > > > The remote object implementing the interface B (and so, A)
> > > > >
> > > > > When you get a remote reference from the naming service, CORBA will create a
> > > > > Corbae object stub, which is the super class of all the CORBA proxies. If
> > > > > you try to cast it down to a proxy to B, you will get a ClassCastException.
> > > > >
> > > > > With CORBA, the proxy may not implemented all the remote interfaces of the
> > > > > remote object.
> > > > >
> > > > > So, you have to call the narrow method to create a proxy implementing the
> > > > > right interface.
> > > > >
> > > > > The narrow method do the following job:
> > > > > 1- Test if the proxy implements the requested interface
> > > > > If yes, the proxy is only casted-down and returned as-is.
> > > > > 2- If No, the method test if the remote object implements the
> > > > > requested interface
> > > > > Call the CORBA method is_a which check if the cast is
> > > > > correct on the server side (IIOP request)
> > > > > If not, an exception is send (Corba BAD_PARAM exception)
> > > > > 3- Create a new proxy
> > > > > The narrow method return a new proxy.
> > > > >
> > > > > Here is an example of the narrow method generated by Javaidl:
> > > > > public static A narrow (org.omg.CORBA.Object obj)
> > > > > {
> > > > > if (obj == null)
> > > > > return null;
> > > > > else if (obj instanceof A)
> > > > > return (A)obj;
> > > > > else if (!obj._is_a (id ()))
> > > > > throw new org.omg.CORBA.BAD_PARAM ();
> > > > > else
> > > > > {
> > > > > org.omg.CORBA.portable.Delegate delegate =
> > > > > ((org.omg.CORBA.portable.ObjectImpl)obj)._get_delegate ();
> > > > > return new AStub (delegate);
> > > > > }
> > > > > }
> > > > > Remark:
> > > > > - the Delegate object contains ORB specific code.
> > > > > - The AStub do not implements the B interface.
> > > > >
> > > > > 2-- RMI over JRMP
> > > > > Much simpler. When you lookup an object with RMI, RMI will create a proxy
> > > > > consistant with the remote object interfaces.
> > > > > So you don't need narrow at all.
> > > > >
> > > > > 3-- So,
> > > > > With EJB, look at the following code:
> > > > > Object object = context.lookup("ejb.A");
> > > > > A a = (A)PortableRemoteObject.narrow(object, A.class);
> > > > >
> > > > > With CORBA, the proxy a implements the interface A, but not B !
> > > > > With RMI, the proxy a implements A and B, because the remote object
> > > > > support these interfaces.
> > > > >
> > > > > So if you cast down the proxy like that:
> > > > > B b = (A)a;
> > > > > With CORBA you will get an exception.
> > > > > With RMI it will works.
> > > > >
> > > > > To make your code portable, you need to write:
> > > > > B b = (B)PortableRemoteObject.narrow(a, B.class);
> > > > > With CORBA, narrow will create a new proxy, but the proxies a and b
> > > > > will contains a reference to the same remote object.
> > > > >
> > > > > Hope this help
> > > > > Tibo.
> > > > > http://www.valtech.com
> > > >
> > > > ===========================================================================
> > > > 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".
> >
> > ===========================================================================
> > 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".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
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".
