Differences between revisions 5 and 6
Revision 5 as of 2006-12-07 12:21:48
Size: 7955
Comment:
Revision 6 as of 2009-09-20 23:06:31
Size: 7955
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

*** Attn: This document is DEPRECATED Check http://incubator.apache.org/synapse/ for updated information ***

Summary of features currently in plan for a 1.0 release..

Synapse 1.0

Priority (1~5)

Difficulty (1~5)

Feature

Owner

Status

1

1

Proxy Services/WSDL Mediation

asankha

supports simple proxy services. Policy support available on Synapse, but Axis2/Neethi must be extended to turn on RM/Sec etc through policies attached to WSDL. Need to support JMS/REST Proxy services

1

1

Security/RM initi/termin-ation

Saminda/Asankha

In Progress

2

4

Package Synapse as an Axis2 Module (MAR)

Saminda

Done

4

4

Fault handling (and optionally hierarchy)

Asankha

Done

3

4

Support for config import mechanism

Paul

In discussion

3

4

Support for a basic registry

Asankha

Done

3

4

Javascript/E4X support

Ant

Done

4

4

Cleaned up doc, real samples, usability

?

Need more (new) samples and replace ones which refered to invesbot

Nice to have features

2

3

Load balanced (round-robin) send

?

2

3

Failover send

?

3

3

Collection and exposing statistics

?

3

4

Support for integration with a Registry

Paul

In discussion

1

4

Callout mediator (Synchronous-blocking)

?

A sample showing how this could be done

Design

Proxy Services

A proxy service creates an actual service implementation on the underlying Axis2 instance, using a specified WSDL and any policies. This allows an existing service to be virtually hosted "on" Synapse, using possibly different semantics, such as WS-Security, WS-RM, Different transports etc. A proxy service is set to a custom Proxy message receiver, which would handover the messages received to a named sequence of Synapse, to the default 'main' sequence, or to an endpoint as a direct passthrough.

Axis2 will be configured to use an additional custom dispatcher for message dispatching, and this will be used to trap all messages not dispatched to any hosted service (Axis2 service or Proxy service). These messages will be passed through the Synapse default mediation rules. If a message was dispatched to an Axis2 service, Synapse will not intercept it. Messages dispatched to Proxy services are received by Synapse, through the custom Synapse message receiver used in the definition of the services. A proxy service could perform the following actions on receipt of a message.

  • Use a named sequence for message mediation
  • Use the default main mediator for message mediation
  • Use endpoint specified and perform a direct passthrough

As a proxy service is a real Axis2 service, Axis2 should enforce any policies defined on the service. This would require some enhancements to Axis2/Neethi to allow WS-Security and WS-RM to be enabled through the WSDL. Thus an WS-RM enabled proxy service would be able to support RM, and a WS-Sec enabled proxy service would handover a message into Synapse only on the incoming message meeting the stated WS-Sec requirements.

As a Proxy service creates a virtual service with a defined WSDL and policy for the processing of messages, on behalf of a real service, the real service implementation may hence be on a different transport, or even a JMS, REST etc. service, different from that defined as its proxy.

All incoming messages on the Axis2 engine are routed through the custom dispatcher, which checks the URI against the known services currently hosted. If a match is found, it is handed over to the applicable service, which maybe a proxy service defined by the Synapse configuration. If the message is not handled by any service, the message is dispatched to the Synapse Service, which applies the default set of rules specified as the ’main’ mediator on the Synapse configuration.

When an incoming message is received by a proxy service implementation, it performs the mediations specified by a named sequence attached as the default mediation sequence for the proxy service. This mediation sequence can now decide on the real service endpoint to which the proxy service should forward the message. It could optionally perform transformation on the message, validate against a schema, or perform custom checks and lookups for message enrichment and/or verification and perform transport switching on forward. (i.e. The actual endpoint may be JMS/REST etc)

Endpoints

An endpoint creates a reusable configuration definition which could be specified as the EPR by a Send mediator. An endpoint simplifies the notion of transport level switching and WS-RM/Sec enabling on messages destined for the endpoint.

An endpoint performs the following functions

  • Defines a reusable named endpoint, which resolves to an absolute EPR at runtime
  • Allow specification of WS-Security and WS-RM specifics for messages destined to the endpoint.
  • Report statistics on messages sent, failures etc. for messages sent to an endpoint (in future)

WS-Sec/RM Termination

WS-Sec and WS-RM termination would be made possible on Synapse through Proxy services. Existing non-RM/Sec services could be exposed with RM/Security turned on, as proxy services hosted on Synapse. It would be possible to specify service level policies for proxy services initially (for Synapse 1.0).

  • client --> Proxy Service (is a real Axis2 service) --> Normal mediation through Synapse

    • (Policies specify WS-Sec/WS-RM requirements)

As per the above scenario, ?wsdl and ?policy on the proxy service by the clients would specify the applicable policy for the service, during runtime. The Proxy service will then pass messages received for mediation to Synapse *only* if WS-Sec and WS-RM requirements are satisfied. (i.e. a WS-Sec error would result in Rampart sending an error message to the client directly)

**Dependency** This feature is dependent on the level of support that the underlying policy implementation provides, and hence would require updates to Apache Neethi/Axis to provide the required level of support. Currently WS-Sec and WS-RM cannot be turned on with a policy specification.

Note: For message level mediation, if RM/Sec is required, the special 'Synapse' service would be configured to use Rampart/Sandesha. This would initially be experimental - and exposed upon satisfactory testing on real world scenarios.

WS-Sec/RM Initiation

To support the case where a non-WS-Sec/RM client requires to consume a WS-Sec/RM service through Synapse, Synapse would allow the specification of the applicable Rampart and Sandesha configurations to be specified on the Synapse Endpoint level.

Thus Synapse would allow Endpoints to define Rampart "OutflowSecurity" configurations and Sandesha configurations. Thus reusable security/RM/endpoint configurations could be referenced by mediators within Synapse rules. It would also be possible the define "OutflowSecurity", or request RM on the Send mediator itself if required, inline. Note: As Synapse would perform 'message mediation' turning on RM implies that the current message would always be sent within an RM sequence. (i.e. If the current message does not already belong to a RM sequence, a new sequence would be created and used, and then closed, as Synapse is stateless.)

e.g.

  • <endpoint name="invesbot" address="http://ws.invesbot.com/stockquotes.asmx" useRM="true">

    • <parameter name="OutflowSecurity">

      • <action>

        • <items>Encrypt</items> <encryptionUser>service</encryptionUser> <encryptionPropFile>client.properties</encryptionPropFile>

        </action>

      </parameter>

    </endpoint>

Synapse/InProgress/Features_and_Design (last edited 2009-09-20 23:06:31 by localhost)