Hello, dear friends. In this video, we will start to examine business tier patterns starting with the service locator pattern. So, let's begin. The service locator pattern is a relatively old pattern that was very popular with java EE. Martin Fowler described it in 2004 on his blog. The goal of this pattern is to improve the modularity of your application by removing the dependency between the client and the implementation of an interface. Basically, the purpose of the service locator pattern is to return the service instances on demand. This is useful for decoupling service consumers from concrete classes. The service locator pattern is used to decouple the service consumers and the concrete classes like DAO implementations. The pattern looks for adequate service, saves it in cache storage to reduce the number of requests and therefore the strain on the server and provides the application with their instances. The server locator design pattern is used when we want to locate various services using JNDI look up. Considering high cost of looking up JNDI for a service, service locator pattern makes use of caching technique.

Spring framework internally uses service locator pattern to manage dependency injection. These days, service locator isn't of much use anymore except in very small proprietary projects. The service locator pattern is a relatively old pattern that was very popular with Java EE. As you can see in the UML of the service locator pattern, there are five participants. The client object is a service consumer. It's responsible for invoking the request from the service locator. The service locator abstracts the API lookup services, vendor dependencies, look up 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. Cache is an object for storing service references to reuse them later. The initial context 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 locators look up and creation service. The service component represents the original services or their implementation. The service factory object represents an object that provides lifecycle management for the business service objects. The service factory object for enterprise beans is an EJB home object. Now I want to create a project using this pattern. So, let's begin. Create a new project and name it ServiceLocator. In describing the previous patterns, we use the employees example. I'd like to use it again in this project. First, we need a service interface.

In the interface, we need two methods, execute and getServiceName. Now, we need a couple of concrete classes that will implement this interface. First, start with employee service, implement service, override methods. Add for customer override methods. According to the pattern when looking up for these services, we should cache them to reduce server strain. So, we have to define cache. We need service list in constructor, we will use... Also, I want to add two methods.

First one is getService method. Now, addService method. Done. We also need a class to look for and instantiate our services. Create initial context, define a new method named lookUp. Okay, done. Finally, we can define a locator class to expose to the client that uses the initial context class to look for services and the cache class to cache them for further use. Add static cache. We also need to get service method. Now, our structure is ready, let's use.

First to find a service with employee service, execute, now change with customer, execute. Okay, done. And look, we can see employees operations and customer operations. Just great. I think that covers the service locator pattern. In the next video, we will examine the business delegate pattern. So, I'll see you there, my friends.