• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer
  • Core Java
  • Design Patterns
  • JSP
  • Servlets
  • Building Tools
  • jQuery
  • Spring
  • Hibernate
  • Mongo DB
  • More
    • HTML
    • SCJP
    • AJAX
    • UML
    • Struts
    • J2EE
    • Testing
    • Angular JS

J2EE Reference

  • Home
  • About Us
    • Java Learning Centers
  • Contact Us

Design pattern – Service Locator

February 1, 2011 By j2eereference Leave a Comment

Service Locator :

Enterprise applications require a way to look up the service objects that provide access to distributed components. J2EE applications use Java Naming and Directory Interface (JNDI) to look up enterprise bean home interfaces, Java Message Service (JMS) components, data sources, connections, and connection factories. Repetitious lookup code makes code difficult to read and maintain. Furthermore, unnecessary JNDI initial context creation and service object lookups can can cause performance problems.

The Service Locator pattern centralizes distributed service object lookups, provides a centralized point of control, and may act as a cache that eliminates redundant lookups.

Improving performance with the Singleton pattern and caching.

The Singleton pattern ensures that only a single instance of a class exists in an application. The meaning of the term “singleton” is not always clear in a distributed environment; in ServiceLocator it means that only one instance of the class exists per class loader.

The Singleton pattern improves performance because it eliminates unnecessary construction of ServiceLocator objects, JNDI InitialContext objects, and enables caching .

The Web-tier service locator also improves performance by caching the objects it finds. The cache lookup ensures that a JNDI lookup only occurs once for each name. Subsequent lookups come from the cache, which is typically much faster than a JNDI lookup.

Let’s see the below example to understand it clearly.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;
public class ServiceLocator {
       private InitialContext initialContext;
        private Map cache;
private static ServiceLocator instance;      static{instance = newServiceLocator();}
 
private ServiceLocator(){
 
try {
 
initialContext = new InitialContext();
 
cache = Collections.synchronizedMap(new HashMap());
 
} catch (NamingException ne) {
 
ne.printStackTrace();
 
} catch (Exception e) {
 
e.printStackTrace();
 
}
 
}
 
public static ServiceLocator getInstance() {
 
return instance;
 
}
 
public DataSource getDataSource(String dataSourceName)
 
{
 
DataSource dataSource = null;
 
try {
 
if (cache.containsKey(dataSourceName)) {
 
dataSource = (DataSource) cache.get(dataSourceName);
 
}
 
else {
 
dataSource = (DataSource) initialContext.lookup(dataSourceName);
 
cache.put(dataSourceName, dataSource);
 
}
 
}
 
catch (NamingException nex) {
 
nex.printStackTrace();
 
}
 
catch (Exception ex) {
 
ex.printStackTrace();
 
}
 
return dataSource;
 
}
 
}

 

Components of the above class:

We have a static block for creating instance of the class which get executed while loading the class,

Note that the no-argument constructor is private: only class ServiceLocator can construct a ServiceLocator. That also  create the initialContext object and initialize a Map to store the Data source object.

We have getInstance method , which returns the ServiceLocator instance

Finally, We have getDataSource method which accepts the  String parameter dataSourceName

In this method , we will check whether the requested datasource name present in the Map or not, If not this method will create the DataSource object and put it in the map , datasourceName as key for future reference and retun that DataSource object. Hence if there is any request in future with the same datasource name, the DataSource object will be taken from the Map and serve the client.

Note also that the HashMap used as a cache is synchronized so that it may be safely accessed from multiple threads that share the singleton instance.

Getting datasource object from  ServiceLocator:

String dataSourceName =”java:comp/env/devDS”;

DataSource ds=ServiceLocator.getInstance().getDataSource(dataSourceName);

Recommended Books

Related Posts

  • Observer pattern
  • Façade pattern
  • What is Design pattern ?
  • Singleton

Filed Under: Design Patterns

Reader Interactions

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

FOLLOW US ONLINE

  • View J2eereference-166104970118637’s profile on Facebook
  • View j2eereference’s profile on Twitter
  • View j2eereference’s profile on LinkedIn

Subscribe by email

Recent posts

  • Java Buzzwords
  • Anonymous Inner Class in Java
  • Network Programming – java.net Package
  • Java Regular Expressions
  • Method Local Inner Class in Java
  • URL Processing in Java
  • Iterator Design Pattern Implementation using Java
  • Strategy Design Pattern Implementation using Java
  • Decorator Design Pattern
  • Adapter Design Pattern Implementation using Java
  • JSF Composite Components
  • JSF UI Components
  • What is JavaServer Faces (JSF)?
  • GOF Design Patterns
  • History and Need for Design Patterns

Footer

Core Java
Design Patterns
JSP
Servlets
HTML
Building Tools
AJAX
SCJP
jQuery
Testing
Spring
UML
Struts
Java Centers
Java Training
Home
About Us
Contact Us
Copyright © j2eereference.com. All right reserved.