Saturday, September 05, 2009
Did you ever encounter issues while designing systems where more than one component is interacting with other component. If yes, the most obvious issue which you might have encountered would be the coupling issue. That is making one component interact with the other yet not making them know about others functioning. Well, today the pattern we would be talking about revolves around this issue. We are talking about command pattern.
Let us first understand what is command pattern. The formal definition is "Command Pattern encapsulates a request as an object, thereby letting us parametrize clients with different requests, queue or log request."
To understand it better, let us say that we would like to design a scheduler, which reads a request from a queue and process each until the queue is not empty. And possible requests includes:
a) Order request holds data to be written in database if the request is for an order performed.
b) If request pertains to weather reporting tool, it requests a weather class to return current temperature from a data source and then finally writing the data to a remote socket.
c) If request pertains to a third party tool, it reads its DB and creates a connection to a remote server and writes the requested data.
And for performing such operation we already have specific request classes available.
As you can see each of these request is of very different type. And we would not like scheduler to practically verify the request type and then invoke each classes pertaining to the actual request. If we do so, we would be increasing the coupling between scheduler and the request classes.
This seems to be the classic case where we can apply command pattern. Let us jump into this then without wasting any more time.
Well let us see which all classes are available for above requests:
a) Order class which allows setting an Order ID and then making a call to UpdateDB() which updates the DB using the Order ID.
b) For weather reporting a class named WeatherManagement is available, which exposes methods to read data from a component and then finally sending the data to remote client.
c) For third party tool, a class named ThirdPartyToolManagement class is avaiable which allow reading data from DB and then posting the data to an address.
Well, as you have seen we do not want scheduler to directly use these classes, we are going to apply the pattern.
The steps to apply command pattern in our case are as follows:
1. All command object will require to apply a single standard so let us define an interface named Command with a method declared Execute()
2. The actual command needs to implement the interface so that pur scheduler can make call to a single method irrespective of command. The possible commands in our case are
a) OrderCommand
b)WeatherCommand
c)ThirdPartyCommand.
So each of these will require implementing the inteface we defined above.
So let us see one of these classes:
Similarly each of the other commands can be defined.
3. Allowing the scheduler to set the command. For this let us define our Scheduler class, using the one command we have seen for our complete understanding
Let us put this to a trial run:
This is explain the functioning, though in reality a Scheduler will be dynamic and will not be static as shown here.
But what we have just seen is a single command. In reality Scheduler will have to deal with multiple command. So the command instance will be an array of commands and scheduler will serially loop though them and execute the command. And in reallity a Scheduler will be a daemon process..so let us dress it up like that
Refer to the class diagram below for details.
As you have seen we have decoupled the scheduler from the actual request it is making. Now our scheduler no more worry about the actual command it is processing. All it knows is it is required to make a call to Execute() method and that's all.
If you need any clarification, please write to me.
Let us first understand what is command pattern. The formal definition is "Command Pattern encapsulates a request as an object, thereby letting us parametrize clients with different requests, queue or log request."
To understand it better, let us say that we would like to design a scheduler, which reads a request from a queue and process each until the queue is not empty. And possible requests includes:
a) Order request holds data to be written in database if the request is for an order performed.
b) If request pertains to weather reporting tool, it requests a weather class to return current temperature from a data source and then finally writing the data to a remote socket.
c) If request pertains to a third party tool, it reads its DB and creates a connection to a remote server and writes the requested data.
And for performing such operation we already have specific request classes available.
As you can see each of these request is of very different type. And we would not like scheduler to practically verify the request type and then invoke each classes pertaining to the actual request. If we do so, we would be increasing the coupling between scheduler and the request classes.
This seems to be the classic case where we can apply command pattern. Let us jump into this then without wasting any more time.
Well let us see which all classes are available for above requests:
a) Order class which allows setting an Order ID and then making a call to UpdateDB() which updates the DB using the Order ID.
b) For weather reporting a class named WeatherManagement is available, which exposes methods to read data from a component and then finally sending the data to remote client.
c) For third party tool, a class named ThirdPartyToolManagement class is avaiable which allow reading data from DB and then posting the data to an address.
Well, as you have seen we do not want scheduler to directly use these classes, we are going to apply the pattern.
The steps to apply command pattern in our case are as follows:
1. All command object will require to apply a single standard so let us define an interface named Command with a method declared Execute()
2. The actual command needs to implement the interface so that pur scheduler can make call to a single method irrespective of command. The possible commands in our case are
a) OrderCommand
b)WeatherCommand
c)ThirdPartyCommand.
So each of these will require implementing the inteface we defined above.
So let us see one of these classes:
public class OrderCommand implements Command
{
Order objOrder; //this is reference to the class which was supplied for order management
public OrderCommand(Order objOrd)
{
objOrder = objOrd;
}
public void Execute()
{
objOrder.UpdateDB();
}
}
Similarly each of the other commands can be defined.
3. Allowing the scheduler to set the command. For this let us define our Scheduler class, using the one command we have seen for our complete understanding
public class Scheduler
{
Command objCmd;
public void SetCommand(Command objCommand)
{
objCmd = objCommand;
}
public void ExecuteScheduler()
{
objCmd.Execute();
}
}
Let us put this to a trial run:
public class TrailScheduler
{
public static void main(String args[])
{
Schduduler objScheduler = new Scheduler();
Order objOrder = new Order(); //creating an instance of actual receiver
objOrder.SetOrderID(12); //set the order Id on which operation is to take place
OrderCommand objOrdCmd = new OrderCommand(objOrder); //creating a command and wrapping the order instance
objScheduler.SetCommand(objOrdCmd);//setting the command finally in the scheduler
objScheduler.ExecuteScheduler();
}
}
This is explain the functioning, though in reality a Scheduler will be dynamic and will not be static as shown here.
But what we have just seen is a single command. In reality Scheduler will have to deal with multiple command. So the command instance will be an array of commands and scheduler will serially loop though them and execute the command. And in reallity a Scheduler will be a daemon process..so let us dress it up like that
public class Schedueler
{
Command[] aObjCmd;
public void Scheduler()
{
aObjCmd = new Command[10];
Command nullCmd = new nullCommand();
for(int i = 0; i < 10; i++)
{
aObjCmd[i] = nullCmd;
}
}
private void RetrieveNSetCommand()
{
aObjCmd = GetDataFromSource(); //this retrieve the ready command objects from a source
}
public void ExecuteScheduler()
{
while(true) //make it infinite
{
RetrieveNSetCommand(); //this loads all command from a source
for(int i = 0; i < 10; i++)
{
aObjCmd[i].Execute(); //execute each of the retrieved commands
}
}
}
}
Refer to the class diagram below for details.
As you have seen we have decoupled the scheduler from the actual request it is making. Now our scheduler no more worry about the actual command it is processing. All it knows is it is required to make a call to Execute() method and that's all.
If you need any clarification, please write to me.
Labels: architecture, Command Pattern, coupling, decorator design pattern, decoupling, Object Oriented Patterns
Sunday, August 09, 2009
Let us look into a pattern which will help us learn how to decorate our classes at runtime using a form of object composition. Yes, we will talk about Decorator Pattern today. It is influenced by the design principle which says "Classes should be open for extension, but closed for modification." That is, by applying this pattern our classes need not be modified for extension. Let us now jump into a real time example.
Let us say we got an offer to develop an object oriented system for a fastfood chain. The system has to calculate the price for each order that is placed at the counter. This system will be installed on the macros placed at the counter.
This may sound simple, but the issue is there are N number of combination for an order. For analyzing this requirement further let us track few of the orders to understand the combination.
Order No. 1: One Turkey Breast + without cheese + with dark chocolate toppings.
Order No. 2: One Oven Roasted Chicken Breast + with extra cheese + dark chocolate topping.
Order No. 3: One Black Forest Ham + with extra cheese + fruit cream topping.
If we see orders above, you would see that each order is different and each person could choose any one ham and any combination of toppings out of given list of toppings. The good thing is that we have a list of hams and a list of toppings.
Now can you think of an object oriented design to solve this?
Well, let us try solving this with our conventional inheritance patterns.
Solution 1: We could create one abstarct class named Burger with an abstract method named Price() and specific classes dedicated to various combination of orders possible. Each such order implementing its Price() method to calculate the price for the order. But, as you might have already realized it is not a clean solution. It has too many disadvantages like it leads to class explosion, next, each time a new ham or topping is added to the menu it leads to changing the combinations, which leads to rewriting code and biggest disadvantage is that when ever a price change for any one items, all methods will have to undergo modifications. Well, in all a bad design.
Solution 2: We continue to have this abstract class Burger with properties to identify toppings like extra cheese, chocolate topping etc. That is, attribute could be bIsCheese, bIsChocolate. And setter methods to set properties to identify the toppings. The Price method now is no more abstract. The Price method of Burger class calculates price based on properties set. And the concrete classes like TurkeyBreast or OvenRoastedChickenBreast overrides the Price() method of parent class (Burger). The Price() method calls parent Price to get the Price for toppings and then adds its specific Price for the Ham.
Again not a clean solution.
OK, now we are sure that such solutions, using inheritance is not a feasible solution. Let us try now applying object combination.
Solution 3: Applying Decorator Pattern:
Let us apply decorator pattern which allow building order with combination of various items at run time. Let us see what is decorator pattern first.
The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality.
Now let us apply this to our problem. To do this we will define an interface named Burger. This will be implemented by TurkeyBreastHam, OvenRoastedChickenBreastHam and BlackForestHam. The Price() method of each of these classes will return the Price of its own. This interface Burger, is also implemented by abstract class, which will be responsible for applying decoration to our class. This class is named ToppingsDecorator. It has an abstract method named Price(). The reason behind its implementing the interface Burger is to apply same type as that of the objects to be decorated. The decorator should of same type as that of the object being decorated.
Now each of out Toppings viz., DarkChocolate, Cheese and FruitCream will inherit the abstract class ToppingsDecorator. It has an reference to Burger as an attribute, which gets initialized by its constructor.
Let us see the class diagram:
The Price() method will have following definition:
return 0.30 + objBurger.Price();
i.e., it returns the addition of its own price and add Price of the Burger it decorates.
The complete class definition for some of the classes are as follows:
public class TurkeyBreastHam implements Burger
{
public double Price()
{
return 0.99;
}
}
public abstract class ToppingsDecorator implements Burger
{
public abstract double Price();
}
public class DarkChocolate extends ToppingsDecorator
{
Burger objBurger;
public DarkChocolate(Burger objBurg)
{
objBurger = objBurg;
}
public double Price()
{
return 0.30 + objBurger.Price();
}
}
Let us see one of the implementation to understand it better
public class FastFoodSystems
{
public static void main(String args[])
{
Burger objBurger = new TurkeyBreastHam(); //order a TurkeyBreastHam
objBurger = new Cheese(objBurger); // on this order a Cheese toppings
objBurger = new DarkChocolate(objBurger); /// and then a DarkChocolate Topping
System.out.println("The Total Price for the order is " + objBurger.Price()); //the price of order TurkeyBreastHam + Cheese + Dark Chocolate
}
}
So, this is our solution. It is clean and a scalable solution. We need not modify the class to add new items in menu, we simply add new classes.
That's all for the day. Do let me know what you feel about it.
Bye for now....
Let us say we got an offer to develop an object oriented system for a fastfood chain. The system has to calculate the price for each order that is placed at the counter. This system will be installed on the macros placed at the counter.
This may sound simple, but the issue is there are N number of combination for an order. For analyzing this requirement further let us track few of the orders to understand the combination.
Order No. 1: One Turkey Breast + without cheese + with dark chocolate toppings.
Order No. 2: One Oven Roasted Chicken Breast + with extra cheese + dark chocolate topping.
Order No. 3: One Black Forest Ham + with extra cheese + fruit cream topping.
If we see orders above, you would see that each order is different and each person could choose any one ham and any combination of toppings out of given list of toppings. The good thing is that we have a list of hams and a list of toppings.
Now can you think of an object oriented design to solve this?
Well, let us try solving this with our conventional inheritance patterns.
Solution 1: We could create one abstarct class named Burger with an abstract method named Price() and specific classes dedicated to various combination of orders possible. Each such order implementing its Price() method to calculate the price for the order. But, as you might have already realized it is not a clean solution. It has too many disadvantages like it leads to class explosion, next, each time a new ham or topping is added to the menu it leads to changing the combinations, which leads to rewriting code and biggest disadvantage is that when ever a price change for any one items, all methods will have to undergo modifications. Well, in all a bad design.
Solution 2: We continue to have this abstract class Burger with properties to identify toppings like extra cheese, chocolate topping etc. That is, attribute could be bIsCheese, bIsChocolate. And setter methods to set properties to identify the toppings. The Price method now is no more abstract. The Price method of Burger class calculates price based on properties set. And the concrete classes like TurkeyBreast or OvenRoastedChickenBreast overrides the Price() method of parent class (Burger). The Price() method calls parent Price to get the Price for toppings and then adds its specific Price for the Ham.
Again not a clean solution.
OK, now we are sure that such solutions, using inheritance is not a feasible solution. Let us try now applying object combination.
Solution 3: Applying Decorator Pattern:
Let us apply decorator pattern which allow building order with combination of various items at run time. Let us see what is decorator pattern first.
The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality.
Now let us apply this to our problem. To do this we will define an interface named Burger. This will be implemented by TurkeyBreastHam, OvenRoastedChickenBreastHam and BlackForestHam. The Price() method of each of these classes will return the Price of its own. This interface Burger, is also implemented by abstract class, which will be responsible for applying decoration to our class. This class is named ToppingsDecorator. It has an abstract method named Price(). The reason behind its implementing the interface Burger is to apply same type as that of the objects to be decorated. The decorator should of same type as that of the object being decorated.
Now each of out Toppings viz., DarkChocolate, Cheese and FruitCream will inherit the abstract class ToppingsDecorator. It has an reference to Burger as an attribute, which gets initialized by its constructor.
Let us see the class diagram:
The Price() method will have following definition:
return 0.30 + objBurger.Price();
i.e., it returns the addition of its own price and add Price of the Burger it decorates.
The complete class definition for some of the classes are as follows:
public class TurkeyBreastHam implements Burger
{
public double Price()
{
return 0.99;
}
}
public abstract class ToppingsDecorator implements Burger
{
public abstract double Price();
}
public class DarkChocolate extends ToppingsDecorator
{
Burger objBurger;
public DarkChocolate(Burger objBurg)
{
objBurger = objBurg;
}
public double Price()
{
return 0.30 + objBurger.Price();
}
}
Let us see one of the implementation to understand it better
public class FastFoodSystems
{
public static void main(String args[])
{
Burger objBurger = new TurkeyBreastHam(); //order a TurkeyBreastHam
objBurger = new Cheese(objBurger); // on this order a Cheese toppings
objBurger = new DarkChocolate(objBurger); /// and then a DarkChocolate Topping
System.out.println("The Total Price for the order is " + objBurger.Price()); //the price of order TurkeyBreastHam + Cheese + Dark Chocolate
}
}
So, this is our solution. It is clean and a scalable solution. We need not modify the class to add new items in menu, we simply add new classes.
That's all for the day. Do let me know what you feel about it.
Bye for now....
Labels: decorator design pattern, design, Object Oriented Design
Sunday, August 02, 2009
Today I will talk about a simple pattern called Strategy Pattern. Strategy Pattern is influenced by the design principle "The aspects of your application which vary should be separated from the aspects which does not vary".
Suppose you are designing a Gaming Application where you have many characters viz., King, Queen, Knight and Troll. Each character can make use of one weapon at a time, but can change weapons at any time during the game.
If you analyze the application, the obvious design solution would be to have a class named Character, where fight() would be a method. But since each character has a different style of fighting, we will have to make separate classes for each character, implementing the fight method on their own. The class we identified named character, will have to be declared as an abstract with fight method declared abstract. So, now all the character classes identified will inherit this abstract class, Character.
Now let us focus on our next requirement. The next requirement is that each character can make us of one weapon at a time. So we can think of identifying the weapon for each character and make one weapon an attribute of each character class. The possible weapons could be Knife, Bows & Arrow, Axe and Sword. Now let us fix one weapon for each of these classes and let their fight() method use 'em. OK, looks fine.
Opps!...but we missed one of the important requirement, which is..."the characters can change their weapon at any time during the game". Oh!...that's bad.... Well now things looks difficult. Let us analyze it again. OK, we read earlier in this article that one of the design principle states that we should separate the aspect of our application which changes. Let us try using this concept. Here we see that the weapons are changing all through out..but rest of the aspect stays on... so we will now prepare a separate set of classes for weapons and then link these weapon classes with our character class with a "Has-a" relation. Well, to do this let us follow one more design principle which states that "never program to an implementation..program application to an interface".
So we set an interface named Weapon, which declares a method named UseWeapon(). All weapon classes implements this interface viz., Knife, Bows & Arrow, Axe and Sword. Now we link this interface to our character abstract class to draw a "Has-a" relation. This will give our Character class enormous capability to dynamically change weapons.
Now our character class has an attribute defined of type Weapon, which can be at run time set to any of the weapon classes. We also implement a method named SetWeapon() in our abstract class. Now our classes looks like this..
So now all our concrete classes can use this.objWeapon in fight method and allow the weapon to be changed at run time.
Let us see one of the possible implementation
Character objCharacter = new King();
Weapon objKnife = new Knife();
Weapon objSword = new Sword();
objCharacter.SetWeapon(objKnife);
objCharacter.fight(); //fighting with Knife now
objCharacer.SetWeapon(objSword);
objcharacter.fight(); //now fighting with a sword
This is how we implement Strategy Pattern. Let us now see the formal definition of this pattern. The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Now you are armed with yet another pattern. That's all for the day...please do let me know, what you think about this pattern.....Looking forward to your comments......Bye for now...
Suppose you are designing a Gaming Application where you have many characters viz., King, Queen, Knight and Troll. Each character can make use of one weapon at a time, but can change weapons at any time during the game.
If you analyze the application, the obvious design solution would be to have a class named Character, where fight() would be a method. But since each character has a different style of fighting, we will have to make separate classes for each character, implementing the fight method on their own. The class we identified named character, will have to be declared as an abstract with fight method declared abstract. So, now all the character classes identified will inherit this abstract class, Character.
Now let us focus on our next requirement. The next requirement is that each character can make us of one weapon at a time. So we can think of identifying the weapon for each character and make one weapon an attribute of each character class. The possible weapons could be Knife, Bows & Arrow, Axe and Sword. Now let us fix one weapon for each of these classes and let their fight() method use 'em. OK, looks fine.
Opps!...but we missed one of the important requirement, which is..."the characters can change their weapon at any time during the game". Oh!...that's bad.... Well now things looks difficult. Let us analyze it again. OK, we read earlier in this article that one of the design principle states that we should separate the aspect of our application which changes. Let us try using this concept. Here we see that the weapons are changing all through out..but rest of the aspect stays on... so we will now prepare a separate set of classes for weapons and then link these weapon classes with our character class with a "Has-a" relation. Well, to do this let us follow one more design principle which states that "never program to an implementation..program application to an interface".
So we set an interface named Weapon, which declares a method named UseWeapon(). All weapon classes implements this interface viz., Knife, Bows & Arrow, Axe and Sword. Now we link this interface to our character abstract class to draw a "Has-a" relation. This will give our Character class enormous capability to dynamically change weapons.
Now our character class has an attribute defined of type Weapon, which can be at run time set to any of the weapon classes. We also implement a method named SetWeapon() in our abstract class. Now our classes looks like this..
So now all our concrete classes can use this.objWeapon in fight method and allow the weapon to be changed at run time.
Let us see one of the possible implementation
Character objCharacter = new King();
Weapon objKnife = new Knife();
Weapon objSword = new Sword();
objCharacter.SetWeapon(objKnife);
objCharacter.fight(); //fighting with Knife now
objCharacer.SetWeapon(objSword);
objcharacter.fight(); //now fighting with a sword
This is how we implement Strategy Pattern. Let us now see the formal definition of this pattern. The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Now you are armed with yet another pattern. That's all for the day...please do let me know, what you think about this pattern.....Looking forward to your comments......Bye for now...
Labels: Design Pattern, Object Oriented Programmming, Strategy
Thursday, May 07, 2009
Today I will talk about the reactor pattern, which allow us to design and develop a scalable, efficient and realistic server. Reactor patterns can be easily realized using Java's NIO. Before I start with this pattern, let me try explaining why at all we need this pattern. Well, if you have written a server in any language you would know that a server needs to do following:
• Receive client requests
• Perform some request-specific task
• Return a response to the client
• Multiple requests should run concurrently
• Requests may contend for resources
• Tolerates slow, misbehaving or unresponsive clients
To accomplish all these, the only option we had was to follow a multi-threaded approach, where each thread corresponds to a connection from a client. The thraad then was responsible to read | decode | compute | encode | and send/write to the client socket. This ofcourse allowed us to produce a server which could more or less satisfy all the above resposbilities. But, the issues are multiple in this approach. The primary issue is performance under increasing load.
Other major issue using this approach are:
• Simulteneous access controls may become a bottleneck
• Threading per client is a serious overhead
• Belittling output as threads/CPU ratio increases
• Scalability issues
The primary reason for following this approach are i) blocking I/O and ii) Stream based I/O instead of block based I/O.
These concerns are major concerns and we can not ignore them for long. The solution of course exists and hence this article. Yes you guessed it right. The solution lies in the pattern called Reactor pattern. Let us see what it is all about. Well, the key answer to all above issues is MULTIPLEXING the request received form client. For this to happen, we must should make use of non-blocking socket. Yes, the good news is java has added a new package called java.nio which allow both non-blocking operations and the multiplexing. Well, now that we know, we have all that are required from an implementation point of view, let us focus on the actual pattern.
Well the patterns suggests following:
i) We should divide our service in terms of event.
ii) For each event we should introduce a separate Event Handler.
iii) Each event handler should be registered with an Initiation Dispatcher, which uses a Synchronous Event Demultiplexer to wait for events to occur.
iv) When events occurs the Event Demultiplexer notifies the Initiation Dispatcher, which in turn initiates the Event Handler associated with the event.
v) The Event Handler then process the event and calls the method that implements the requested service.
If that was too much to digest, let us relax a bit.
Now let us see what it all meant. Let us continue with our earlier example of server. First, it says we should think of dividing our service. So, in our case the events we deal with, are, Accept connection, Read, Write etc. Next, it says we should dedicate separate handler for each. Well, handler in our case could be separate classes dedicated to events like Accepting connection, Reading Data etc. Next it says, we should register each of these handlers/classes to a IntiationDispatcher. Ok, so let us do that. But how? Well, answer for us is Java's NIO. It has a selector API. So, we need to register all our socket/channel with selector. While reistering we inform selector about the event we are interested in, so that it can notify us when such event takes place. So, we inform selector that we have a server socket binded on a port and we would like to know each time there is a connection ready to be accepted. So, selector takes our instruction and waits for the event to occur. This completes our task stated by Sl. No. iii).
In (iv) it says "Event Demultiplexer notifies the Initiation Dispatcher, which in turn initiates the Event Handler associated with the event". Let us see how it happens in our case. In our case, we perform a selector.select(), which notifies us about the event which occured. We loop though each of the event.
The event we registered earlier was "ACCEPT". So, if we find a "ACCEPT" event during the loop, we initiate the handler/class associated with this event. Let us assume we had a class named ConnectionAccepter class. We intiate this class, which internally accepts the connection and its associated socket. It also, registers the accepted connection with selector and inform selector that a READ event to be notified. Now, within our main loop (of events) we will also look for a new event (apart from "ACCEPT"), which is "READ". Each time a "READ" event is found, we initiate a new class associated with READ.
Now we have seen how the (iv) is applied in our case. Let us now see what (v) says. According to this, our event handler or classes dedicated to each event should initiate method/process, which does the required service. Well, we have seen what our ConnectionAcceptor class did. It did what was required. But, the class dedicated to Read is a critical one, because that is the one, which will interpreat the message sent by our remote client and process further. So our Reader class, should parse the message read and submit it to a method or service, which could process it further. Now, the processing of data will require some time and we can not block our server for this. So, we will have to disconnect our server processing from data processing. So we may create some restricted number of worked threads, which reads a queue, where messages are submitted by the Reader handler/class. These worker thread processes them one by one in parallel. This completes all our server responsibilities and yet without any major bottlenecks.
Now, our thread count need not increase as our number of client increases, because it is no more related to number of connections we are serving. So, cheers!!!
Well, before we close let us see if this pattern has any downside. Well, as every thing has good and bad side our pattern too holds this true. It does have some limited/negligible disadvantages, which are:
- The dispatcher could become relatively slow.
- Debugging could become a bit tricky.
Well, that's all for today. Please let me know your views on this.
• Receive client requests
• Perform some request-specific task
• Return a response to the client
• Multiple requests should run concurrently
• Requests may contend for resources
• Tolerates slow, misbehaving or unresponsive clients
To accomplish all these, the only option we had was to follow a multi-threaded approach, where each thread corresponds to a connection from a client. The thraad then was responsible to read | decode | compute | encode | and send/write to the client socket. This ofcourse allowed us to produce a server which could more or less satisfy all the above resposbilities. But, the issues are multiple in this approach. The primary issue is performance under increasing load.
Other major issue using this approach are:
• Simulteneous access controls may become a bottleneck
• Threading per client is a serious overhead
• Belittling output as threads/CPU ratio increases
• Scalability issues
The primary reason for following this approach are i) blocking I/O and ii) Stream based I/O instead of block based I/O.
These concerns are major concerns and we can not ignore them for long. The solution of course exists and hence this article. Yes you guessed it right. The solution lies in the pattern called Reactor pattern. Let us see what it is all about. Well, the key answer to all above issues is MULTIPLEXING the request received form client. For this to happen, we must should make use of non-blocking socket. Yes, the good news is java has added a new package called java.nio which allow both non-blocking operations and the multiplexing. Well, now that we know, we have all that are required from an implementation point of view, let us focus on the actual pattern.
Well the patterns suggests following:
i) We should divide our service in terms of event.
ii) For each event we should introduce a separate Event Handler.
iii) Each event handler should be registered with an Initiation Dispatcher, which uses a Synchronous Event Demultiplexer to wait for events to occur.
iv) When events occurs the Event Demultiplexer notifies the Initiation Dispatcher, which in turn initiates the Event Handler associated with the event.
v) The Event Handler then process the event and calls the method that implements the requested service.
If that was too much to digest, let us relax a bit.
Now let us see what it all meant. Let us continue with our earlier example of server. First, it says we should think of dividing our service. So, in our case the events we deal with, are, Accept connection, Read, Write etc. Next, it says we should dedicate separate handler for each. Well, handler in our case could be separate classes dedicated to events like Accepting connection, Reading Data etc. Next it says, we should register each of these handlers/classes to a IntiationDispatcher. Ok, so let us do that. But how? Well, answer for us is Java's NIO. It has a selector API. So, we need to register all our socket/channel with selector. While reistering we inform selector about the event we are interested in, so that it can notify us when such event takes place. So, we inform selector that we have a server socket binded on a port and we would like to know each time there is a connection ready to be accepted. So, selector takes our instruction and waits for the event to occur. This completes our task stated by Sl. No. iii).
In (iv) it says "Event Demultiplexer notifies the Initiation Dispatcher, which in turn initiates the Event Handler associated with the event". Let us see how it happens in our case. In our case, we perform a selector.select(), which notifies us about the event which occured. We loop though each of the event.
The event we registered earlier was "ACCEPT". So, if we find a "ACCEPT" event during the loop, we initiate the handler/class associated with this event. Let us assume we had a class named ConnectionAccepter class. We intiate this class, which internally accepts the connection and its associated socket. It also, registers the accepted connection with selector and inform selector that a READ event to be notified. Now, within our main loop (of events) we will also look for a new event (apart from "ACCEPT"), which is "READ". Each time a "READ" event is found, we initiate a new class associated with READ.
Now we have seen how the (iv) is applied in our case. Let us now see what (v) says. According to this, our event handler or classes dedicated to each event should initiate method/process, which does the required service. Well, we have seen what our ConnectionAcceptor class did. It did what was required. But, the class dedicated to Read is a critical one, because that is the one, which will interpreat the message sent by our remote client and process further. So our Reader class, should parse the message read and submit it to a method or service, which could process it further. Now, the processing of data will require some time and we can not block our server for this. So, we will have to disconnect our server processing from data processing. So we may create some restricted number of worked threads, which reads a queue, where messages are submitted by the Reader handler/class. These worker thread processes them one by one in parallel. This completes all our server responsibilities and yet without any major bottlenecks.
Now, our thread count need not increase as our number of client increases, because it is no more related to number of connections we are serving. So, cheers!!!
Well, before we close let us see if this pattern has any downside. Well, as every thing has good and bad side our pattern too holds this true. It does have some limited/negligible disadvantages, which are:
- The dispatcher could become relatively slow.
- Debugging could become a bit tricky.
Well, that's all for today. Please let me know your views on this.
Labels: java nio, pattern, reactor
Sunday, March 15, 2009
Coupling & Architecture:
We all have read about tight and loose coupling. We all are aware that there exists two major type of couplings but, how many times did we try to depict and use the concept of loose coupling in our architecture? I am sure we are more driven towards tight coupling atleast practically. The reasons are:
1. Tight coupling is obvious option when scope of software application is small.
2. When development is required at rapid pace.
3. When debugging needs to be made easy for atleast new team members.
But, when this small application tries to add features and when complexity increases, we are often struck with evil called tight coupling. The reason?
The reason is straight forward. Each change in one component calls for changes in almost all other components, due to inter-dependency factor, known to us as tight coupling. It is because, each of our interacting components known more that what it needs, about the other component and hence, maintains some form of data or functionality dependency about the other component, with which it is interacting. This dependency obstructs our maintenance and feature building within our present architecture. And the intensity of evil increases when we add more new developers to the team. All new developers added, are hardly aware of already present complexity and their main aim is to some how manage, and get the feature working. This further accelerates the already complex situation.
When such situation arises, we are often seen compromising with many critical factors like: a) Optimization b) Resource utilization etc etc.
Then what is the way out?
The only way out is, while architecting a system always try to design a loosely coupled system. I agree, often during the initial phases, it will feel like a burden, from both architect and developers perspective. But, as an architect our aim is to NOT only think of present, but also of future. In most of the cases, we see that all system/application grows with time and hence desiging a loosly coupled system will always pay in long term.
But what exactly is loosely coupled design?
A loosely coupled design is one, where components does not bear complex assumptions while interacting with each other. For example, if we have two components say, a web-service and a scheduler, where web-service feeds the scheduler with some kind of data. In such scenario, the scheduler should not expect a particular order of data ie, assumption like, the first node will always hold the Primary ID and next node will holds the API name etc. Rather, it would be a wise choice to expect that where ever a Primary ID key is encountered, it is assumed to be holding Primary ID and so on. In such case, within the web service even if I change the order of my data, Scheduler need not change. Another good example could be in a web-application scenario, where, even if I change a database field my inteface component need not change. It is because, while designing the system I decided to create a component called Model. Which is positioned between Interface and my database layer, which takes care of data and always sends data in the same manner, irrespective of database structure, to the consumer component, which is interface in this case. So, we are no more concerned about the changes in one component effecting the other. So our initial effort pays later.
Please let me know, if you have some other view on this, and any feedback that you might have for me.
We all have read about tight and loose coupling. We all are aware that there exists two major type of couplings but, how many times did we try to depict and use the concept of loose coupling in our architecture? I am sure we are more driven towards tight coupling atleast practically. The reasons are:
1. Tight coupling is obvious option when scope of software application is small.
2. When development is required at rapid pace.
3. When debugging needs to be made easy for atleast new team members.
But, when this small application tries to add features and when complexity increases, we are often struck with evil called tight coupling. The reason?
The reason is straight forward. Each change in one component calls for changes in almost all other components, due to inter-dependency factor, known to us as tight coupling. It is because, each of our interacting components known more that what it needs, about the other component and hence, maintains some form of data or functionality dependency about the other component, with which it is interacting. This dependency obstructs our maintenance and feature building within our present architecture. And the intensity of evil increases when we add more new developers to the team. All new developers added, are hardly aware of already present complexity and their main aim is to some how manage, and get the feature working. This further accelerates the already complex situation.
When such situation arises, we are often seen compromising with many critical factors like: a) Optimization b) Resource utilization etc etc.
Then what is the way out?
The only way out is, while architecting a system always try to design a loosely coupled system. I agree, often during the initial phases, it will feel like a burden, from both architect and developers perspective. But, as an architect our aim is to NOT only think of present, but also of future. In most of the cases, we see that all system/application grows with time and hence desiging a loosly coupled system will always pay in long term.
But what exactly is loosely coupled design?
A loosely coupled design is one, where components does not bear complex assumptions while interacting with each other. For example, if we have two components say, a web-service and a scheduler, where web-service feeds the scheduler with some kind of data. In such scenario, the scheduler should not expect a particular order of data ie, assumption like, the first node will always hold the Primary ID and next node will holds the API name etc. Rather, it would be a wise choice to expect that where ever a Primary ID key is encountered, it is assumed to be holding Primary ID and so on. In such case, within the web service even if I change the order of my data, Scheduler need not change. Another good example could be in a web-application scenario, where, even if I change a database field my inteface component need not change. It is because, while designing the system I decided to create a component called Model. Which is positioned between Interface and my database layer, which takes care of data and always sends data in the same manner, irrespective of database structure, to the consumer component, which is interface in this case. So, we are no more concerned about the changes in one component effecting the other. So our initial effort pays later.
Please let me know, if you have some other view on this, and any feedback that you might have for me.
Labels: architecture, coupling, design
Saturday, October 06, 2007
Let's talk about TCP/IP today.
For us to understand this completely we will be required to cover bit of theory first and
then we can proceed to take a case.
TCP stands for Transmission Control Protocol/Internet Protocol. This is a four layered protocol. The layers are
1. Application Layer
2. Transport Layer
3. Internet/Network Layer
4. Physical Layer.
Now let's see what all are handled at each layers.
Let's start from bottom.
1. Physical Layer: This is the layer, where physical network is taken care of. This layer deals with the network adapter and its device driver. So if we have a switch, it is implemented at this layer.
Popular protocols like PPP (Point to point protocol) etc are handled at this layer. Covering these protocols here, is beyond the scope of this article.
2. Internet Layer/Network Layer: This is the layer, where Internet Protocol is applied. This layer can be compared with the network layer of OSI. This is the layer, where we would apply routing protocols and handle routers.Its job is to send packets or datagrams - a term which basically means “blocks of data” - from one point to another. It uses the physical protocol to
achieve this. Both the network layer and the physical layer are concerned with getting data from point AB to point BC.
However,whilst the network layer works in the world of TCP/IP, the physical layer has to deal with the real world or real hardware. This is the layer, which breaks packet further depending on the MTU (Maximum Transmission Unit) of the datalink layer. It adds it's own headers, which are parsed by the destination Network layer of the TCP/IP stack. IP or Internet
Protocol, which works on this layer, does not guarantee an error free transmission for the packets.
3.Transport Layer: This is the layer on which TCP or UDP (User Datagram Protocol) works.
The UDP or User Datagram Protocol does not need to establish a connection with a host before exchanging data, and there is no mechanism for ensuring that data sent is received.
TCP or Transmission Control Protocol on the other hand provides reliability. An application that uses TCP knows that data it sends is received at the other end, and that it is received correctly. TCP uses checksums on both headers and data. When data is received, TCP sends an acknowledgement back to the sender. If the sender does not receive an acknowledgement within a certain timeframe the data is re-sent. The data received by this layer fronm higher layer is broken down into packets and then headers are added. Though
UDP is non-reliable transmission mechanism but the advantage is the fastness. Since it don't worry about the accuracy the overhead is less and hence better speed in transmision. This is the reason, why UDP is used while buffering songs and movies.
4. Application Layer: This is the layer, where we talk about the underlaying application. This layer takes special care of destination address and port and host address and port. So this four tuple information is most critical to this layer. A 32 bit IP address, and 16 bit port number is used for both detination and host. Using this 16 bit port number it decides the application. By applicaton we mean, whether it is HTTP, FTP or SMTP and so on. The default port ca be used to identify the application protocol. For example, if it is port 80, we know it is HTTP, if it is 21, we know it is FTP and so on. Howvwer, even if an appication is configured at a port other than the default one, it hardly matters to ths layer. All it needs is the correct IP and port. Say, HTTP in destination is configured at port 8080, the application layer will handle the packet at that port at destination's end.
So this was bit of theory we required to know about TCP/IP. I would recommend you to go thorough some good resource to cover the underlying protocols like PPP, UDP etc...
Now let's use this knowledge to trace what happens when we request a web-page using our browser.
When we type a address on our browser's address bar and hit the 'Enter' key the activity starts.
First, once we do that browsers prepares a HTTP request header, retrieves the IP and sends it to the network. The local gateway's server will have the TCP stack, which will take control of the data. It will then (as discussed earlier), will be received by the application layer, determine the host, destination's IP:port and then hand it over to the application layer and so on. TCP divides the data into MTUs (multiple transmission units, which is determined by the data link layer of the network) and adds its own headers which contains directives like Checksum, Sequences etc. TCP also has a error control mechanism. So, for a packet if an acknowledgment is not received in a given time interval, packet is considered lost and is re-transmitted. The packet then passes to Intenet Layer (corresponds to Network layer of OSI). Here all task associated with IP is applied. Data is then passed to the physical layer for transmission. At destination end physical layers receives the data, passes it to the Internet layer. It removes its header and passes it to the Transport layer. Here it verifies directives like Checksum and other stuff to verify the data. On successful verification, an acknowledgment is sent to the Transport layer of the Source. Then it is passed to the Application layer. Now here, application layer, verifies the destination port number to identify that this needs to go the HTTP. So opens a port (80 in this example) and passes the request. On port 80, a server is generally waiting for request continuously. It listens on port 80. So the Application layers writes the data on the socket, which is accepted by the server (could be apache) and data is processed. And then the processed data is sent back to the browser (client) using the same technique.
I hope this practical example adds to your confidence in TCP/IP.
That's all from today. Please do let me know, what do you, think of this article.
For us to understand this completely we will be required to cover bit of theory first and
then we can proceed to take a case.
TCP stands for Transmission Control Protocol/Internet Protocol. This is a four layered protocol. The layers are
1. Application Layer
2. Transport Layer
3. Internet/Network Layer
4. Physical Layer.
Now let's see what all are handled at each layers.
Let's start from bottom.
1. Physical Layer: This is the layer, where physical network is taken care of. This layer deals with the network adapter and its device driver. So if we have a switch, it is implemented at this layer.
Popular protocols like PPP (Point to point protocol) etc are handled at this layer. Covering these protocols here, is beyond the scope of this article.
2. Internet Layer/Network Layer: This is the layer, where Internet Protocol is applied. This layer can be compared with the network layer of OSI. This is the layer, where we would apply routing protocols and handle routers.Its job is to send packets or datagrams - a term which basically means “blocks of data” - from one point to another. It uses the physical protocol to
achieve this. Both the network layer and the physical layer are concerned with getting data from point AB to point BC.
However,whilst the network layer works in the world of TCP/IP, the physical layer has to deal with the real world or real hardware. This is the layer, which breaks packet further depending on the MTU (Maximum Transmission Unit) of the datalink layer. It adds it's own headers, which are parsed by the destination Network layer of the TCP/IP stack. IP or Internet
Protocol, which works on this layer, does not guarantee an error free transmission for the packets.
3.Transport Layer: This is the layer on which TCP or UDP (User Datagram Protocol) works.
The UDP or User Datagram Protocol does not need to establish a connection with a host before exchanging data, and there is no mechanism for ensuring that data sent is received.
TCP or Transmission Control Protocol on the other hand provides reliability. An application that uses TCP knows that data it sends is received at the other end, and that it is received correctly. TCP uses checksums on both headers and data. When data is received, TCP sends an acknowledgement back to the sender. If the sender does not receive an acknowledgement within a certain timeframe the data is re-sent. The data received by this layer fronm higher layer is broken down into packets and then headers are added. Though
UDP is non-reliable transmission mechanism but the advantage is the fastness. Since it don't worry about the accuracy the overhead is less and hence better speed in transmision. This is the reason, why UDP is used while buffering songs and movies.
4. Application Layer: This is the layer, where we talk about the underlaying application. This layer takes special care of destination address and port and host address and port. So this four tuple information is most critical to this layer. A 32 bit IP address, and 16 bit port number is used for both detination and host. Using this 16 bit port number it decides the application. By applicaton we mean, whether it is HTTP, FTP or SMTP and so on. The default port ca be used to identify the application protocol. For example, if it is port 80, we know it is HTTP, if it is 21, we know it is FTP and so on. Howvwer, even if an appication is configured at a port other than the default one, it hardly matters to ths layer. All it needs is the correct IP and port. Say, HTTP in destination is configured at port 8080, the application layer will handle the packet at that port at destination's end.
So this was bit of theory we required to know about TCP/IP. I would recommend you to go thorough some good resource to cover the underlying protocols like PPP, UDP etc...
Now let's use this knowledge to trace what happens when we request a web-page using our browser.
When we type a address on our browser's address bar and hit the 'Enter' key the activity starts.
First, once we do that browsers prepares a HTTP request header, retrieves the IP and sends it to the network. The local gateway's server will have the TCP stack, which will take control of the data. It will then (as discussed earlier), will be received by the application layer, determine the host, destination's IP:port and then hand it over to the application layer and so on. TCP divides the data into MTUs (multiple transmission units, which is determined by the data link layer of the network) and adds its own headers which contains directives like Checksum, Sequences etc. TCP also has a error control mechanism. So, for a packet if an acknowledgment is not received in a given time interval, packet is considered lost and is re-transmitted. The packet then passes to Intenet Layer (corresponds to Network layer of OSI). Here all task associated with IP is applied. Data is then passed to the physical layer for transmission. At destination end physical layers receives the data, passes it to the Internet layer. It removes its header and passes it to the Transport layer. Here it verifies directives like Checksum and other stuff to verify the data. On successful verification, an acknowledgment is sent to the Transport layer of the Source. Then it is passed to the Application layer. Now here, application layer, verifies the destination port number to identify that this needs to go the HTTP. So opens a port (80 in this example) and passes the request. On port 80, a server is generally waiting for request continuously. It listens on port 80. So the Application layers writes the data on the socket, which is accepted by the server (could be apache) and data is processed. And then the processed data is sent back to the browser (client) using the same technique.
I hope this practical example adds to your confidence in TCP/IP.
That's all from today. Please do let me know, what do you, think of this article.
Tuesday, February 20, 2007
Strategy Method Pattern:
The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.
Here an object and its behaviour are separated and put into two different classes. This allows to switch the algorithm that we are using at any time. To implement the strategy pattern, we are required to define a shared interface for all algorithms. Then we can implement these interfaces.
Let's say we have an interface which should change its behaviour depending on the country from where client is logged in. We first would identify the behaviours, and for each behaviour, we would create a class holding those in form of methods. And to make sure these methods are uniformly applied thoughout, we declare an interface with these methods.
Let's say the interface is something like this
Now we identified the set of methods,
Now let's make the classes with strategies,
Now we have two startegies with us, which could grow with time, but this will hardly force us to make any changes in any of the existing codes anywhere. And moreover, we are not required to use those nested if or switches.
Let's now apply these,
So the implementation is cool. Right?
So we can conclude that when we have several objects that are basically the same, but differ only in their behaviour, it is a good idea to make use of the Strategy Pattern.
Using Strategies, we can reduce these several objects to one class that uses several Strategies.
That's all for the day...will get back with some more
patterns soon....
The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.
Here an object and its behaviour are separated and put into two different classes. This allows to switch the algorithm that we are using at any time. To implement the strategy pattern, we are required to define a shared interface for all algorithms. Then we can implement these interfaces.
Let's say we have an interface which should change its behaviour depending on the country from where client is logged in. We first would identify the behaviours, and for each behaviour, we would create a class holding those in form of methods. And to make sure these methods are uniformly applied thoughout, we declare an interface with these methods.
Let's say the interface is something like this
interface sample
{
function MakeGreeting();
function FormatDate();
}
Now we identified the set of methods,
Now let's make the classes with strategies,
class USA implements sample
{
public function MakeGeeting()
{
echo 'Hello';
}
public functon FormatDate()
{
$dData = date("F j, Y, g:i a");
return $dData;
}
}
class India implements Sample
{
public function MakeGeeting()
{
echo 'Namastey';
}
public functon FormatDate()
{
$dData = date("j, F, Y, g:i a");
return $dData;
}
}
Now we have two startegies with us, which could grow with time, but this will hardly force us to make any changes in any of the existing codes anywhere. And moreover, we are not required to use those nested if or switches.
Let's now apply these,
function __autoload($country)
{
require_once $country . '.php';
}
$country = 'usa';
$cntry = new $country;
//test formatting
print($cntry->MakeGeeting() . "
\n");
print('Today is: ');
print($cntry->FormatDate() . "
\n");
?>
So the implementation is cool. Right?
So we can conclude that when we have several objects that are basically the same, but differ only in their behaviour, it is a good idea to make use of the Strategy Pattern.
Using Strategies, we can reduce these several objects to one class that uses several Strategies.
That's all for the day...will get back with some more
patterns soon....
