Skip to main content



"Swordfish" is the nickname for the SOA Runtime Framework project. It is is a proposed open source project. This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to


The goal of a service-oriented business architecture (SOA) is the loose coupling of business services. In order to enable such a service-oriented business architecture users require a SOA runtime platform. As of today, enterprise users face a number of challenges in operating these SOA runtime platforms, e.g.

  1. SOA Platforms consist of a set of internal technical services (e.g. registry, messaging, and security). Today, those technical services are strongly coupled within most of these platforms. A loose coupling of those services would allow a best of breed approach and would give the user the option to leverage existing software assets
  2. The interoperability between different SOA runtime platforms is often limited to the basic technical services (e.g. messaging). High level interoperability (e.g. business process orchestration) across SOA domains operated on different platforms is often not possible.
  3. The enablement of embedded systems collaborating in a SOA runtime environment.

The SOA platforms available today fall short to these expectations and limit the value of SOA on the user side. This project intends to address these three challenges:

  • Lack of common interfaces between the technical components of a SOA runtime platform
  • Lack of interoperability between SOA environments
  • Lack of SOA runtime deployment on embedded systems, e.g., on medical devices in the healthcare industry

Lack of common interfaces: The different SOA runtime platforms consist of very similar technical components (e.g. service registry, messaging). The lack of common APIs between these technical components means that these components cannot be exchanged. This project intends to develop a common framework/API which treats these components as exchangeable plug-ins.

Lack of interoperability: Although there are ongoing standardization efforts, the interoperability of heterogeneous SOA environments is very limited today. As an example, a BPEL code can usually not be executed across different SOA environments. Rather than introducing yet another new SOA platform, the SOA Runtime Framework introduces a new abstraction layer and allows developers to create adapters to existing SOA platforms.

Lack of SOA deployment on embedded systems: The vast majority of the currently existing SOA environments is exclusively targeted at enterprise environments and demands a considerable amount of memory and processing resources. The SOA Runtime Framework takes a different approach in that all components could potentially be replaced by alternatives with a smaller footprint which renders it equally well suited for both enterprise environments and resource-restricted embedded and mobile devices.


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

The following figure illustrates Swordfish's component architecture:

(1) Functional components and plug-ins

Swordfish defines a number of components and plug-ins:

  • Business Application Adaptor (plug-in)

    Business application adaptors connect business application logic (the actual service implementation) to the other components within the framework. A Business Application Adaptor's reponsibilities include the mapping of implementation-specific data types to normalized XML messages and the correlation of incoming and outgoing messages. A sample implementation of an Business Application Adapter delivered along with the framework provides an easy-to-use Java API to facilitate the integration of business logic.
    In addition to that, an open source BPEL engine will be integrated into the framework as another example of a Business Application Adaptor.

  • Service Resolver (plug-in)

    The Service Resolver is reponsible for resolving logical service references into physically addressable communication endpoints. The revolving process can take additional metadata (e.g. policies) into account, depending on the desired strategy. A sample implementation delivered as part of the framework uses a file system-based data store to retrieve service information. Another possible implementation resolves service references based on information stored in a UDDI registry.

  • Security Manager (core component & plug-in)

    The Security Manager is responsible for coordinating and supervising security-related tasks such as authentication, authorization, data confidnetiality and integrity protection within the framework.

  • Message Dispatcher (core component)

    The Message Dispatcher is responsible for decoupling message processing being performed inside the Message Processor from the Transport Bindings. The interfaces exposed by the Message Dispatcher are defined by the JBI standard.

  • Transport Bindings (plug-in)

    Transport Bindings are reponsible for a) transforming messages from the canonical representation used within the framework into transport and protocol specific formats and b) communicating with remote source and target systems. The interface provided by the framework for integrating Transport Bindings is defined by the JBI standard. Sample implementations delivered along with the framework support SOAP over HTTP and SOAP over JMS.

  • Message Processor (core component)

    The Message Processor is responsible for coordinating message processing between Business Application Adapters and Transport Bindings. The actual processing is performed within a chain of pluggable Interceptor components. The assembly of the processing chain and the order of execution is controlled by an interchangeable Planner component. A sample implementation of a Planner that is provided as part of the framework evaluates policies in WS-Policy format.

  • Message Interceptors (plug-in)

    A Message Interceptor is responsible for processing a message regarding (ideally exactly) one functional aspect such as transformation, validation or compression. Message Interceptors can be assembled into a chain to jointly perform more complex tasks. The interface that Message Interceptors have to implement will be defined within this project and serves as a public extension point of the framework.

  • Management/Monitoring (core component & plug-in)

    The Management/Monitoring component is responsible for recording and processing relevant events within the framework and provides management interfaces for monitoring and controlling the framework's components remotely. A sample implementation provided along with the framework is based on the JMX standard.

  • Configuration (core component & plug-in)

    The Configuration component provides configuration data to all other components of the framework in a unified way. A sample implementation that is delivered as part of the framework takes configuration data from filesystem-based storage. Another possible implementation retrieves configuration data from a remote respository.

In addition to that, the SOA Runtime Framework provides a deployment mechanism that supports run-time deployment of components based on artefacts generated by SOA design tools (e.g. by the Eclipse SOA Tools Platform).

(2) Foundation on OSGi

The foundation on OSGi is a prerequisite of the SOA Runtime Framework due to the following reasons. The OSGi Framework provides a mature and proven component lifecycle model with an underlying security concept and a fine-grained isolated class loading scheme which makes it an excellent choice for the technical foundation of the SOA Runtime Framework. In addition to that, OSGi’s notion of a dynamically deployable bundle as a higher level unit of modularization allows for the flexibility that is necessary to support the SOA Runtime Framework’s deployment model. Apart from these technical aspects, adopting OSGi as the SOA Runtime Framework’s future technical base architecture has a number of additional advantages, including

  • Seamless integration into the Eclipse ecosystem,
  • Potentially more straight-forward integration into future enterprise runtime environments such as applications servers, and
  • The opportunity to extend the reach of the SOA Runtime Framework into the embedded and mobile devices market.

(3) Support existing SOA standards

It is the intention that the SOA Runtime Framework will support all available major existing SOA standards and be flexible enough to react to future standard work. As of today, the Service Component Architecture (SCA) and Java Business Integration (JBI) are planned to be supported.

  • Service Component Architecture (SCA): SCA describes a model for building applications and systems using a service-oriented and component-based architecture. The SOA Runtime Framework will be designed to act as an SCA runtime implementation that is able to execute SCA applications built, for example, with the development tools created by the Eclipse SOA Tools Project. The SOA Runtime Framework intends to provide a framework for the consumption of existing SCA runtime implementations, for example Tuscany and Fabric3.
  • Java Business Integration (JBI): JBI describes Java standard interfaces for normalized message mediation between service components within a Java VM, along with a corresponding component lifecycle model and management facilities. Out of these, the normalized messaging concept is especially valuable to allow for protocol and transport abstraction. Based on OSGi as the underlying component model, the intention of the SOA Runtime Framework project is to provide a JBI 2.0-compliant implementation.


Project Management

The SOA Runtime Framework project is overseen by a project lead.
  • Oliver Wolf (Sopera): Project lead

Initial committers and contributors

The initial committers will focus on (a) making the contributed code OSGi based, (b) providing framework APIs, and (c) submitting patches and further code contributions. Our agile development process will follow's standards for openness and transparency. As such we will actively encourage contributions to this project. The initial committers and contributors are:

  • Klaus Kiehne (DPWN): Lead Architect & Committer
  • James Strachan (IONA): Architect & Committer
  • Guillaume Nodet (IONA): Committer
  • Zsolt Beothy-Elo (Sopera): Contributor
  • Gerald Preissler (Sopera): Contributor
  • Dietmar Wolz (Sopera): Contributor
  • Anubhav Sharma (Sopera): Contributor
  • Andreas Mattes (Sopera): Contributor
  • Ramtin Mesbahipour (Individual): Contributor
  • Adrian Co (Individual): Contributor
  • Jonas Lim (Individual): Contributor
  • Torsten Reimers (SoftQuadrat): Contributor
  • Jörg Drescher (Sopera): QA
  • Georg Voutsinos (Sopera): QA
  • Carsten Biermann (Sopera): Build


  • Oisín Hurley (IONA): STP PMC Member and Member of the Architecture Council
  • Jochen Krause (innoopract): WTP PMC Member

Potential Consumers

Potential consumers of the SOA Runtime Framework within the Eclipse Foundation include the ALF, SOA Tools, EclipseLink and the OSEE projects. Potential non-Eclipse consumers include Deutsche Post World Net (DPWN), Senacor, SoftQuadrat GmbH.

Code Contribution

Deutsche Post World Net (DPWN) will contribute its custom-developed SOA platform into this project. The contributed code contains the initial code representing the framework, a messaging plug-in, a service discovery plug-in and a management plug-in.

The contributed code of Deutsche Post World Net is not based on OSGi. One of the first project tasks will be an adoption of the code to deliver an OSGi-based runtime component which enables the implementation of OSGi-based service providers and consumers. The DPWN contact person for the Eclipse Community will be Klaus Kiehne (Deutsche Post World Net).

Related projects

The following related projects which require future alignment:

  • SOA Tool Platform (STP): The major phase of the SOA Lifecycle Management are “Planning”, “Design”, “Implementation”, “Deployment”, “Operations” and “Support”, The STP aims the earlier phases of the SOA lifecycle – “Planning”, “Design” and “Implementation”. In contrast the SOA Runtime Framework project aims the later phases “Operations” and “Support”.  It is general consensus that STP and Swordfish complement each other. More specifially, the deployment framework  developed as part of the STP effort  will be crucial for successfully using Swordfish in productive environments.
  • Equinox: Swordfish relies heavily on OSGi as the underlying component architecture. Advancements in OSGi standardization and implementation -- especially regarding results of the OSGi Enterprise Expert Group -- are expected to require frequent alignment with Equinox
  • Corona: The Corona project also aims at defining a Service Runtime Framework, but concentrates on tool integration rather that general SOA applications. It is anticipated that Corona could benefit from adopting Swordfish as the underlying SOA runtime framework in the future.
  • Higgins – The Trust Framework: The Higgins project is developing an extensible, platform-independent, identity protocol-independent, software framework to support existing and new applications that give users more convenience, privacy and control over their identity information. Higgins should be considered as a preferred candidate for a potential security and identity framework for Swordfish.

Tentative Plan

Assuming a start of the incubation phase in August 2007 the following milestones are planned:

Milestone Version Deliverable/Scope
October 2007 v0.5 Basic framework
February 2008 v0.7 All examply plug-ins
July 2008 v0.9 BPEL plug-in
October 2008 v1.0 SCA compliant deployment mechanism


The future server-side extension of OSGi (e.g. enterprise deployment and distributed execution container) should be leveraged after v1.0 as soon as a first open source implementation is available.

Back to the top