Skip to main content

Changing source code at run-time with Service Locator pattern

I have a service to get some data but the result can be different basing on where the implementation is. Technically, I have two or more concrete implementation of an interface and I am able to switch using these concrete classes at run-time. That means I have a place to configure it without re-deploying the application. In order to overcome this issue, I use Service Locator design pattern and here I only care about two advantages below:
  • Encapsulating the specific implementation, we just declare the name and don't care about the implementation of the service.
  • Changing the implementation at run-time.



Client: an object that invokes the services via Service Locator
Business services: services that is used by Client.


Once again, I used the JFS Helloworld example from previous post for this example.

1. Create a service interface "CountryService" and two concrete classes "CountryService1" and "CountryService2" (Business services)

package vn.nvanhuong.servicelocator.service;

import java.util.List;

public interface CountryService{
 public List<String> getCountries();
}

The first concrete service:
package vn.nvanhuong.servicelocator.service.impl;

import java.util.ArrayList;
import java.util.List;

import vn.nvanhuong.servicelocator.service.CountryService;

public class CountryService1 implements CountryService{

 public List<String> getCountries() {
  List<String> result = new ArrayList<String>();
  result.add("Vietname");
  result.add("Switzerland");
  result.add("Japan");
  return result;
 }

}

The second concrete service:
package vn.nvanhuong.servicelocator.service.impl;

import java.util.ArrayList;
import java.util.List;

import vn.nvanhuong.servicelocator.service.CountryService;

public class CountryService2 implements CountryService{

 public List<String> getCountries() {
  List<String> result = new ArrayList<String>();
  result.add("Vietname");
  result.add("America");
  result.add("China");
  return result;
 }

}

2. Create class "InitialContext" that is used for looking up and creating classes basing on the provided names
package vn.nvanhuong.servicelocator;

import java.lang.reflect.Constructor;

public class IntitialContext {
 
 public Object lookup(String serviceName){
    
  if(serviceName != null){
   try {
    Class<?> clazz = Class.forName(serviceName);
    Constructor<?> ctor = clazz.getConstructor();
    Object object = ctor.newInstance();
    return object;
   } catch (Exception ex) {
    ex.printStackTrace();
   } 
  }
  return null;
 }

}


3. Create class "ServiceLocator", I used Singleton to cache the object.
package vn.nvanhuong.servicelocator;

public class ServiceLocator {
 private static ServiceLocator instance;
 
 private ServiceLocator(){}
 
 public static synchronized ServiceLocator getInstance(){
  if(instance == null){
   return new ServiceLocator();
  }
  return instance;
 }

 public Object getService(String serviceName) {
  IntitialContext initialContext = new IntitialContext();
  return initialContext.lookup(serviceName);
 }

}

4. Create a resource file "services.properties" in order to configure the changing implementation at run-time. :)
country = vn.nvanhuong.servicelocator.service.impl.CountryService1
language = vn.nvanhuong.servicelocator.service.impl.LanguageService1

5. Calling SeviceLocator in Managed bean (Client)
package vn.nvanhuong.servicelocator.bean;

import java.io.IOException;
import java.io.InputStream;
import java.util.List;
import java.util.Properties;

import javax.faces.bean.ManagedBean;

import vn.nvanhuong.servicelocator.ServiceLocator;
import vn.nvanhuong.servicelocator.service.CountryService;

@ManagedBean(name = "helloBean")
public class HelloBean {
 private List<String> countries;
 
 public HelloBean() throws IOException {
  Properties prop = new Properties();
     InputStream input = null;
     
     String filename = "services.properties";
  input = HelloBean.class.getClassLoader().getResourceAsStream(filename);

  prop.load(input);
  CountryService countryService = (CountryService) ServiceLocator.getInstance()
              .getService(prop.getProperty("country"));
        this.countries = countryService.getCountries();
  
 }

 public List<String> getCountries() {
  return countries;
 }

 public void setCountries(List<String> countries) {
  this.countries = countries;
 }
 
}
6. GUI code: index.xhtml
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
 <title>Service Locator</title>
</h:head>
<h:body>
 <h3>Lis of countries:</h3>
 <h:dataTable value="#{helloBean.countries}" var="country">
   <h:column>
         <h:outputText value="#{country}" />
     </h:column>
 </h:dataTable>

</h:body>
</html>

7. Test (on Tomcat v7.0)

http://localhost:8080/service_locator/

Use the "CountryService1" by changing in "services.properties", don't need to restart the server.

country = vn.nvanhuong.servicelocator.service.impl.CountryService1




Use the "CountryService2" by changing in "services.properties", don't need to restart the server.

country = vn.nvanhuong.servicelocator.service.impl.CountryService2

Here we also can add more concrete classes of CountryService and just declare in file "services.properties" for using. For this reason, I use Java Reflection to create the objects basing on the provided names in general way otherwise we have to change the InitialContext whenever we want to add new concrete class of "CountryService".

Note:
There might have several ways to implement this pattern but the idea is general so that my example is only a case. We also can improve my implementation by using caching technique, see reference [3].


Reference:

Comments

Popular posts from this blog

Set up a web server for learning HTTP headers

Motivation We all follow the client-server model using the HTTP protocol for most of our web apps today. In development, we simply may have a backend API server and a frontend (web pages or mobile apps) only. However, it seemed that a proxy server is always required for production. In fact, most of the hardest issues in production come from integration. The requests and responses might be modified by the proxy server. Therefore, the understanding of HTTP protocol is one of the key skills to resolve those issues. I wanted to dive deep into HTTP with some core concepts such as caching, cookies, and CORS. I didn't intend to go quickly rather than moved slowly to have a well understanding of what I do. Prepare a server The easiest way is to use my laptop as a server then I can just use "localhost". I can also use ngrok to make my web server online. Finally, I use an online tool such as RedBot to check the HTTP headers. To make it more excited though, I deployed the app on A...

What the heck is Meteor DDP?

I was using Meteor for my messenger project. I was so curious about the real time connection. I wanted to know how exactly this mechanism works. In this post, I will go through the DDP Specification, an overview of WebSocket, and a simple demo about how to subscribe a publication of Rocket.Chat (containing a DDP server) from an external webpage. At a glance, I knew that Meteor invented a protocol called DDP which uses for handling real time connection. So then, what is DDP? "DDP (Distributed Data Protocol) is the stateful WebSocket protocol that Meteor uses to communicate between the client and the server." [1] All right! Why does DDP matter? "DDP is a standard way to solve the biggest problem facing client-side JavaScript developers: querying a server-side database, sending the results down to the client, and then pushing changes to the client whenever anything changes in the database" . [2] In order to understand deeply the protocol, I decided ...

Awareness of Product Development

Software development can be understood simply as a program to receive inputs (i.e customer needs) and then produce outputs (i.e working software). It is worth it to know how many steps are in that program. When something gets stuck in a step, everyone is aware of that. The first painting of my son The General Process Big Picture There are two main factors in this picture including the people with roles and their interactions. All people involved in developing the product know their responsibilities clearly and how to make things done right. Therefore, a good collaboration can be reached. Product Roadmap Contribution It would be great for developers to know what the next features to work on are as well as when those features will be delivered. Therefore, the product roadmap is very important. The items in the roadmap should be contributed by ALL people involved in the product. Because software engineers directly develop, test, delivery, and monitor the software, they should also contrib...

Solving your data visualization needs with open source reporting

Most of applications have some types of data visualization needs: - Gather the data. - Perform calculation, sort, group, aggregate, total,.. - Present information professionally. and meeting user demand is crucial to the success of an application. To solve this problem, there are some different approaches: - Buy a closed-source commercial product (for example, Crystal Reports, JReport,..), we must to pay for a lot of features but maybe more of features we don't need. - Build a custom-developed solution, so we need a team to develop our solution but the problem is how much time and money that we need to spend for that. Nowaday, open source creates new choices. Firstly, we can leverage open source in a customer solution by plug-in it to our solution. Secondly, we can build open-source-based products by using open source code. There are many open source reporting tools for use in the enterprise such as BIRT, iReport, JasperReports,... In this post, I wou...

DevOps Toolchain Enhancement

 Historically, our company ubitec had started with a customer project. Agile/Scrum was our proposal for working with customers. Time by time, Agile/Scrum also became our culture for software development. To be successful with this development approach, we somehow needed to have a fast release for customers (i.e. every one week). Back then, we had a build tool Jenkins which was responsible for having sprint release packages for our customers. The build job pipelines contain some steps such as gathering the artifacts, checking the code convention, running the tests, building docker images, and packaging an archived file (a zip file). The set of tools involved in a pipeline is roughly called a toolchain. It is just a part of a bigger process called the DevOps toolchain. Source: https://www.ibm.com/blogs/cloud-archive/2016/11/devops-architecture-available-on-bluemix-garage-method-site/ DevOps is a proven method that fits Agile. Today,  it is even treated as a mandatory factor...