• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Location transparency in EJB?

 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Raghu.
 
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Jaikiran Pai
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic