• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

PetStore: Service Locator Pattern design question

 
Renaud FLORQUIN
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Based on several recommendations for the part 2 of the certification, I'm currently studying the PetStore 1.4 design to understand the Sun approach of a J2EE architecture and I have some questions.

There are two implementations of the ServiceLocator pattern (whith the same services), one using a cache (com.sun.j2ee.blueprints.servicelocator.web.ServiceLocator) and the other one without a cache (com.sun.j2ee.blueprints.servicelocator.ejb.ServiceLocator).
Most of the PetStore components use the second version.
Although the book "Core J2EE Patterns" explained that "it is not uncommon to see tho Service Locator implementations in a application, one for the presentation tier and one for the business tier", I don't understand why there is two different implementations ? Why there is no cache for the business tier?

Thanks in advance for your advises
Renaud
 
Tomi Tuomainen
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Service Locator may be used for caching when creation of service components is complex. I haven't studied PetStore code but I guess the complex components are in business tier and that's why cache is needed. If web tier just connects to a session facade then a cache won't help us much.

I think it's more flexible and clearer solution to have different Service Locators for different tiers. We could for example run presention tier and business tier components in different servers (frontend and backend).
 
Renaud FLORQUIN
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your answer.
I agree with your logic but the PetStore uses the cache version of the ServiceLocator for the web tier and most of the components (inside the business tier) use the version without cache.
The cache implementation uses a synchronized map and thread synchronization is a restriction of a EJB component; so I think it is the reason of the two implementation.
Is the synchronization always required? I don't think but a book like 'Core J2EE Patterns' should discuss this type of issues instead to show how to use Service Locator for EJBHome, DataSource, JMS Topic, ... (very similar) but I didn't find :-(

Renaud
 
Tomi Tuomainen
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Renaud,

I agree that guidelines to implementation details are hard to find. One of the EJB restrictions also is that we cannot use nonfinal static fields. Is this just for the bean classes? Can we still use static (synchronized) cache for all the bean instances if it's in a class "outside" the bean (in a different jar)? Or is a stateful (one per client) EJB the only way to build a cache?

As architects we shouldn't usually care about technical details, but of course we cannot model things that are against the EJB standard. Any gurus around?

Tomi
 
Ramon Gill
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The PetStore sample application uses a distributed architecture (p375 of bluprints, chapt 11). This may be the reason why caching is not used for the ServiceLocator on the EJB tier. It may not give much benefit to do so when only local calls are made.

Ray
 
Tomi Tuomainen
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's true, EJB local calls should be as fast as direct object method calls. I'm still wondering if I can use Value List Handler in EJB tier to cache search results for better performance... or is this one of the restricted things.

Tomi
 
Renaud FLORQUIN
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the EJB restrictions also is that we cannot use nonfinal static fields. Is this just for the bean classes? Can we still use static (synchronized) cache for all the bean instances if it's in a class "outside" the bean (in a different jar)? Or is a stateful (one per client) EJB the only way to build a cache?

I'm not an EJB specialist but for me a bean should not call a class with synchronized code (raison: the concurrency is controlled by the container). A stateful bean can build a cache but only for its own client (concurrent call is not allowed for a Stateful Session Bean).
Renaud
 
Frank Silbermann
Ranch Hand
Posts: 1408
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Renaud FLORQUIN:

I'm not an EJB specialist but for me a bean should not call a class with synchronized code (raison: the concurrency is controlled by the container). A stateful bean can build a cache but only for its own client (concurrent call is not allowed for a Stateful Session Bean).
Renaud


I'm sure that a DBMS implemented in Java uses synchronization, yet is called by an EJB. But perhaps it's a bad example, in that a DBMS runs in a different process, and must observe certain resource-provider J2EE contracts that ordinary developers don't worry about.

What does disturb me is that there is so much repetition of code in the two service locators. That's an Extreme Programming no-no. I suspect that one could implemented such that users of a "getSingletonServiceLocator" routine would use caching, but those using a simple "new ServiceLocator" would not. But the code would then be more confusing; even if you were only interested in one tier, you would still have to understand the needs of the other tier to appreciate the ServiceLocator code. Furthermore, you'd have to package it differently so it could be deployed to both tiers.

Can anyone think of an elegant way to eliminate the code redundancy? Maybe some kind of decorator to the ServiceLocator that adds caching! But the code for the decorator might be just a big as a second ServiceLocator (and harder to read).

Part of me says that whenever there is redundancy in a program and no good way to remove it, that's a sign that a new language construct is needed!
 
vu lee
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I still confuse why there were two different versions of service locator -- one for web and the other for ejb. As Frank pointed out, much of the code has been duplicated. IMO,the only difference is that the web version uses singleton and a Map to cache. Some suggested that each of these locators would be deployed on different node, and others suggested that the EJB version did not need to cache because of local EJBs. I think cache would be needed even for the ejb version since , besides creating new objets, lookup is still costly and time consumption.

Would it be... for ejb client, business delegate and service locator will be in the client jar; therefore, singleton and caching are irrelevant. but...what prevents me from accepting this answer is that petstore ejb locator also contains code to MDB related and datasource. Would someone shed some light on this?
 
vu lee
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any comment?
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The big difference between the Service Locator is not the singleton or caching, actually is based on how the Service Locator to get InitialContext. In PetStore, We see both of them use local way(ie. just new InitialContext()), but I don't think this is a typical enterprise solution. In real world, the web Service Locator most time will be at remote, and it is vendor dependent.
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's hard to understand why the ejb Service Locator has no cache. I think at least the Remote one we need a cache. any comments?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic