ServiceLocator pattern
Hello !
I have the need of the ServiceLocator pattern: I am currently using JMS intensively in my application through a session EJB that creates the topic factory (and so on) if not yet created as a class member. for instance I have a getTopic method that creates the topic if the class member is null, otherwise returns the class member (kind of lite singleton).
since a lot of EJBs (internally in the app srv) use this publisher/subscriber session bean the JMS elements are often re-created (the connection, topic and so on) everytime the pub/sub bean has been passivated and is re-activated.
the ServiceLocator pattern looks cool, yet I have few wonders:
- is this ServiceLocator pattern usable for a client (service client) inside the app srv ? this is not clear in the pattern doc, also in petstore sample where static singleton is only used for a remote web client.
I have this wonder coz I can't see how my client beans are gonna deal with the fact that they will each have a copy of the singleton (one per classloader, one per bean).
- also since in the pattern, the static methods are not synchronized, what is going to happen when 2 beans access the ServiceLocator at the same time ?
- won't it affect clustering work to use such a pattern ?
Thank you for any clarification or advice on how to perform the ServiceLocator goal inside an app srv (local clients of the service)
[1441 byte] By [
sblanc4a] at [2007-9-28 7:45:52]
> since a lot of EJBs (internally in the app srv) use
> this publisher/subscriber session bean the JMS
> elements are often re-created (the connection, topic
> and so on) everytime the pub/sub bean has been
> passivated and is re-activated.
>
Personally, I don't cache the JMS objects in the app server components. Even in a moderately chatty application, the overhead to create a connection and publish a message isn't that great--less than 20 ms.
If you do this, you don't need to worry about passivation/activation of the JMS components (QueueConnection, etc).
> the ServiceLocator pattern looks cool, yet I have few
> wonders:
>
> - is this ServiceLocator pattern usable for a client
> (service client) inside the app srv ? this is not
> clear in the pattern doc, also in petstore sample
> where static singleton is only used for a remote web
> client.
Sure.
> I have this wonder coz I can't see how my client beans
> are gonna deal with the fact that they will each have
> a copy of the singleton (one per classloader, one per
> bean).
>
Hmmm, if in fact the classloader for each bean loads this, it will still be a singleton that is shared by all instances of that bean, just not across all beans in the container. This still is an improvement over not using a singleton.
> - also since in the pattern, the static methods are
> not synchronized, what is going to happen when 2 beans
> access the ServiceLocator at the same time ?
>
Unless the SL has state that invoking the methods changes, synchronization isn't a problem.
> - won't it affect clustering work to use such a
> pattern ?
How so?
thanx for answers.
about clustering issue, for instance if I want to have 2 standby servers in my cluster, it looks to me that
anything that is cached out of container policy in the server 1 will have to be cached with the same state in the second server too.
I'm just beginning with clustering and it seems to me like I then need to find a way to transfer all the caching state from server 1 to server 2 (jms for instance) which looks pretty messy.
seb.
You do not need to replicate cached open connections and factories. You just recreate them if none are set.
But I also recommend not to use any pattern, especially not static caches, unless you have the need for it. It might make your application less portable, less stable and very complicated to debug. And for some stuff there is realy no need for it.
eckia at 2007-7-9 18:59:18 >
Hi,
The servicelocator is useful for clients of both remote and local EJBs.
For web tier clients using a "singleton" per class loader is a common strategy. Note that the Map caching/holding the resource references is synchronized. Also not that it caches Factory objects and not references to EJB instances etc. So the objects being cached are NOT client specific but are at application scope and can be used by any client. Connections in J2EE should be pooled so you should be able to open and close them with much performance penalty so you dont need to hang on to them. The code for a web tier servicelocator is at
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java.html
In terms of clustering, there should not be any issues since the locator caches resources that are not client session state and if you have different instances of the locator in your cluster, it does not make a difference. They dont need to be in sync so multiple versions is ok.
For clients that are EJBs, it may not make sense to make a static "singleton" of the servicelocator and instead just use the servicelocator to hold all the look up code and make the code more manageable. Your EJBs can manage the resources themselves as part of their lifecycle and can use the servicelocator to create objects and the EJB can hold those references. The code for an example is at
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/ejb/ServiceLocator.java.html
and an example of its use by an EJB is at
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/opc/ejb/PurchaseOrderMDB.java.html
The pattern and example are discussed at
http://java.sun.com/blueprints/patterns/ServiceLocator.html
hope that helps,
Sean
