How to extend the Base Class

I just met up with this scenario where I wanted to add some field in my gui panel which was shared across different use cases. But as always problem was twisted a bit. I only wanted to change panel for this use case. Base class code has some method like createFields() which used to add all fields of panel in defined layout.

Public class BasePanelClass()
{
private List components;
private List labels;
Protected void createFields()
{
// create component add it to the panel
addComponent(component1, label1);
.
.
addComponent(component2, label2);
.
.
.
}

/**
* This method adds component and label to some collection.
* Lets say draw() method will later use this collection to iterate on all components
* and put them configured layout on the panel to show
*/

Private void addComponent(component, label)
{
labels.add(label);
components.add(component);}
}
}

Now I can solve this thing by many different approaches.

i) From createFields() I can call some new protected method say addNewField(). This call will be made from point where this new field should be added. It will have empty default implementation in base class. There will be child class for this scenario say Child1PanelClass which will override this method to add required field.

ii) I can make use of flag to decide whether to or not to add required field. This even doesn't need subclassing.

Both of these approaches may serve the need and even second approach may seem like least work required and job done. Because when it comes to some very old applications where people already having nightmares maintaining them everyone wants to keep changes in code as minimum as possible.
However this is not good idea to do that. Adding addNewField() method to base class is totally irrelevant to other flows. What if some other flow later needed to add some other field in same panel. With these 2 approaches we will end up in touching panel base class code. Which may impact other scenarios and certainly will make base class messy.
So what we need to do is go back to basics of inheritance. Base class should represent things which are common to all childs. There should not be dependency downwards from base class to child class either by some empty protected method which very specific to some child class or by some conditional checks which needs to be maintained every time there is change in some child class's needs. This definitely violates dependency inversion principle.
Better way to do that can be like this. We have createFields() method in base class which adds up components to some collection. Order of the components in collection determines order of the corresponding fields on the panel. And our need is to add field somewhere on the panel for specific need.

So in base class we can now add method addComponentAfter().

/**
* Adds given component with label "label" after given index
*/
Private addComponentAfter(index, label, component)
{
labels.add(index + 1, label);
components.add(index + 1, component);
}

I defined new child class for this scenario Child1PanelClass.

Public class Child1PanelClass()
{
@overrides
Protected void createFields()
{
super.createFields();
// create field specific for this need
// add it after index
addComponentAfter(index, label, component);
}
}


So I have overridden createFields() and let my base class add fields in its way. After that added my new field in required order.
With this my base class doesn't need to be changed for any further change in some other flow. Also we have encapsulated the change for this flow and limited it to its own class.
This suffices Encapsulate the Change principle.
There can be question of base class changing order of components. Which may affect child class as it relies on ordering of fields decided by base class. However this dependency is not harmful as child class are always supposed to depend on their base. Which sounds obvious also. This is what called as Dependency Inversion.

To Summarize, There are some principles that should be followed when there is extension required to system. Decision of whether to use flags, some protected methods or subclassing with dependency inversions depends really upon many factors like time availability for the change, future change anticipations, extent of reuse etc. We have to consider all these factors before really deciding with the approach. But I prefer to do change which are following open-closed principle, dependency inversion, encapsulate the change principles. Because what we all need is system which is more stable and at same time easier for extensions.

Chaining the responsibility

I would like to share one usage of chain of responsibility pattern in my application.

Requirement is to route the message to proper backend. Input is payment instruction data. This is about determing based on type of instruction where exactly we have route message for further processing.

For this requirement i could have used simple configuration and based on some parameter i could have decided which backend handler i will delegate to. But some times this logic is complex and dificult to configure. Consider for some group of message types deciding factors may be different than other group. Morever you dont know change in logic and support for new backends.

This was guiding factor in going for chain of responsibility pattern. Here i kept chaining configuration in xml and commons api chaining support executed the chain.

Member of chain are dedicated to respective backends. Which receives same context information from chain executer and decides whether they are able to accept the message or needs to route to next member of the chain.
I can even use one chain member for more than one related backend.
Also having chaining configuration it is easier to modify chain flow.

More on multithreading

There are many things to learn when you try to solve classic problems of software engineering thinking on stepwise decisions and their consequences. I tried it for producer consumer problem and found this experiment very interesting.

Prodcucer-consumer is classic example of shared resource. Here producer produces something which consumers are waiting to consume. So why cant producer produce and directly tell consumer to use it, job done. But mostly Producers and consumers are different threads of execution. Producer can be some messages coming from some backend of the system and consumer is your application who is waiting for them for some processing. So there should be some common place for these messages so that they can be queued (or whatever based on policy) and later consumer can use them. So this is what shared resource. And there are not only one producer and one consumer thread that we are talking.

It is actually more than one. There is concern of how producer inform consumer that new message is arrived and how good the logic is that makes consumer to react as quickly as possible.

What Producer needs to do when the buffer is full?

What Consumer should do when there is no message in the buffer?

What Consumer should do after processing the message?

What if message processing itself is taking too much time and there are so many messages coming in the buffer? We can’t wait for entire message to get processed as buffer will get full and we may loose some information and increase response time which is definitely a failure at least for real time system.

What about the case when buffer should be updated by more than 2 threads at same time? What we have to lock and how long we should keep the lock considering the processing time?

First of all we will draw some requirement:

Here we have 5 producers that produce some thing after some time delay. They append those details to the queue. Now there are 5 consumers running which take those details out of the queue and process it. If buffer is full then producer can wait to allow some consumers to consume something out of the queue. If there is nothing that consumer can consume then consumer can wait for some producer to produce something.

Solution:

I have following classes:

Producer (Runnable)
Consumer (Runnable)

ThreadPool (which starts some number of threads which are meant to run the passed Runnable)

MessageBuffer (this is shared data structure by producers and consumers. Here we will have locks if buffer is empty and consumer is trying to read etc.)

Other participants are straight forward. But critical part is message buffer. I can write following simple code for addMessage and removeMessage methods.

Things to be noticed:

i) Add method will be called by producer group of thread. Remove method will be called by consumer group of threads. These are the method where shared data structure will be updated and the place where we need locking implementation.

ii) We have same lock (same MessageBuffer instance) for all (producers and consumers) threads.

Now these are common things that I find everywhere when I search for producer and consumer problem.

What is conceptually more important is this:

i) Wait is inside the while loop. This because when thread waits it is because of some condition. And when It is woken up this is not necessary that it because that condition is fulfilled. It can be interrupted from other thread, wrong notification (which should not be the case) or may be timeout. Keeping this inside the loop solves this problem as thread immediately checks condition again and if it is fulfilled then only continues.

ii) I have used wait(n) and notify(). There is some intent with this.

Use of one makes other necessary. When notify() is used to wake up waiting thread this will wake up only one thread and will keep other threads still waiting.

So imagine I have some point in time 2 producer threads waiting on buffer full condition and 2 consumer threads waiting on buffer empty condition. Yes, this scenario is possible as I have used notify() here. Now when I say notify() from some say Consumer thread that there is some space in the buffer for one producer can try to add something to queue and as all (producer and consumer) threads are locked by same messageBuffer instance, notification can go to even Consumer thread. Consider when this consumer thread wakes up queue is already empty because of last read by consumer. This newly woken up thread will check for queue empty case and as queue is empty it will again go to wait state. So we miss notification and message is still in queue even though there 2 waiting producer threads.

This could have been solve with notifyAll() method but this will lead unnecessary context switching overhead as all waiting thread (producers and consumers) will come out of waiting state and move to runnable state. Also this is meaningless when I read one message making place for one new message in queue. So waking up all say 4 waiting producer thread is unnecessary overhead.

So to solve this I have to

a) wait using wait(n) within while loop. This makes sure that even if we miss notification thread after n time will check for the condition. Yes, but of course we shouldn’t have missed the notification in first place.

b) Use different locks for reader and writers. Reader when they find that buffer is empty they wait on writer lock to which only writer can notify after adding something to the buffer and vice versa. This is important gain in performance because notification from readers are meaning less for other reader and only meant for writer.

This can be coded like this:

This code will solve the problem of unnecessary notifications and wastage of notification. Readers will notify to writers only and writer will notify readers only.

This was some explanation of producer consumer which made me to appreciate trickyness of multithreading. That’s why I like it as it makes me think like genius :)

There are many other concepts which I read in mentioned documents.

i) How to determine and optimize size of thread pool?

ii) How to use happen-before concept to make sure to avoid memory inconsistency while doing multithreading

iii) How multi core CPU’s supports concurrency and response time required for real time systems. JIT compilers options to optimize the response time for real time processing system.

iv) How garbage collection of java increases worst case response time for concurracy?

v) Support for various thread issues from new java.util.concurrent package

References:

http://www.ibm.com/developerworks/library/j-jtp0730.html

http://mindprod.com/jgloss/thread.html#VOLATILE

http://www.javaworld.com/javaworld/jw-04-2008/jw-04-realtime.html?page=4

http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html

Patterns born from design principles

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.

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.

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.

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.

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.

Interesting thing about RWT as mentioned in this article is:

"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."

Hi

Hi,
This is my first blog.

Many updates will be coming on this shortly.