Service Locator

author-image
CIOL Bureau
Updated On
New Update

Avijeet Dash and Satyabrata Dash

The commonly used JNDI-administered services are lookup for JDBC connection
pool, EJB Home and Remote object, JMS Queue/Topic connection factory,
Queue/Topic session, Queue/Topic etc. The lookup for same service objects often
appears in multiple clients.

Advertisment

For example, all stateless session bean client applications, that use the
CabinEJB session bean also use code snippet, like the following is written to
find the home and remote reference object CabinEJBHome and CabinEJB
respectively.

{

Context context=new InitialContext();

CabinEJBHome home=context.lookup("CabinEJBHomeJNDI");

CabinEJB remote=home.create();

}

The drawbacks with the approach just explained are,

  1. If multiple clients are accessing the same session bean, then expensive
    operation of look up is done multiple times.
  2. Code is duplicated at various places.
  3. The lookup operation is not cached.
  4. The context factory for initial JNDI context creation is provided by the
    service provider vendor and is therefore vendor-dependent. For example the
    initial context factory name used in weblogic is "weblogic.jndi.WLInitialContextFactory".
    So the application can not easily be ported to a different J2EE vendor.

So, to avoid the above problems, Service Locator pattern abstracts the
operation of lookup and caching of JNDI-administered service objects.

For example, the following steps of using JMS administered can be delegated
to Service Locator.

  1. Setup the JNDI environment.
  2. Get an initial context for the JMS service provider from the JNDI naming
    service.
  3. Use the initial context to locate the Queue/Topic connection factory.
  4. Use Queue/Topic connection factory to get Queue/Topic connection.
  5. Use Queue/Topic connection to get Queue/Topic session.
  6. Use Queue/Topic session to get Topic Publisher or Topic Subscriber or
    Queue Sender and Queue Receiver respectively.

Structure


Client

This is the client of the Service Locator. The client is an object that
typically requires access to business objects such as a Business
Delegate
.

Advertisment

Service Locator

The Service Locator abstracts the API lookup (naming) services, vendor
dependencies, lookup complexities, and business object creation and provides a
simple interface to clients. This reduces the client’s complexity. In
addition, the same client or other clients can reuse the Service Locator.

InitialContext

The InitialContext object is the start point in the lookup and creation
process. Service providers provide the context object, which varies depending on
the type of business object provided by the Service Locator’s lookup and
creation service. A Service Locator that provides services for multiple types of
business objects (such as enterprise beans, JMS components, and so forth)
utilizes multiple types of context objects, each obtained from a different
provider (for instance, context provider for an EJB application server may be
different from the context provider for JMS service).

ServiceFactory

The ServiceFactory object represents an object that provides lifecycle
management for the BusinessService objects. The ServiceFactory object for
enterprise bean components is an EJBHome object. The ServiceFactory for JMS
components can be a JMS ConnectionFactory object such as a
TopicConnectionFactory (for publish/subscribe messaging model) or a
QueueConnectionFactory (for point-to-point messaging model).

BusinessService

The BusinessService is a role that is fulfilled by the service
the client is seeking to access. The BusinessService object is created or looked
up or removed by the ServiceFactory. The BusinessService object in the context
of an EJB application is an enterprise bean component. The BusinessService
object in the context of a JMS application can be a TopicConnection or a
QueueConnection. The TopicConnection and QueueConnection can be then be used to
produce a JMSSession object such as TopicSession or a QueueSession respectively.

Sample Example

You can find sample code from Core J2EE Patterns implemented at http://www.phptr.com/corej2eepatterns/codeChap8_3.html
- ex8.33

The two variations of Service Locator implementation strategy are:

  1. Typed checked Service Locator strategy
  2. For an enterprise bean lookup, or any JNDI service lookup, often the JNDI
    name is passed as the input argument. Instead, the clients can just pass a
    constant as the input argument and Service Locator will find the corresponding
    JNDI name from the input constant. This approach gives the advantage of type
    safety as the clients can’t pass any arbitrary JNDI names, but the approach
    is not extensible. So, this approach suits the requirement, where number of
    objects to be looked up is well- known and it is less in number.

  3. Service Locator Properties strategy
Advertisment

Service Locator Properties strategy tries to solve the limitation of
Typed checked Service Locator strategy problem by allowing to define the
constants and JNDI names in a Property file such as the deployment
descriptor or an XML property file. The file can be read only once at the
start-up time. This strategy avoids hard-coding the JNDI names in the
program.

Conclusion

We had already mentioned about Service Locator in other patterns. The
various patterns that use Service Locator pattern to locate JNDI-administered
objects are

  • Business
    Delegate


    The Business Delegate pattern uses Service Locator to gain access to
    the service objects like EJB objects, JMS topics and JMS queues. This
    separates the complexity of service location from the Business Delegate
    leading to loose coupling and increased manageability.
  • SessionFacade

    The Session Façade pattern uses Service Locator to gain access to
    the enterprise beans that are involved in a workflow. The Session Façade
    could directly use the Service Locator or delegate the work to a Business
    Delegate (see BusinessDelegate pattern).
  • Value
    Object Assembler


    The Value Object Assembler pattern uses Service Locator to gain
    access to the various enterprise beans it needs to access to build its
    composite value object. The Value Object Assembler could directly use the
    Service Locator or delegate the work to a Business Delegate (see
    BusinessDelegate pattern).

Reference:

Core J2EE Patterns, Deepak Alur, John Crupi, Dan Malks

http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/

Advertisment

(The authors are senior developers at MindTree Consulting. They can be
reached at avijeetd@mindtree.com
and
satyabrata_dash@mindtree.com.)

tech-news