Software patterns for better bioinformatics applications: some experiences with Chipster Aleksi Kallio CSC - IT Center for Science [email_address]

Background For several years, our team has been developing and providing service on top of Chipster Chipster is a client centric distributed system for bioinformatics data analysis, with a focus on microarrays User friendly full graphical interface Supports major array types (Illumina, Affymetrix, Agilent, cDNA)‏ Comprehensive selection of analysis tool, mostly based on R/Bioconductor Possibility to construct (and share) analysis workflows‏ Written in Java I will present two software patterns that I consider useful in the context of bioinformatics applications, even though they are purely generic

For several years, our team has been developing and providing service on top of Chipster

Chipster is a client centric distributed system for bioinformatics data analysis, with a focus on microarrays

User friendly full graphical interface

Supports major array types (Illumina, Affymetrix, Agilent, cDNA)‏

Comprehensive selection of analysis tool, mostly based on R/Bioconductor

Possibility to construct (and share) analysis workflows‏

Written in Java

I will present two software patterns that I consider useful in the context of bioinformatics applications, even though they are purely generic

Pattern: Graceful GUI blocking Motivation It is not feasible to do all GUI actions concurrently (loading previous sessions, for example)‏ It is ok for an application to be busy as long as user understands what's happening Problem statement How to gracefully block GUI? GUI should be updated normally to keep it in sync User should not be able to mess with the GUI It should look nice and informative

Motivation

It is not feasible to do all GUI actions concurrently (loading previous sessions, for example)‏

It is ok for an application to be busy as long as user understands what's happening

Problem statement

How to gracefully block GUI?

GUI should be updated normally to keep it in sync

User should not be able to mess with the GUI

It should look nice and informative

Pattern: Graceful GUI blocking Solution Place an opaque layer on top of the main window, with information on what's happening The opaque layer consumes all GUI events, blocking user out Supported by Swing with glass pane feature Pros Looks nice GUI feels more responsive Simple to implement, also when refactoring old code Cons UI is blocked (but that was the motivation for this in the first place)‏

Solution

Place an opaque layer on top of the main window, with information on what's happening

The opaque layer consumes all GUI events, blocking user out

Supported by Swing with glass pane feature

Pros

Looks nice

GUI feels more responsive

Simple to implement, also when refactoring old code

Cons

UI is blocked (but that was the motivation for this in the first place)‏

Pattern: Graceful GUI blocking // setting up JRootPane rootPane = SwingUtilities.getRootPane(mainFrame); rootPane.setGlassPane(waitPanel); // implementing wait waitPanel.startWaiting("Please wait..."); Thread backgroundThread = new Thread(new Runnable() { public void run() { try { // do your stuff } finally { waitPanel.stopWaiting(); } } }).start();

Pattern: Graceful GUI blocking Use SwingUtilities.invokeAndWait inside the Runnable.run WaitGlassPane source available from: http://chipster.svn.sourceforge.net/viewvc/chipster/trunk/src/main/java/fi/csc/microarray/client/waiting/WaitGlassPane.java?revision=111&view=markup

Use SwingUtilities.invokeAndWait inside the Runnable.run

WaitGlassPane source available from: http://chipster.svn.sourceforge.net/viewvc/chipster/trunk/src/main/java/fi/csc/microarray/client/waiting/WaitGlassPane.java?revision=111&view=markup

Pattern: Self service distributed state management Motivation Making a heavily distributed system easy also for administrators (that's us!)‏ After 2 years of public service this pattern has proved its worth and we have been able to concentrate on further development instead of nurturing an ill-behaving service Problem statement System should be distributable (for load balancing, multitier networks / firewalls / DMZ's, ...) WITHOUT a single point of failure Typical solutions (brokers, RPC, ...) introduce a single point of failure unless complicated tweaks are done

Motivation

Making a heavily distributed system easy also for administrators (that's us!)‏

After 2 years of public service this pattern has proved its worth and we have been able to concentrate on further development instead of nurturing an ill-behaving service

Problem statement

System should be distributable (for load balancing, multitier networks / firewalls / DMZ's, ...) WITHOUT a single point of failure

Typical solutions (brokers, RPC, ...) introduce a single point of failure unless complicated tweaks are done

Pattern: Self service distributed state management Solution At very low level, use existing technology for distribution with failover support: message oriented middleware ActiveMQ / JMS Distribute application level state management to clients: every client manages distributed state that is related to it (“self-service”)‏ Examples When a job is submitted compute services offer to process it and client decides who will get it If a file broker is dropped out the client will reload missing data files to other file brokers if needed Pros No complex patterns such as 2-phase commits need to be implemented State management lifecycle same as the client lifecycle Cons Not possible without fat clients

Solution

At very low level, use existing technology for distribution with failover support: message oriented middleware ActiveMQ / JMS

Distribute application level state management to clients: every client manages distributed state that is related to it (“self-service”)‏

Examples

When a job is submitted compute services offer to process it and client decides who will get it

If a file broker is dropped out the client will reload missing data files to other file brokers if needed

Pros

No complex patterns such as 2-phase commits need to be implemented

State management lifecycle same as the client lifecycle

Cons

Not possible without fat clients

Conclusion: in my opinion bioinformatics will benefit from software patterns, both generic and bioinformatics specific Acknowledgements: Jarno Tuimala, Taavi Hupponen, Petri Klemelä, Mikko Koski, Janne Käki and Eija Korpelainen For more information see chipster.sourceforge.net Or mail us at chipster@csc.fi Or meet us at poster N23 (or E21) on Monday's session Conclusion

Conclusion: in my opinion bioinformatics will benefit from software patterns, both generic and bioinformatics specific

Acknowledgements: Jarno Tuimala, Taavi Hupponen, Petri Klemelä, Mikko Koski, Janne Käki and Eija Korpelainen

For more information see chipster.sourceforge.net

Or mail us at chipster@csc.fi

Or meet us at poster N23 (or E21) on Monday's session