Project Plan For Swordfish, version 1.0


The goal of the Swordfish project is to provide an extensible SOA framework based on the proven Eclipse Equinox runtime technology. The framework is designed to be complemented by additional open source components such as a service registry, a messaging system, a process engine etc. to form a comprehensive open source SOA runtime environment based on both established and emerging open standards.

Release Deliverables

  • Tooling: delivers tools to help the develepors create, test and deploy Swordfish enabled consumers and providers. Also included is a detailed documentation.
  • Runtime: delivers the core framework and exemplary implementation for the core framework's extension points to be used as target platform.

Table of Contents

Release Milestones

The Sowrdfish version 1.0 milestones and release candidates will be aligned with the release schedule of the Helios Simultaneous Release train (offset +3)
1.0 M3
1.0 M4
1.0 M5
1.0 M6
1.0 M6
1.0 RC1
1.0 RC2
1.0 RC3
1.0 RC4

The ramp down policy is the following:

With M6 we will freeze the API, no new features will be added after M7 . Starting with RC3 only bugs with severity Blocker or Critical and target milestone 1.0 may still be fixed. This has to be accompanied with a notification to the swordfish-dev list.

Table of Contents

Target Environments

Swordfish 1.0 will depend on Equinox 3.6.. The sources will be compiled against 1.6 JDK and are designed to run on 1.6 Java Runtime Environment, Standard Edition.


For Swordfish Tooling the plugins are developed following common rules about string externalization to make the internationalization possible.

Table of Contents

Compatibility with Previous Releases

The APIs are still provisional and are expected to further evolve based on the experience we get when implementing the exemplary plugins and the community feedback. Stabilization is planned after the 1.0 release

Table of Contents

Themes and Priorities

Enhanced Policy Processing

Swordfish allows to define non functional aspects of a service call in a declarative way via so called policies. Non functional aspects that may be specified in a policy may be e.g. encryption or compression of the messages. Policy processing is implemented by providing policy based message interceptors which can be pluged into the Swordfish framework invoked during message processing. A Message Interceptor is responsible for processing a message regarding one policy aspect. Currently we only have a very limited number of policy interceptor, but aim to provide exemplary interceptors for the most common policies.
  • Committed
    • Authentication interceptor (using Eclipse Higgins STS)
    • Compression interceptor (using gzip)
    • Validation interceptor (using XML Schema validation)
    • Transformation interceptor (using XSLT)
  • Proposed
    • Authorization interceptor
    • Encryption interceptor
    • Signature interceptor

Remote Swordfish Provider Deployment

Initial support for an easy deployment of Swordfish Provider to a remote OSGI Application Server from within the Eclipse IDE. This might be to a server on premise or within the Cloud.
  • Committed
    • Equinox 3.6
  • Proposed
    • SpringSource dm Server
    • Eclipse Gemini

Service Activity Monitoring (Metric data)

The current swordfish version already provides sporadic management information. We want systematically add measuring points to collect metrics and other management information and provide a unified JMX interface to retrieve the information and e.g. visualize it in a JMX enbaled management console.
  • Committed
    • Min., Avg. and Max. Response Time for three configurable time periods e.g. 5, 15, 60 min
    • Number of requests that failed due to application errors during the selected periods
    • Number of failures due to communication problems during selected periods
    • Total number of requests in the period

JMS Transport

Swordfish provides the abiltiy to change the transport binding dynamically based on a transport policy for Swordfish 1.0 we will support additionally to HTTP/HTTPs also JMS based tranport.
  • Committed
    • Apache Active MQ

Stabilizing API's

When implementing the exemplary plugins for we realized that some parts of the API need improvement to ensure to ensure that a wide variety of plugins can be implemented and make it as convenient as possible to implement the plugins. We want to take the chance to improve them before the 1.0 release in order to keep them stable after the release.

Table of Contents


Table of Contents

view raw xml of project plan
from project meta-data key "projectplanurl"