incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Incubator Wiki] Update of "Synapse/InProgress/Features and Design" by Asankha Perera
Date Wed, 07 Jun 2006 03:51:13 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The following page has been changed by Asankha Perera:

New page:
= Summary of features currently in plan for a 1.0 release.. =

||||||||||Synapse 1.0 - Target August 15th ||
||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             || asankha || ||
||2  ||4  ||Package Synapse as an Axis2 Module (MAR)   || saminda || Done ||
||4  ||4  ||Fault handling (and optionally hierarchy)  || ?||  ||
||3  ||4  ||Support for config import mechanism        || ?|| Paul to design ||
||1  ||4  ||Callout mediator (Synchronous-blocking)    || ?|| A sample showing how this could
be done||
||3  ||4  ||Javascript/E4X support                     || Ant? || ||
||||||||||Nice to have features||
||2  ||3  ||Load balanced (round-robin) send           || ?||  ||
||2  ||3  ||Failover send                              || ?||  ||
||4  ||4  ||Time based filter                          || ?||  ||
||4  ||4  ||Identity based filter                      || ?||  ||
||3  ||3  ||Collection and exposing statistics         || ?||  ||
||3  ||4  ||Support for integration with a Registry    || ?||  ||

== 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

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

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

== 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
               (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

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.)

    <endpoint name="invesbot" address="" useRM="true">
	    <parameter name="OutflowSecurity">

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message