*
The moose likes EJB and other Java EE Technologies and the fly likes ServiceLocator with stateful session beans EJB 3.0 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "ServiceLocator with stateful session beans EJB 3.0" Watch "ServiceLocator with stateful session beans EJB 3.0" New topic
Author

ServiceLocator with stateful session beans EJB 3.0

Sorin Alexandru
Greenhorn

Joined: Nov 30, 2008
Posts: 28
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
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Sorin,

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

Best regards,
Reza


Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Sorin Alexandru
Greenhorn

Joined: Nov 30, 2008
Posts: 28
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
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
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
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
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
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
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

Joined: Apr 16, 2008
Posts: 2187
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

Joined: Nov 30, 2008
Posts: 28
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

Joined: Apr 16, 2008
Posts: 2187
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

Joined: Nov 30, 2008
Posts: 28
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

Joined: Apr 16, 2008
Posts: 2187
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

Joined: Nov 30, 2008
Posts: 28
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
 
wood burning stoves
 
subject: ServiceLocator with stateful session beans EJB 3.0
 
Similar Threads
Providing sessionbeans through init()
JNDI lookup in EJBHomeFactory pattern
caching the jndi call
Datasource lookup
singleton