Spring Dynamic Modules for Cytoscape

(Under construction) TableOfContents

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. [http://www.springframework.org/osgi Spring Dynamic Modules (Spring DM)] is one of the solutions to achive maximum modulality.

Spring DM is a part of [http://www.springframework.org/ 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:

Service Management

In an OSGi environment, objects shared by multiple bundles are usually managed by [http://www.knopflerfish.org/osgi_service_tutorial.html 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).

• Define objects as regular Spring Beans

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

• Export as OSGi service

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

• Import OSGi service

  • If a plugin writer wants to use the command, they should import the service from OSGi service resigtory. With Spring DM, this can be done by creating a reference to the service. The plugin should include the following XML file to import OSGi service:

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

• Now, the HelloCommand is accessible from the plugin. To use it, just inject it like regular Spring Beans:

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

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!)

Logging

Benchmarking

Example: Command Parameter Intercepter

Managing Instances by Setter Injection

Open Issues / Problems

• Inter-bundle aspect management.

References

Spring Framework

OSGi

Aspect Oriented Programming