When we talk about OO development we talk about cleaner code, separation of concerns, design principles, abstraction, encapsulation, delegation, inheritance etc. Patterns are created with these building blocks and are applicable for some problem in some context.
I have seen and coded several design patterns in my application. There are Singeltons when some thing is heavy to initialize or act as connection between 2 systems. There are strategies when i have to attach dynamic behaviour to the class. There are command patterns when i configure pluggble extentions in some xml and code decides which extension to use to serv current request. I have seen chain of responsibility when i have to try one by one of available options and go with first matching.
All these pattern are based on design principles. Actually to follow some design principle to solve current problem we end up in using some pattern. eg. To solve requirement where class wants to behave as flyable and later behave as quackable we have to encapsulate the change and delegate the request to particular implementation at runtime. These design principles combinely forms Strategy pattern.
Now based on different intent and different implementations there are different variations in the pattern. Strategy talks about switching between algorithms dynamically. Where decorator pattern talks about extending behaviour at dynamically. Both uses delegation but their intent is different. Both have change encapsulated in respective implementation. But the intent is totally different.
Thursday, May 29, 2008
Strategy pattern Usage:
Strategy pattern:
When requirement is to vary behaviour of the class dynamically we cant go for inheritance as it is tied to instance type. Strategy pattern is about separating dynamic behaviours from the class and proving way of switching between them.
I have used this pattern as follows:
Requirement:
There are 2 rate type trade booking. Real time trade booking and bench mark trade booking. For both booking there are 3 possible flows in which application can come from. All 3 flows have different behaviour for implementation. But most of the code is common for same flow in different rate types. So if I go for inheritance I will need to create 6 subclasses and any change in say flow1 has to be replicated in flow1 of other rate type as well.
Implementation:
Common abstract class for both rate type
Common abstract class for all flow types.
2 Implementation for AbstractTradeBooker
i) RtTradeBooker
ii) BMTradeBooker
3 implementation for AbstractTradeFlow
i) Flow1TradeFlow
…
Now any change in processing which is totally depedent on rate type can go in Implementation of AbstractTradeBooker and any change in some flow will go in particular implementation of AbstractTradeFlow.
There will be abstract method or may be constructor defined in AbstractTradeBooker to set instance of AbstractTradeFlow.
Also we can use template design pattern inside these abstract base classes which will define generic steps for processing and let implementation override and change implementation of specific step.
So here we have encapsulated part that is changing inside different trade flows.
Second requirement:
Consider your web application can forward request to some other application when user clicks on some link. Consider there are 2 ways of authentication of user to the new application. One can be using cookies and other using web services.
Now to decide which strategy to be used for authenticating user to this application depends upon some user level flag maintained by parent application. Based on this flag we have to decide dynamically how we will be authenticating this user to requested application.
This can be solved by having 2 implementation of the AuthenticationService. CookieBasedAuthentication and WebServiceBasedAuthenticationService and decide which instance based on the user flag at runtime.
When requirement is to vary behaviour of the class dynamically we cant go for inheritance as it is tied to instance type. Strategy pattern is about separating dynamic behaviours from the class and proving way of switching between them.
I have used this pattern as follows:
Requirement:
There are 2 rate type trade booking. Real time trade booking and bench mark trade booking. For both booking there are 3 possible flows in which application can come from. All 3 flows have different behaviour for implementation. But most of the code is common for same flow in different rate types. So if I go for inheritance I will need to create 6 subclasses and any change in say flow1 has to be replicated in flow1 of other rate type as well.
Implementation:
Common abstract class for both rate type
Common abstract class for all flow types.
2 Implementation for AbstractTradeBooker
i) RtTradeBooker
ii) BMTradeBooker
3 implementation for AbstractTradeFlow
i) Flow1TradeFlow
…
Now any change in processing which is totally depedent on rate type can go in Implementation of AbstractTradeBooker and any change in some flow will go in particular implementation of AbstractTradeFlow.
There will be abstract method or may be constructor defined in AbstractTradeBooker to set instance of AbstractTradeFlow.
Also we can use template design pattern inside these abstract base classes which will define generic steps for processing and let implementation override and change implementation of specific step.
So here we have encapsulated part that is changing inside different trade flows.
Second requirement:
Consider your web application can forward request to some other application when user clicks on some link. Consider there are 2 ways of authentication of user to the new application. One can be using cookies and other using web services.
Now to decide which strategy to be used for authenticating user to this application depends upon some user level flag maintained by parent application. Based on this flag we have to decide dynamically how we will be authenticating this user to requested application.
This can be solved by having 2 implementation of the AuthenticationService. CookieBasedAuthentication and WebServiceBasedAuthenticationService and decide which instance based on the user flag at runtime.
Tuesday, May 27, 2008
Clustering
Clustering mainly used to support failover.
Facts about web application deployed on clustered environment.
There is one instance of ServletContext, Servlet per JVM.
There is only one instance of HttpSession in distributed application for given user.
Attributes inside session implementing Serializable interface are replicated to different JVM’s.
So interesting thing is how and when session is propogated and
other things that are dependent on this behaviour.
Like how HttpSessionActivationListener comes into picture with all this. What does it mean by session activation and session passivation.
We will see how weblogic goes about implementing this.
Weblogic has the term called Sticky Sessions. This means weblogic takes care that all request of user during session active time are transferred to same instance of the server.
So when does propagation of session occurs.
Session replication happens always when you set attributes to session using setAttribute() method. Whenever attribute is set to using this method container replicates delta in session to the secondary server. So even though Weblogic uses sticky session technique when the instance to which user session is stick is failed container forward request to secondary session where user sessions replica is already maintained.
More details for this technique are available at: http://edocs.bea.com/wls/docs90/cluster/failover.html
So now about HttpSessionActivationListener. This is binding interface that attributes stored in session should implement if they want to be called back by container in case of session activation or passivation. Containers migrate sessions to different JVM's or persists them into database. Attributes implementing this interface will be called by container when it performs these activities.
Facts about web application deployed on clustered environment.
There is one instance of ServletContext, Servlet per JVM.
There is only one instance of HttpSession in distributed application for given user.
Attributes inside session implementing Serializable interface are replicated to different JVM’s.
So interesting thing is how and when session is propogated and
other things that are dependent on this behaviour.
Like how HttpSessionActivationListener comes into picture with all this. What does it mean by session activation and session passivation.
We will see how weblogic goes about implementing this.
Weblogic has the term called Sticky Sessions. This means weblogic takes care that all request of user during session active time are transferred to same instance of the server.
So when does propagation of session occurs.
Session replication happens always when you set attributes to session using setAttribute() method. Whenever attribute is set to using this method container replicates delta in session to the secondary server. So even though Weblogic uses sticky session technique when the instance to which user session is stick is failed container forward request to secondary session where user sessions replica is already maintained.
More details for this technique are available at: http://edocs.bea.com/wls/docs90/cluster/failover.html
So now about HttpSessionActivationListener. This is binding interface that attributes stored in session should implement if they want to be called back by container in case of session activation or passivation. Containers migrate sessions to different JVM's or persists them into database. Attributes implementing this interface will be called by container when it performs these activities.
Multithreading in real world
Necessity of multithreading becomes obvious when we talk about scenario where we need to process some 100 messages each one taking 20-50 seconds on average to process.
Mostly in these processing ordering doesn’t matter. So instead of processing sequentially we can make use of threads to process them (virtually) parallel.
Consider there is system which processes user scheduled actions by web application. It is commonly known as job scheduler.
Requirement here is that user triggers some activity from UI application. When these triggers should be executed and all that logic depends on scheduling policy for that trigger. So there should be one monitoring thread which will be checking when to execute that trigger based on this scheduling policy. Now this execution can take some time for execution which is completely unknown to executer. Also there can be more than one job ready for execution at that time. So it is necessary for executer to execute this job in separate thread and return back it its actual monitoring work.
So main multithreading concepts used by executer. Executer uses threadpool. Threadpool has some configured number of threads configured which keeps monitoring some jobqueue. Whenever thread finds some job in the queue it removes it from queue and owns it for its execution. Then it continues polling.
There can be other approach to this implementation. Like wait-notify approach. Thread will wait for some condition and then will be notified to all by main monitoring thread.
Thread pool size is configured based on load of processing. If there are more messages to be processed simultaneously to reduce response time then we can increase the thread pool size. Thing to remember is that thread creation is heavy process and should be minimized by reusing the thread.
This wait-notify or task queue approaches works when triggering and triggered both thread are running in same JVM. Mostly the case is where these triggering threads are in different JVMs. E.g. Web application with which user is interacting is one thread of process running in container. Actions triggered by this user interaction may cause job monitor to execute some job in some other JVM. This communication can be easily handled by database. User interaction with the screen will create entry in database and background job scheduler will get triggered from this database entry.
Main problem is when we want to notify immediately to job scheduler to execute some critical job. You can’t use wait-notify or job queue approach. One way to do this is to use Oracle signals. Concept is almost same as that of wait-notify only difference is in wait-notify we wait on object locks which are bounded to its JVM but in this case we can wait-notify at database level so spanning more than one JVM’s.
Mostly in these processing ordering doesn’t matter. So instead of processing sequentially we can make use of threads to process them (virtually) parallel.
Consider there is system which processes user scheduled actions by web application. It is commonly known as job scheduler.
Requirement here is that user triggers some activity from UI application. When these triggers should be executed and all that logic depends on scheduling policy for that trigger. So there should be one monitoring thread which will be checking when to execute that trigger based on this scheduling policy. Now this execution can take some time for execution which is completely unknown to executer. Also there can be more than one job ready for execution at that time. So it is necessary for executer to execute this job in separate thread and return back it its actual monitoring work.
So main multithreading concepts used by executer. Executer uses threadpool. Threadpool has some configured number of threads configured which keeps monitoring some jobqueue. Whenever thread finds some job in the queue it removes it from queue and owns it for its execution. Then it continues polling.
There can be other approach to this implementation. Like wait-notify approach. Thread will wait for some condition and then will be notified to all by main monitoring thread.
Thread pool size is configured based on load of processing. If there are more messages to be processed simultaneously to reduce response time then we can increase the thread pool size. Thing to remember is that thread creation is heavy process and should be minimized by reusing the thread.
This wait-notify or task queue approaches works when triggering and triggered both thread are running in same JVM. Mostly the case is where these triggering threads are in different JVMs. E.g. Web application with which user is interacting is one thread of process running in container. Actions triggered by this user interaction may cause job monitor to execute some job in some other JVM. This communication can be easily handled by database. User interaction with the screen will create entry in database and background job scheduler will get triggered from this database entry.
Main problem is when we want to notify immediately to job scheduler to execute some critical job. You can’t use wait-notify or job queue approach. One way to do this is to use Oracle signals. Concept is almost same as that of wait-notify only difference is in wait-notify we wait on object locks which are bounded to its JVM but in this case we can wait-notify at database level so spanning more than one JVM’s.
Sunday, May 11, 2008
ECLIPSE RAP
Eclise RAP
Eclipse as many people knows is about defining bundles (plugins) and extending the system. With OSGI it goes one step further and allows to add bundles to system at run time. This is what adds value to its architecture. You can add bundle to system, you can stop it, you can redeploy it and many more. This means no restart. This will sound familiar to J2EE developer. Containers supports similar kind of feutures. But difference with OSGI you can redeploy changes in class files without restart which otherwise may need restart on J2EE container.
Eclipse Rich client Ajax platform is platform which allows developers to create rich ajax ui application using their knowledge SWT development and (J2EE) servlet technologies.
Actually j2ee details is mostly encapsulated by underlying RAP framework bundles.
So thing here is that you can develop application working on AJAX, coded in JAVA SWT and runs in browser.
Commucation of SWT code to html is done by underlying RWT framework and qooxdoo framework. Developer actually codes in RWT which has same interface as of SWT and qooxdoo is javascript library which handles user events on browser and communicates with widgets on server side.
I just went into code to find how it serves the request. This is what i understood about them.
It started with url : http://localhost:8080/rapdemo/rap.
Where I have deployed one web application with context path “rapdemo”. And one servlet mapped to path /rap.
Rap application has lauch configuration file where we can specify servlet name.
Eclipse-equinox bridge receives request from client on server. This is also one bundle which is like ActionServlet in struts as it receives http request and then passes control to eclipse bundles. Deployed war file has required bundles. Based on alias “rap” in request control is transferred to proper UI with default entrypoint.
RWTDelegate is the servlet which receives request for rap applications. This servlet is mapped to path “/rap”. This servlet transfers control to RWTLifeCycleServiceHandlerSync. Here you can find more on RWTLifeCycle: http://wiki.eclipse.org/WidgetToolkit. This is about lifecycle thread that is started for this web application. This is the thread that serves user requests.
"Render: is where the markup or javascript assignments are created, which will be sent to the browser. During the actual rendering no changes of the widget-tree will happen - neither creation or addition of new widgets nor changing of attributes of existing ones. The AJaX-rendering-mode only creates assignments of those widget-attributes that were changed during the request-processing. This results in a minimal amount of information that needs to be exchanged between server and client."
Subscribe to:
Comments (Atom)