http://www.cytoscape.org/images/logo.png http://www.osgi.org/www/osgi_logos_supporter_final.png http://static.springframework.org/images/spring25.png

Cytoscape 3 Developer's Guide

Contents

  1. Cytoscape 3 Developer's Guide
    1. Status
  2. Cytoscape 3 Design Concept
    1. Introduction
    2. Why Do We Have To Learn These New Technologies?
      1. Important Design Principle of Cytoscape 3
        1. Interface Oriented Design
        2. Dependency Injection
        3. Micro Core Architecture
      2. OSGi
      3. Spring Framework and Spring Dynamic Modules
        1. Wiring Objects
        2. Separate Implementation from API
          1. Service Provider
          2. Service Consumer
      4. Building System
        1. Convention over Configuration
  3. Working with Cytoscape 3 Code
    1. Introduction
    2. Create OSGi-Spring Based Project
  4. Related Frameworks and Technologies
    1. Developer's Tutorials and References
      1. For Eclipse Users
        1. Basic Tutorial
        2. Optional
      2. For Netbeans Users
      3. Other OSGi Tools and Technical Notes
    2. Books
      1. Spring
      2. Spring DM and OSGi
      3. Maven
    3. Tricks
      1. Ignoring .svn in Bash Auto-completion
      2. Searching for Classes in Javadocs

Status

Cytoscape 3 Design Concept

Introduction

A central goal of Cytoscape 3 is to make a more modularized, expandable, and maintainable version of Cytoscape. To achieve this goal, we follow several design principles and take advantage of three new technologies:

These technologies are very powerful, but you'll need to understand a few new concepts to use them easily and effectively. The purpose of this document is to introduce the new design concepts that you will need to develop Cytoscape 3 code.

Why Do We Have To Learn These New Technologies?

Cytoscape 2.x has several architectural problems. They are:

Central to each of these problems is a lack of a module system. Unfortunately, Java lacks an effective mechanism for defining modules. To address this need, we have decided to use OSGi as a mechanism for enforcing modularization. While OSGi provides many benefits, its most important is that it provides a new scoping mechanism that allows java packages to be declared public or private. This is accomplished by adding a few lines of metadata to the manifest file of a jar. Aside from the metadata the jars (which OSGi calls bundles) are normal java jar files.

OSGi developers have built upon this scoping mechanism and developed a framework (i.e. the Service Registry) as well as design patterns that allow developers to write very clean and simple code. Taking advantage of this framework, however, requires knowledge of and use of the OSGi API, which is not necessarily a simple thing. Dealing with this concern brings us to Spring.

Spring (specifically Spring Dynamic Modules) allows us to remove all OSGi dependencies from our code yet still take advantage of the Service Registry and other OSGi features. This means that you continue to write normal java POJOs. The cost is that your code is now initialized using Spring XML configuration code.

Finally, because OSGi breaks applications into many jars (called bundles) with dependencies and version numbers we have decided to use a build tool that has an explicit model for dealing with dependencies: Maven. You can think of Maven as a formalized version of Ant or even make. Unlike other tools, Maven provides a simple structure for declaring and using dependencies. We will take advantage of Maven's dependency handling to simplify the Cytoscape build process.

Important Design Principle of Cytoscape 3

Interface Oriented Design

Fundamental throughout Cytoscape 3 and OSGi is it's enforcement ofInterface Oriented Design. Rather than make both interfaces and implementations publicly available, Cytoscape 3 will only make interfaces public. All implementations of interfaces will be hidden in internal packages and will only be available through the OSGi Service Registry and Spring. The benefit of this approach is that you only need to concern yourself with an interface. You will never need to worry about specific implementation details. As long as you code to the interface, your code should continue to work.

From a plugin writer's perspective, you should:

  1. Hide unnecessary classes and only expose a limited number of interfaces. This makes your module (plugin) easy-to-use for other developers. OSGi provides the enforcement mechanisms for this.
  2. Separate implementation from API. This makes it easy to replace implementations without breaking other modules because they access your classes only through exported interfaces. Spring DM is one of the best tools for this job.

Dependency Injection

An important aspect of Cytoscape 3 development is the idea of Dependency Injection. In practical terms, this means that all dependencies for your classes should be specified in your constructor and you should no longer be creating (most) objects on your own.

For instance, if you need to create a new CyNetwork you will not call the constructor of a particular implementation of the CyNetwork interface. Instead you will have a CyNetworkFactory injected into your class (via its constructor) and then you will ask CyNetworkFactory to provide you with a new instance of CyNetwork. The benefit of this approach is that you never see the implementation of CyNetwork which frees us from a particularly onerous dependency - the ability to change implementation easily.

Micro Core Architecture

In Cytoscape 3, all modules are equal and there is no clear distinction between Core and Plugins. Instead of running Cytoscape on the top of Java Virtual Machine, we will insert one extra layer called the OSGi runtime. Cytoscape 3 is simply a set of bundles running on top of an OSGi micro core.

The diagram above shows overall architecture of Cytoscape 3. The most important point is that all of the inter-bundle communication is managed by the OSGi service registry, meaning through interfaces only, and not through concrete classes.

architecture1.png

OSGi

OSGi is relatively complex technology, but the broad points that you should understand are as follows:

  1. OSGi's unit of modularity is the bundle. A bundle is simply a jar file with extra metadata included in the manifest.

  2. In Cytoscape 3, everything is a bundle. This means there is no longer a distinction between plugin and core.

  3. You must define which packages in your bundle are accessible to other bundles.
  4. You must define which classes are imported by your bundle. While seemingly cumbersome, this is generally automated and has the advantage of allowing you to specify specific version numbers of the library. OSGi allows different versions of the same library can exists in the same instance of a framework.

  5. Any java interface can serve as the definition of an OSGi Service. Any implementation of an interface can thus be registered as an instance of that service in the OSGi Service Registry. All bundles can access those registered services.

These solves several problems we had in version 2.x:

Suppose you want to develop a plugin to find clusters in a large network. You want to make your clustering algorithms accessible from other plugin developers. In that case, all you have to do is exporting the following interface: 

   1 public interface ClusteringService {
   2     // Run my clustering algorithm for a given network "parent" and return clusters as a set of subnetworks.
   3     public Set<CyNetwork> getClusters(CyNetwork parent);
   4 }
   5

Spring Framework and Spring Dynamic Modules

Spring is the defacto standard of lightweight container for dependency injection. Tons of books and documents are available for Spring, and you can learn its mechanism by reading them. The role of Spring in Cytoscape 3 is simple: defining relationships between objects.

Wiring Objects

The diagram below shows the relationships between objects in Cytoscape 3 desktop application. In Spring, objects are defined as beans.

spring1.png

spring2.png

This diagram represents the cytoscapeDesktop bean, which is defined in a Bean Configuration XML file: 

<bean name="cytoscapeDesktop" class="cytoscape.view.internal.CytoscapeDesktop">
    <constructor-arg ref="cytoscapeMenus" />
    <constructor-arg ref="networkViewManager" />
    <constructor-arg ref="networkPanel" />
    <constructor-arg ref="cytoscapeVersion" />
</bean>

Cytoscape Desktop is the main GUI component which includes some other components such as Network Panel or Menu Bar. To create an instance of Cytoscape Desktop, we need to provide those objects prepared somewhere outside of it. Instead of creating new instances of those required objects inside Cytoscape Desktop, you can inject them by Spring. In this case, all of the required dependency (cytoscapeMenus, networkViewManager, networkPanel, and cytoscapeVersion) are defined as beans in the Bean configuration file, and Spring injects those automatically to Cytoscape Desktop.

Separate Implementation from API

Spring is a powerful tool, but if we use Spring Dynamic Modules (Spring DM) along with it, we can take advantage of both Spring and OSGi.

Remember the ClusteringService in the last section. Without Spring, users of this object should do: 

   1 public class ClusteringServiceUser {
   2   private ClusteringService service;
   3 
   4   public ClusteringServiceUser() {
   5      // Now ClusteringServiceUser depends on an implementation ClusteringServiceImpl. 
   6     service = new ClusteringServiceImpl();
   7   }
   8 }
   9

This creates a dependency to specific implementation of ClusteringService API. With Spring, we can avoid this dependency: 

   1     AbstractApplicationContext ctx
   2       = new ClassPathXmlApplicationContext(new String []{"bean-configuration.xml"});
   3     service = ctx.getBean("clusteringServiceBean");
   4

However, this introduces a new dependency to Spring Framework itself (AbstractApplicationContext). With Spring DM, the client code looks like the following: 

   1 public class ClusteringServiceUser {
   2   private ClusteringService service;
   3 
   4   public ClusteringServiceUser(ClusteringService service) {
   5      // No dependency to frameworks! 
   6     this.service = service;
   7   }
   8 
   9   // Sample client code to find clusters for each network passes as parameter.
  10   public Map<Integer, Set<CyNetwork>> analyzeNetwork(Set<CyNetwork> networks) {
  11     final Map<Integer, Set<CyNetwork>> clusterMap = new HashMap<Integer, Set<CyNetwork>>();
  12 
  13     for(CyNetwork net:networks) {
  14       clusterMap.put(net.getSUDI(), service.getClusters(net));
  15     }
  16     return clusterMap;
  17   }
  18 }
  19

In this case, the user object depends on ClusteringService interface only and completely independent from implementations or framework. But what's the magic behind this? The answer is the combination of service configuration file and Spring OSGi Extender bundle.

Service Provider

To create an instance of ClusteringServiceImpl, you can define it as a regular Spring bean: 

<bean name="clusteringServiceBean" class="org.foo.clustering.iternal.ClusteringServiceImpl">
    <constructor-arg ...
</bean>

Now you need to export this as an OSGi service: 

<osgi:service id="clusteringServiceBeanService" ref="clusteringServiceBean"
                interface="org.foo.clustering.ClusteringService" />

Spring OSGi Extender read the configuration file and export clusteringServiceBeanService as an OSGi service automatically.

Service Consumer

In the client (ClusteringServiceUser), you need to import clusteringServiceBeanService to inject the service to the client. This can be done by writing a simple enty in the XML file: 

<osgi:reference id="clusteringServiceBeanServiceRef" interface="org.foo.clustering.ClusteringService" />

Once client import the service, you can use it as a regular Spring bean. Therefore, you can inject it like: 

<bean name="clusteringServiceUserBean" class="org.bar.client.iternal.ClusteringServiceUserImpl">
    <constructor-arg ref="clusteringServiceBeanServiceRef" />
</bean>

As you can see the example above, if we use Spring DM, Cytoscape 3 code is independent from OSGi API and Spring API. This means all of the Cytoscape objects are POJOs and we can replace the framework later when necessary.

Building System

This is not actually the architecture/design issue of Cytoscape 3, but is very important to understand to develop Cytoscape 3. In Cytoscape 2, we use build tool called Apache Ant. This is fairly flexible an powerful building tool, but have some issues:

  1. Developers have to manage module dependency manually

    • Cytoscape is a fairly complex application software using lots of public libraries (JARs). This means developers have to find correct version of libraries and copy them manually to the project directory. The bad news is most library JARs depends on other libraries and you need to figure out how they are related.

  2. Need to repeat same thing again and again

    • Probably, the first thing developer do to begin Cytoscape 2 plugin development is copying build.xml file from somewhere (from your old project or other plugin code). This is because most developers follow very similar process, like compile, test, create jar, publish JavaDoc to web site, etc.

To solve these issues and time saving, we decide to use Apache Maven for official build tool for Cytoscape 3.

Convention over Configuration

The basic idea of Maven is Convention over Configuration. In most cases, Java developers follow very similar process: write code, compile, test, build JAR files, create JavaDoc, and publish it. In Maven, this model development style is defined as a convention and it is designed not to repeat the same configuration again and again. Instead of writing build.xml at the beginning of plugin development, you can start with type some maven command to create basic directory structure for your plugin. It looks like the following: 

src
test
pom.xml

Because maven creates the basic directory structure, you do not have to configure details, such as location of source code, test cases, resource files, etc.

Also, Maven 2 has a very useful feature to import dependent libraries automatically over the internet. If you want to use library A, all you have to do is adding it to the pom.xml file. Then maven finds the dependent library for you.

Please try this example to understand basic concept of Maven2.

Working with Cytoscape 3 Code

/!\ Need to update the sections below.

Introduction

In this section, you are going to learn how to write Cytoscape 3 style code in the new building system.

Create OSGi-Spring Based Project

Related Frameworks and Technologies

From 3.0, new technologies/frameworks will be used for implementation. The following is the list of links to documents related to those frameworks/technologies.

Developer's Tutorials and References

For Eclipse Users

Basic Tutorial

Optional

For Netbeans Users

Other OSGi Tools and Technical Notes

Books

Spring

Spring DM and OSGi

Maven

Tricks

Ignoring .svn in Bash Auto-completion

Because of the restructuring of Cytoscape 3, the directory structures have become deeper than Cytoscape 2. Luckily, Bash makes it easy for us to cd quickly into a deep directory structure. When I type "cd src/main", then press tab repeatedly, I'll quickly find myself in src/main/java/org/cytoscape/.

Unfortunately this doesn't work when the directories are under version control, because Bash auto-completion finds .svn as well. Since I almost never need to enter the .svn directory, Bash auto-completion doesn't allow me to quickly traverse directory structures. I must read the name of the directory I want to enter, type its first letter, type tab again, and repeat until I'm in src/main/java/org/cytoscape. This may seem like a silly complaint about saving a few seconds, but considering that I find myself wanting to quickly access a source file repeatedly throughout the day, it serves as an effective distraction when I'm focused on getting the source file.

The way to get around this is to set the FIGNORE environment variable to ".svn". Bash reads this environment variable and filters out any auto-completion results that match FIGNORE. I also use FIGNORE to filter out .class files and .pyc files (compiled Python scripts), since I almost never need to open them. In my ~/.bashrc file, I have written: 

export FIGNORE=".svn:.class:.pyc"

Searching for Classes in Javadocs

Javadocs displays classes in packages and the members of classes at a glance. However it doesn't provide any means to search for classes or members. As a substitute, I use Firefox's find command to look for a class. This is a poor substitute, because it searches all frames--meaning package names and class members as well. If I want to look up the javadocs for java.lang.String, I find myself having to hit the "Forward" button repeatedly until I find it.

I have found a script that installs a search box at the top of the list of classes/interfaces/exceptions in all javadoc pages. This means you type in the class/interface/exception name, and it'll give you a list that matches what you entered. If you press return when the search box has focus, it'll bring up the first class listed. It doesn't, unfortunately, search method names or class members.

You'll first need to install Greasemonkey (https://addons.mozilla.org/fr/firefox/addon/74), then install the Javadoc search script (http://code.google.com/p/javadoc-search-frame/). Afterwards, when you open a javadocs page, you'll see a search box above the list of classes. This is much better than using Firefox's find command.

Questions? Please e-mail me (kono_at_ucsd_edu)

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