Dave Wolf wrote:
>
> Tony,
>
> Generally the PRO.narrow is used when casting to verify that the object
> recieved is actually able to be casted to the type needed. One of the
> rationals as I understand is that the PRO.narrow() can do typecasting of the
> object whether it is marshalled as serialized Java class or a IDL type.
>
> For instance take the following object
>
> public final class Customer implements java.io.Serializable
> {
> public String _fname;
> public String _lname;
> }
>
> Now this could be marshalled in one of two ways.
>
> 1) As a serialized Java class over an RMI type. This is likely how mosy
> containers would marshall this like BEA. Basically my guess is this is why
> PRO.narrow() is a no-op for BEA is that they always serialize so there is no
> need for type casting
>
> 2) As an IDL type marshalled over IIOP. Since the object has no methods and
> is final is can be mapped to an IDL struct type. This means when marshalled
> there is MUCH less overhead as you do not need to serialize the instance
> which is expensive.
>
> One PRO.narrow()'s job is to handle these scenarios. This is why you may
> see performance gains in those EJB containers with CORBA roots by avoiding
> alot of unnecesary Java serialization.
>
> Im not an RMI-IIOP expert but thats one reason this approach is consistant
> with the goal of portability.
>
> Dave Wolf
> Internet Applications Division
> Sybase
Dave,
As the name implies, the method:
javax.rmi.PortableRemoteObject.narrow
is a "Java extension to RMI to enable the narrowing of portable Remote
objects". In RMI, portable Remote objects are objects that implement
interfaces which extend:
java.rmi.Remote
and for which all methods throw:
java.rmi.RemoteException
Your Customer object, above, as you point out, is a data object (or a
structure), and is not a RMI Remote object. Thus, using PRO.narrow for
a collection containing these objects would be invalid. The collection
itself would already contain the right objects, an a simple cast would
suffice.
In a previous post I provided the correct rationale for PRO.narrow.
I also discussed why it's being required is (IMO) a bug in the RMI
specification. That is, it is not actually required by RMI systems
built on IIOP, or otherwise.
-jkw
===========================================================================
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".
