Spring Dynamic Modules for Cytoscape

(Under construction)

Introduction

From Cytoscape 3.0, the entire system is based on OSGi, and this modularizes Cytoscape into a collection of bundles. OSGi bundles are just regular jar files plus a simple metadata file (MANIFEST.MF) and they can be used in other non-OSGi systems. However, once we use raw OSGi API, the bundle is coupled with OSGi environment, and it is not easy to port the bundle to non-OSGi environments. Spring Dynamic Modules (Spring DM) is one of the solutions to achive maximum modulality.

Spring DM is a part of Spring Framework, which is a defacto standard framework for enterprise-level systems. Because of its populality, lots of documents and tools are available.

Usecases

The core feature/concept of Spring Framework is Inversion of Control (IoC) or Dependency Injection (DI). The point is, keep objects independent from specific framework (those objects are called POJO, Plain Old Java Objects), and use metadata to configure system. There are many usecases of Spring DM for Cytoscape:

OSGi Service Management

In an OSGi environment, objects shared by multiple bundles are usually managed by OSGi Service Registory. There are lots of Cytoscape objects which should be managed by a central registory, such as layout algorithms, commands, etc. OSGi service registory can manages those objects, but export/import OSGi service is a OSGi API dependent. By using Spring DM, we can do this without directly accessing OSGi API.

Here is an example. In 3.0, Cytoscape's high-level functions, such as layout graph or load network file will be accessible simple Command interface through a command layer:

   1 public interface Command {
   2         // Getters
   3         public String getName();
   4         public String getDescription();
   5         
   6         // Execute the command.
   7         public void execute() throws Exception;
   8 }
   9 

And actual implementation looks like the following:

   1 public class HelloCommand extends AbstractCommand {
   2         public void execute() throws Exception {
   3                 System.out.println("Hello Cytoscape");
   4         }
   5 }
   6 

These implementations will be exported as OSGi service, and they will be acessible from any bundle. At this point classes above are POJO and does not depend on OSGi API. Without Spring DM, developers have to access OSGi API to export/import these commands as OSGi service. However, once we use Spring DM, we can leave all objects as POJO. Spring handle this based on the information on metadata XML file (Bean definition file).

        <bean id="helloCommand"
                class="command.internal.commandimpl.HelloCommand">
                <property name="name" value="helloCommand" />
                <property name="description" value="Sample command" />
        </bean>

Command properties (in this case, private fields name and descriptions) are injected by Spring and it creates an instance of HelloCommand object named helloCommand.

        <osgi:service id="helloService" ref="helloCommand"
                interface="command.Command">
        </osgi:service>

This xml file exports the HelloCommand object as an OSGi service called helloService. The good news is, even if you export the OSGi service, no OSGi dependent code is necessary. (Even BundleActivator is not required.)

        <osgi:reference id="helloServiceRef"
                interface="command.Command" bean-name="helloCommand">
        </osgi:reference>

        <bean name="samplePlugin" class="org.cytoscape.SamplePlugin">
                <property name="helloCommand" ref="helloServiceRef" />
        </bean>

   1 public class SamplePlugin {
   2     Command helloCommand;
   3 
   4     // Do something with the HelloCommand...
   5 }
   6 

As you can see, all of Cytoscape code can be POJO with Spring DM.

Interface-Based Programming

One of the goals of Cytoscape 3 is a clean and easy-to-understand set of API accessible from all plugin developers. Currently, lots of implementations are published as public API and this tides actual implementations to the API design. In this case, API is tightly coupled with the current implementation. Spring is designed to solve this problem.

In Spring, a system can be described as a relationship between interfaces. Implementation detail are clearly separated from actual implementations and modules (beans) are interacting to each other through public interfaces. In the example above, there is an entry:

    <osgi:service id="helloService" ref="helloCommand"
                interface="command.Command" />

This means that all objects using this OSGi service will access it only through the interface command.Command.

Testing

Testing is a good starting point to use Spring DM for Cytoscape.

Integration Test

Mock Object

Aspect Oriented Programming

Aspect Oriented Programming (AOP) is a technique to manage cross-cutting concerns shared by multiple objects (note: AOP and object oriented programming are not mutually exclusive!). Typical cross-cutting concerns are logging and performance testing, and this is also important for Cytoscape.

Logging

Benchmarking

Managing Instances

In current version of Cytoscape, the number of object instances is manged by Java code. Usually, we need to keep some object as singleton (such as VisualMappingManager), and others should have multiple instances. Scope of objects can be controled by Spring.

    <bean id="accountService" class="com.foo.DefaultAccountService" scope="singleton"/>

Open Issues / Problems

References

Spring Framework

OSGi

Aspect Oriented Programming

Outdated_Cytoscape_3.0/Spring (last edited 2011-02-24 15:38:13 by PietMolenaar)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux