synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <>
Subject Re: WSRM handling
Date Fri, 05 May 2006 14:09:14 GMT
Hi Paul,

Here are some of my thoughts about this.

When we support RM from Synapse IMHO we need to support all the three scenarios.  It should
have the full capabilities of an RM Endpoint if we decided to support RM.

The major hurdle that I find in the architecture is the lack of Queuing. It is true that Axis2
can pause the messages but there should be some thread keeping track of this paused message
and since we are inside a container we always have the limitation from the container's thread
models. I tested this scenario and found that it quickly exhaust the container's thread pool.

Scalability requirement of synapse is very high and we should go for a model where the incoming
messages does not cause limitations to the performance. IMHO a standalone server (Standalone
Synapse Server) with front end queue will provide this capability and then we can easily handle
these QoSs. I even tested this scenario and found that it does not load the container in the
case of Asynchronous Invocations. (I used Axis servlet just to inject messages to a broker(Naradabroker  and Synapse "pulls" the messages from a Queue instead of
getting invoked.)

Any thoughts?


  ----- Original Message ----- 
  From: Paul Fremantle 
  Sent: Friday, May 05, 2006 7:56 AM
  Subject: WSRM handling

  I'd like to start a discussion on handling WSRM in Synapse.

  There are three aspects:

  1. passthrough. In this model the sequence is from one endpoint to the other, and Synapse
doesn't really get involved. 
  2. Synapse as an RM client. The message comes into Synapse, maybe over JMS or SMTP. We send
it on with a sequence. Synapse is acting as an RM client (probably two-way).
  3. Synapse is acting as an RM server and passing messages on without RM, perhaps to a "pre-RM"
SOAP server, or via JMS. 

  1 isn't very interesting to us, tho we could do some special logging.
  2 should be fairly straightforward. We need to be able to configure some aspects of the
RM infrastructure - timeouts, the assignment of messages to sequences etc. I will propose
a config model and syntax for this. 
  3 is a little tricky. The problem comes with "in-order" delivery. If this is enabled then
synapse may need to hold up further processing of this  message until earlier messages have
been delivered. Sandesha can take care of the "holding up", but we have no way currently of
pausing a mediator or re-injecting a message partway through a mediator chain. 

  There are a few solutions to this I can think of:
  A) Don't support inorder delivery - at least to start with. I think this might be a worthwhile
first step, but it isn't a good long term solution as in-order is one of the main requirements
people have for RM. 
  B) Add pausing or re-injection into Synapse. This would be some re-architecture. My main
issue with this is that this is already built into Axis2 so I'm not keen on re-building it
in Synapse as well if we can re-use the Axis2 capability instead. 
  C) This is a limited proposal but might be a reasonable model to start with. The idea is
to split processing into two halves. The first half happens before RM "delivery" (i.e. before
the inorder constraint is applied). The second half takes place after delivery. A simple syntax
to handle this might look like: 

     <reliableTerminate> <!-- i.e. we are terminating the RM connection in Synapse
and passing on without RM -->
            mediators here
     <mediator...> Any mediators here get called post delivery </med>


  Paul Fremantle
  VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

  "Oxygenating the Web Service Platform",

View raw message