Category Archives: Design Patterns

Bootstrap (Service Loader)

1 Reply

Bootstrap has different meaning based on the context of the current subject. Today, we are going to talk about Bootstrap that is related to Software / programming technique. Bootstrap is a technique where we use to load different services at the system start based on context of any program.

Where can we use Bootstrap?

  • Where we need to load the Services / Systems / Modules dynamically. (In this program, we use bootstrap.properties to define the Services to load). Something that needs
  • Where we need to load the Services based on State of Server. For eg., any application server may be started / running with different state like NORMAL, IDLE, ERROR, UPDATE, … so on.. In that case, we can define different services to be turned on based on the modules as specified in bootstrap.properties file.
  • Where we need to take complete control of Services loaded to the System. As well, if we need to have total control of the Services to turn ON / OFF based on some events. Total instrumentation over Services can be achieved by using this technique.

Some real-time example for Bootstrap:

How is Bootstrap designed?

Check out this link in Wiki of Bootstapping where it says that Bootstrapping can be interpreted as some step by step process where it initiates each service at the boot of the system. Here in our system we made it completely property file driven (I don’t recommend to keep all configuration to be kept in database as even Database should be treated as service). So, entire Bootstrap system is a self-sustained system that doesn’t need any service to work.

Step 1. Load Service list and State of system from Property file:

We create a custom property file that defines the current state of system to be started. As mentioned above, the current state can be NORMAL, IDLE, ERROR and more.. For each and every state, we will specify list of Services that are to be started in the Bootstrap startup. The Bootstrap will first load the property file and will prepare the list of Services to be started with any optional arguments specified in the property file.

Step 2. Init and Start the Services:

Now after loading the list of Services to be loaded, the Bootstrap will start one service after another sequentially as specified in the property file. What are services? A Service is again a self-sustained module / system that will be serving application for one specific context. Some examples can be Database Access Service, Scheduler Service, SMS Service, EMAIL Service, and so on… Here we can have any types of services in the System based on its function. But, they are broadly classified under two types as ESSENTIAL or ADDON based on its need. At the Bootstrap startup, when any of the Essential services are not started due to some problem, then the booting process will be put to error mode and shut down the system automatically (Remember what happens when memory service fails when you start the computer? similar system).

Each service will run independently providing access to the system. We should be having a Service Directory something similar to JNDI implementation where we will register all booted services for further use. Any modules / application layer will access the Service Directory and will get the working instance of the service and will invoke its functionality.

After successfully starting all the services, now Bootstrap itself will change its state to NORMAL or any state as specified in bootstrap.properties.

Step 3: Accessing Service:

Now, once the Bootstrap is successfully executed and started, all the Services will be available in the Service Directory. Service Directory as said before, is a JNDI kind of implementation where we keep all the instances of services in a map where we can get it object by passing its Simple Name (of class) as context. We shall get instance that is initialized and started at Bootstrap with complete accessibility.

Step 4: Shutting down Bootstrap

If we have to put system on halt for any need, we will be executing Bootstrap’s shutdown function, where it will stop each services one by one and will finally put the server to shutdown mode. This will be really useful to take complete control on each services that are running at the time of shutdown. Particularly if we have any thread based application, we should make sure all the threads are put down before we shutdown the system.

Instrumentation / Control Panel for Services:

This Bootstrap and Service Directory totally enables us to create an Instrumentation layer, where we can create a Control panel where we can manage each and every service individually. You can think like a dashboard panel where you can turn on / off any specific service.

Programmatic Implementation (Java Based):

Considering above 4 steps, I created a simple Bootstrap implementation based on Java (We can use the same technique to create the same in any languages). Here is the class diagram generated from my source code:

Bootstrap Class Diagram

Bootstrap Class Diagram

Source Code:

I shared the source code at GitHub https://www.github.com/kousikraj/bootstrap. You can download the source code and use it in your project. You can always ping me to get any information regarding Bootstrap.

Sample Implementation:

In the source code, there is a package com.test where we have two Service Classes, TestService and DummyService for you to understand how to create a service. Also, refer to bootstrap.properties to see how to configure a properties file to start the bootstrap. There is a another file having main method BootstrapTest.java where you can run and see the output of Bootstrap.

Note:

I used Apache’s Logger for using as logger for the Bootstrap and you can run with the BasicConfigurator to see the output in console itself.

Conclusion:

Hope this Bootstrap system is easy-to-implement in your existing architecture. And it helps you to make your system more towards SOA and improves the modularity of the system.

Thanks,

Kousik Rajendran.

Advertisement

Abstract Factory Pattern – Creational Patterns

1 Reply

Download Sample Here

The Abstract Factory pattern is one level of abstraction higher than the factory pattern. You can use this pattern when you want to return one of several related classes of objects, each of which can return several different objects on request. In other words, the Abstract Factory is a factory object that returns one of several factories.

One classic application of the abstract factory is the case where your system needs to support multiple “look-and-feel” user interfaces, such as Windows-9x, Motif or Macintosh. You tell the factory that you want your program to look like Windows and it returns a GUI factory which returns Windows-like objects. Then when you request specific objects such as buttons, check boxes and windows, the GUI factory returns Windows instances of these visual interface components.

In Java 1.2 the pluggable look-and-feel classes accomplish this at the system level so that instances of the visual interface components are returned correctly once the type of look-and-feel is selected by the program. Here we find the name of the current windowing system and then tell the PLAF abstract factory to generate the correct objects for us.

String laf = UIManager.getSystemLookAndFeelClassName();

try {

UIManager.setLookAndFeel(laf);

}

catch (UnsupportedLookAndFeelException exc){

System.err.println(“UnsupportedL&F: ” + laf);

}

catch (Exception exc){

System.err.println(“Error loading ” + laf);

}

This pattern is one level of abstraction higher than factory pattern. This means that the abstract factory returns the factory of classes. Like Factory pattern returned one of the several sub-classes, this returns such factory which later will return one of the sub-classes.

Let’s understand this pattern with the help of an example given in the sample code. Suppose we need to get the specification of various parts of a computer based on which work the computer will be used for.

The different parts of computer are, say Monitor, RAM and Processor. The different types of computers are PC, Workstation and Server.  So, here we have an abstract base class Computer. This class, as you can see, has three methods all returning different parts of computer. They all return a method called Parts. The specification of Parts will be different for different types of computers. Let’s have a look at the class Parts. And now let’s go to the sub-classes of Computer. They are PC, and Server.

When to use Abstract Factory Pattern?

One of the main advantages of Abstract Factory Pattern is that it isolates the concrete classes that are generated. The names of actual implementing classes are not needed to be known at the client side. Because of the isolation, you can change the implementation from one factory to another.

Download Sample Here

Builder Pattern – Creational Pattern

Leave a reply

Download Sample Here

The Builder Pattern is a software design pattern. The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects.

The Builder Pattern separates the construction of a complex object from its representation, so that several different representations can be created depending on the needs of the program.

Often, the Builder Pattern is used to build Products in accordance to the Composite pattern, a structure pattern.

Class Diagram

Class Diagram representation of Builder Pattern

Class Diagram of Builder Pattern

Builder: Abstract interface for creating objects (product).

Concrete Builder: Provide implementation for Builder. Construct and assemble parts to build the objects.

Director: The Director class is responsible for managing the correct sequence of object creation. It receives a Concrete Builder as a parameter and executes the necessary operations on it.

Product: The Product is the final object that will be created by the Director using Builder.

  • Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
  • Builder often builds a Composite.
  • Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
  • Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components are built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

Consequences of the Builder Pattern

  •  A Builder lets you vary the internal representation of the product it builds. It also hides the details of how the product is assembled.
  •  Each specific builder is independent of the others and of the rest of the program. This improves modularity and makes the addition of other builders relatively simple.
  •  Because each builder constructs the final product step-by-step, depending on the data, you have more control over each final product that a Builder constructs.
  • A Builder pattern is somewhat like an Abstract Factory pattern in that both return classes made up of a number of methods and objects. The main difference is that while the Abstract Factory returns a family of related classes, the Builder constructs a complex object step by step depending on the data presented to it.

Download Sample Here