Differences between revisions 14 and 15
Revision 14 as of 2005-10-20 23:29:06
Size: 4945
Editor: 206
Revision 15 as of 2009-09-20 22:48:37
Size: 4951
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
 * [attachment:Celtix_Overview.ppt Celtix Overview Presentation]
 * [attachment:Infravio_X-broker_Overview.pdf Infravio X-broker Overview]
 * [http://people.apache.org/~chinthaka/ppt/Introducing_Axis2_22Sep2005.ppt Axis2]
 * [[attachment:Celtix_Overview.ppt|Celtix Overview Presentation]]
 * [[attachment:Infravio_X-broker_Overview.pdf|Infravio X-broker Overview]]
 * [[http://people.apache.org/~chinthaka/ppt/Introducing_Axis2_22Sep2005.ppt|Axis2]]

Notes from Synapse F2F Sept. 22nd to 24th in Cupertino, CA

Thursday, September 22nd

Today is background day - going thru Celtix, X-Broker and Axis2. The presentations discussed will be posted here soon.


Friday, September 23rd


  • Cliff Schmidt
  • Feng
  • Paul Fremantle
  • Frank Martinez
  • Davanum Srinivas
  • Jeremy Boynes
  • Glen Daniels
  • Eric Newcomer
  • Mike Greenberg
  • Wenjun Wu
  • Eran Chinthaka
  • Sanjiva Weerawaraa
  • Mukund Balasubramanium
  • Rajesh Koilpillai
  • Miko Matsumura

Discussing Features & Function

  • a messaging and communications infrastructure;
  • based on the principles of service oriented architectures;
  • that provides a way of connecting disparate systems;
  • that manages the connections and the routing of messages between systems;
  • that intermediates and transforms messages and service interactions independently of the endpoint applications;
  • that is neutral with respect to the languages and platforms that are integrated - providing first class support for C/C++/COBOL/Java/.NET and other application platforms;

Specific Mediations We'd like to Have

  • Logging and monitoring
  • XSLT transformations
  • Schema validation
  • Transparent RM
  • Content & context based routing

  • Security
  • Load balancing & failover

  • Deprecation model (versioning)
  • SLA/QoS (e.g., throttling)
  • Lightweight process management (as in like routing a message through a plan .. itineraries)


  • Provider Endpoint: The service endpoint which is being mediated.

  • Listener: A source of messages into Synapse.

  • Client: The thing that sends messages (which end up at a Listener) to Synapse to be mediated and delivered to a Provider Endpoint.

  • Mediation: The stuff that happens related to a message inside Synapse when in arrives via a Listener and until it goes out to a Provider Endpoint.

  • Mediation Component: Implementation of some mediation: i.e., some action to or related to a message. The mediation component may be composed of lots of other mediation components or be an atomic mediation component which has some specific behavior.


  • Configure a new listener
  • Configure a new endpoint
  • Configure a raw pass-thru mediation between a listener and endpoint

Core Model

There is a rule: match -> mediation component approach

Suppose I want to log every message, and then run tranform mediation on the stockquote service.

rules * -> LogMediation, QoS markers http://xmethods.net/stockquote -> StockXFormMediation, QoS markers

This could be used as a "composition" model, but that is not the primary aim. Primarily compositions happen statically inside a mediation. So for example, we may provide a BPELMediation that use BPEL syntax to compose sub-mediations. Alternatively, we may provide some logical composition components (chain, branch, tee) that can be combined to compose mediations.

However, there is some differences between using the rule model and the mediation composition mode:

1. The invocation of a Mediation component by the framework is a single thread - so multiple rule matches may operate on separate threads (e.g. above, the logging may happen on a different thread to the xform).

2. The QoS markers are only at the level of a rule. So mediation writers can do what they like inside a mediation. So if a mediation wants to launch a new AxisEngine to get the security handlers invoked it can.

3. The rule matching is inherently dynamic, whereas the mediations are more statically defined and deployed. (of course a mediation is just Java so it can do as much dynamic stuff as any other Java - reflection, classloading, etc).

Rules can be added dynamically.

In fact because the system is inherently one-way, sometimes we will automatically add a new tule that matches an async response.


We could write our own serialisation



or use Policy attachment



Another option would be to have an ASCII/LEX serialisation that transforms to/from the PolAttachment model above.

Synapse/200509F2F (last edited 2009-09-20 22:48:37 by localhost)