Differentiating how parameters are handled

[Mark Garland]

Hi,

I'm reading Mastering EJB Chapter 3, 4th ed. p66.

From what I understand, for remote clients, parameters are passed by value. This means that they are serialized, and the bean is uninterested in what the client does with the value, as the client is operating on a copy.

Now, EJB's also support a local view for performance. These parameters are passed by reference. This means that "if the bean does not want the client to modify the returned value, it needs to explicitly copy the return data into another variable and pass that to the client.". That makes sense.

"EJB does support both local and remote client views.... the bean developer is just required to define POJI (plain old java interface) business interfaces for lo0cal and remote clients of the bean". That's fine.

"Alternatively, the same business interface can be used to serve both local and remote clients". But hang on... When writing a method used by both interfaces, how do I know whether parameters are coming at me in a value or reference form? Is the rule 'code for value if you don't want them changed, reference otherwise'.

I hope this question makes sense. Perhaps this is answered later in the book, but hey, I'm impatient. :-)

[Benoît de Chateauvieux]

Hi Mark,

I don't how to read your sentence

Alternatively, the same business interface can be used to serve both local and remote clients

because the specs 4.6.6 says:

The same business interface cannot be both a local and a remote business interface of the bean.

Any idea ?

Beno�t

[Mark Garland]

Hi,

Thanks for your reply.

I can't really answer your question, except to give a copy of what was said in the book. I don't think I'm in breach of any regulations here, as the book is freely available and I'm quoting the source.

EJB and Location Transparency
Distributed computing systems that offer location transparency essentially
offer an ability for the clients to communicate with the remote object without them having to be aware of the remote object�s machine location. The servicing object can be located on the same machine or on a different machine; the client doesn�t have to care. The location transparency is usually attained via an intermediary, such as a registry, wherein the distributed objects are registered along with information such as their exact machine location. All the client has to do is search this registry for the requisite remote object, and it is the registry that
hands over the remote object to the client.
In the EJB world, location transparency translates to the ability of the client to communicate with the EJB that is deployed in a JVM other than the client�s JVM. The clients of the EJB that support remoting are not required to be located within the same JVM; they can be in the same JVM, but they don�t have to be. JNDI is an enabler of location transparency in the EJB framework. A remote client of a bean can be located on any system�as long as it can communicate with the JNDI service of the EJB container, it can get to the bean. EJBs also support local client view. This functionality was added in the 2.0 version of EJB technology so that the clients co-located in the same JVM as the bean can bypass the performance inefficiencies of pass-by-value semantics inherent to the distributed programming models. For such invocations on the bean�s local client view, the container passes method parameters by reference. Similarly, the container passes method return values by reference from bean to the client. Pass-by-reference basically leads to sharing of the state between caller and the called. Hence, if the bean does not want the client to modify the returned value, it needs to explicitly copy the return data into another variable and pass that to the client. Local clients of EJB do not benefit from location transparency as such, since they have to be, by definition, co-located in the same JVM as the bean.
EJB 3.0 does support both local and remote client views, as it did in the previous versions, except that the bean developer is no longer required to provide definitions of EJBObject interfaces for local and remote client views. Instead, the bean developer is just required to define POJI (plain old Java interface) business interfaces for local and remote clients of the bean. Alternatively, the same business interface can be used to serve both local and remote clients.

[Mark Garland]

No takers?
This forum seems a little dead compared with the SCWCD one?