"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 http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.soa.
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.
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: 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:
Swordfish defines a number of components and plug-ins:
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.
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.
The Security Manager is responsible for coordinating and supervising security-related tasks such as authentication, authorization, data confidnetiality and integrity protection within the framework.
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 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.
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.
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.
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.
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).
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
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.
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 eclipse.org's standards for openness and transparency. As such we will actively encourage contributions to this project. The initial committers and contributors are:
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.
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).
The following related projects which require future alignment:
Assuming a start of the incubation phase in August 2007 the following milestones are planned:
|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