aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Location transparency in EJB? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Location transparency in EJB?" Watch "Location transparency in EJB?" New topic
Author

Location transparency in EJB?

Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10266
    
168

I have been working on EJB2.x for quite sometime now, and i have always thought of asking this question. Since we have Raghu Kodali and Jonathan Wetherbee at Javaranch, this week, i thought it is the best time to ask this question.
EJB specs(even the new EJB3 spec) keep mentioning about location transparency. Here's one of the extracts from the EJB3 spec:

The remote client view of an enterprise bean is location independent.


It goes on to say that the client APIs will be the same irrespective of where the bean instance is running. Is this completely true? Doesn't the client have to specify as part of the InitialContext properties(either through code or through the properties file) as to where to look for the bean while doing a lookup? I have done this before when i had to lookup a remote bean - i had to pass the appropriate machine name and port while doing the JNDI lookup.

So where does this leave the concept of location transparency? The client has to pass the appropriate values while doing a lookup which makes it aware about the location of the bean instance. Am i wrong? Or have i got the notion of location transparency completely wrong?


[My Blog] [JavaRanch Journal]
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17259
    
    6

Yes, there is still a need for a "hint" so that you aren't looking everywhere to find your bean in a haystack. But with jndi.properties file, your code doesn't need to know exactly what is in there, you you can change that file without changing your client codebase.

Also, if you have a cluster and your jndi.properties just points to a multicast IP address, then there is definitely transparency because your client will have no clue which node in the cluster is serving your requests. Your client proxy will, but that is another story.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Jon Wetherbee
author
Ranch Hand

Joined: Oct 05, 2006
Posts: 33
Hi Jaikiran-
You're right that the remote client does need to know how to look up the remote session bean, both when it specifies the JNDI name and when it specifies the remote server connection information (this is typically captured in a jndi.properties file).

However, the quote you cite addresses a different point regarding location transparency: The session bean's api is constant regardless of the client's location. Here's the quote in context (from section 3.1 of the EJB 3 Core Contracts document):

The interface used by a remote client of a session bean is implemented by the container as a remote business interface (or a remote EJBObject interface), and the remote client view of a session bean is location-independent. A client running in the same JVM as the session object uses the same API as a client running in a different JVM on the same or different machine.


Regards,
Jon
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10266
    
168

Originally posted by Mark Spritzler:
Yes, there is still a need for a "hint" so that you aren't looking everywhere to find your bean in a haystack. But with jndi.properties file, your code doesn't need to know exactly what is in there, you you can change that file without changing your client codebase.


Originally posted by Jon Wetherbee:
You're right that the remote client does need to know how to look up the remote session bean, both when it specifies the JNDI name and when it specifies the remote server connection information (this is typically captured in a jndi.properties file).


Thanks Mark and Jon.

Originally posted by Jon Wetherbee:
However, the quote you cite addresses a different point regarding location transparency: The session bean's api is constant regardless of the client's location. Here's the quote in context (from section 3.1 of the EJB 3 Core Contracts document)


The quote that i cited was from section 3.2.1 of the EJB 3 Core document:

The remote client view of an enterprise bean is location independent.A client running in the same JVM as a bean instance uses the same API to access the bean as a client running in a different JVM on the same or different machine.


All the same, i now understand that location transparency was meant to be related to session bean's APIs rather than the API(s) used to get hold of the session bean.

Thanks again guys
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10266
    
168

Talking about bean lookups, EJB3 supports dependency injection of bean's interface. Does it also support injection of remote interfaces(by remote, i mean a bean which is running on a separate app server instance).If no, is the traditional JNDI lookup the only option in EJB3 as well? Just curious.
Raghu Kodali
author
Greenhorn

Joined: Oct 05, 2006
Posts: 18
Yes, you can use dependency injection in the client application that is using the application client container to get to bean(s) that is/are running in remote container, and invoke the business methods.

-raghu
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10266
    
168

Thank you Raghu.
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3325
    
    8
The client does not really specify the location of the bean. It only needs to "know" the location of the JNDI server. The bean may be anywhere and as long as it is registered with the JNDI server, a client can find it.
This, imho, is what is meant by location transparency. A client need not "know" where the bean is.


Enthuware - Best Mock Exams and Questions for Oracle/Sun Java Certifications
Quality Guaranteed - Pass or Full Refund!
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10266
    
168

It only needs to "know" the location of the JNDI server

Theoretically, yes. But, so far in whichever app server that i have used, i have seen that when a bean is deployed on the app server, the app server will bind it to the JNDI server present within it. Practically, is it possible with any of the application servers that are in the market, to deploy a bean on one server and register it to a JNDI server on some other server?

P.S.: I am not saying that you are wrong, but with whatever little experience that i have, i havent practically seen this either in any sample examples or any production applications.
[ October 25, 2006: Message edited by: Jaikiran Pai ]
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10266
    
168

To be more clear, what i mean is i havent come across something like plugging in a external JNDI server into an application server and bind the beans deployed on the application server into this JNDI server
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3325
    
    8
Originally posted by Jaikiran Pai:
To be more clear, what i mean is i havent come across something like plugging in a external JNDI server into an application server and bind the beans deployed on the application server into this JNDI server


That's the shortcoming of the EJB server implementation. The EJB spec is quite clear on location transparency. AFAIK, you can use a separate JNDI server to register and lookup beans with WebLogic as well as WebSphere. How else will multiple projects use each other's beans? Please check their documentation.

TO answer your original questions, "So where does this leave the concept of location transparency? The client has to pass the appropriate values while doing a lookup which makes it aware about the location of the bean instance. Am i wrong? Or have i got the notion of location transparency completely wrong?"

The client does not have to pass the location of the Bean. Nor does it have to be aware of the location of the bean. Knowing the location of the JNDI server is not same as knowing the location of the bean.

BTW, this concept of location transparency has been in existance since CORBA days. There, you use a common Naming Server and any CORBA object can publish its existance.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10266
    
168

Knowing the location of the JNDI server is not same as knowing the location of the bean.


I agree.

The EJB spec is quite clear on location transparency. AFAIK, you can use a separate JNDI server to register and lookup beans with WebLogic as well as WebSphere. How else will multiple projects use each other's beans? Please check their documentation.


Sure i will do that, atleast for Websphere.

Paul Anil, thanks for answering in detail.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Location transparency in EJB?