• 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

ServiceLocator with stateful session beans EJB 3.0

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear all,

According to the Core J2EE Patterns, ServiceLocator is supposed to cache EJBHome objects.
Now suppose I work with stateful session beans in EJB 3.0. I don't have home objects any more, so I'd cache the object returned by context.lookup() (see code below). But that means that several users would have access to the same stateful bean (the cached one), which is not what we want.
How to solve this issue in the context of EJB 3.0 ?


public class ServiceLocator {
/**
* Singleton Instance of this class
*/
private static ServiceLocator serviceLocator = null;

/**
* InitialContext object
*/
InitialContext context = null;

/**
* Cache where the objects can be stored for later
* retrieval.
* This enhances the performance.
*/
HashMap serviceCache = null;

/**
* Constructor to initialize the class
*
* @exception NamingException In case an exception is
* generated
*/
public ServiceLocator() throws NamingException {
// Start the initial context
context = new InitialContext();
// Initialize the HashMap to store 5 objects
serviceCache = new HashMap(5);
}

/**
* Returns the singleton instance
*
* @exception NamingException In case an exception is
* generated
* @return Singleton Instance
*/
public synchronized static ServiceLocator getInstance() throws NamingException {
if (serviceLocator == null) {
// If the object is not created, then create it
serviceLocator = new ServiceLocator();
}

// Return the singleton instance
return serviceLocator;
}

/**
* This is the method that returns the service
*
* @param jndiName JNDI Lookup needed for invoking the
* service
* @exception NamingException In case an exception is
* generated
* @return Service Object
*/
public Object getService(String jndiName) throws NamingException {
if (!serviceCache.containsKey(jndiName)) {
// If the object is not saved in the cache, then do a
//lookup and save it
serviceCache.put(jndiName, context.lookup(jndiName));
}
// Return the required object
return serviceCache.get(jndiName);
}

}

Thank you,
Sorin
 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorin,

The short answer is that service locators are not needed in EJB 3.0.

Best regards,
Reza
 
Sorin Alexandru
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok Reza, but suppose I don't use the ServiceLocator, at a certain point I'll
have something like:

MyTestBean b1 = context.lookup("myTest");

and later, in another piece of code:

MyTestBean b2 = context.lookup("myTest");

Now the problem is this will create another bean identity and in the case of stateful beans, this is not what I want. Obviously, I'd like to talk to the same bean, so I'd like to cache b1. But then I arrive to the original problem.

So, if the ServiceLocator pattern is not needed in EJB 3.0, how do I solve this new issue of preserving bean identity ?

Thanks,
Sorin
 
Reza Rahman
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorin,

In a web-application, this is solved by putting the stateful session bean reference in the HTTP session. JBoss Seam makes this even easier via managing the HTTP session state via DI.

If you are not in the web tier (e.g. a standalone application), it is typically just a matter of storing the stateful bean inside a variable with appropriate scope. You can even use a Map/HashTable where needed.

Regards,
Reza
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You may still use the Service Locator design pattern. Putting EJB references in the Presentation tier (HttpSession) is a "questionable" design, in my opinion.

A Service Locator serves as a delegate to the service implementation and encapsulates lookup code (shields it from the client API).
[ December 01, 2008: Message edited by: James Clark ]
 
Reza Rahman
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James,

I most certainly won't push my opinion on anyone about this. However, do keep in mind that a tighter binding of the presentation, service and persistence tiers are almost the central aspects of technologies like Seam, Spring MVC/WebFlow and Ruby on Rails. That being said, there are always good reasons to have a solid line between tiers.

Best regards,
Reza
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Reza - it is helpful to point out other technologies that promote a "tighter" coupling between components. And as we can see, some of them conflict with some well-known enterprise design patterns.

It boils down to a set of design decisions, which should be based on analysis of an application or service's "known" technical and quality-of-service requirements.


The Importance of Model-View Separation
[ December 01, 2008: Message edited by: James Clark ]
 
Sorin Alexandru
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James, you can't use the ServiceLocator pattern 'as is'. Namely, the ServiceLocator can't be a singleton accessible to all users, because then they would be able to use the same stateful bean.
Of course, there are workarounds to this, but I thought you might know about the 'right pattern' for such a case.

Thank you,
Sorin
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An object-oriented design pattern does not specify exactly how it can be implemented. It also does not specify exactly one one way to implement it. A design pattern is only a guide. So, in regards to using the Service Locator pattern, your definition of "as is" does not make much sense.

A Service Locator implementation does not have to be a singleton. Moreover, as specified in the pattern's documentation, you will most likely have multiple instances of the Service Locator in a distributed application. Each client object can have a reference to it's own Service Locator.

The benefits of the Service Locator design pattern are very significant and valuable. Coding "lookup" statements directly in client classes is a poor design decision, in my opinion. The Service Locator is the "right pattern" that can be used effectively in any design that merits its usage. The "right person" needs to be able to understand this, however.
[ December 02, 2008: Message edited by: James Clark ]
 
Sorin Alexandru
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,
I agree with you when you say:
"An object-oriented design pattern does not specify exactly how it can be implemented"
However, when I said "as is", I was referring to the ServiceLocator as described in the "official" Core J2EE Patterns:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html
You notice immediately that the service locator is presented a singleton and it is only usable in the context of EJB before 3.0.
So, in my original post I asked if you knew about this pattern in the context of EJB 3.0.

Like I said, I can always find workarounds or use the pattern the "right way" for EJB 3.0 or for the general case.
And sure, the "right person" needs to understand it, but also the "right person" should be able to explain it to others ....

Greetings,
Sorin
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorin, do you have a copy of the "official" Core J2EE Patterns book? There is more information in the printed book than there is on the online web page.

If you have the book, read the second paragraph on page 316 under the Solutions heading.

Either way, the examples described in the UML diagrams are only examples of how the pattern could be implemented. They are only examples. Other examples with design variations are certainly possible. The other example of this pattern is described in the paragraph mentioned above.

Another implementation of the Service Locator design pattern is found in Apache Axis. Here the Service Locator is used to get web service stub implementations and other related data. Note, there are no EJBs in this implementation.
[ December 03, 2008: Message edited by: James Clark ]
 
Sorin Alexandru
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you James, I'll find the book and read that paragraph.
Anyway, I think the patterns should be technology agnostic, like you also suggest. I hoped I could easily find such a ServiceLocator pattern, but any time I look for one online, I bump into a technology-dependent implementation.

Greetings,
Sorin
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic