Saminda
On 11/7/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
Saminda--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Yes, this is currently possible. However I guess the expectation is to make it "simpler" to assign mediation rules that would apply to proxy services. The in/out sequences would be more valid for message level mediation. However when one creates a proxy service, it would be meaningful to target messages to either a direct endpoint, or to a sequence. Right now we allow the user to specify a target sequence for incoming messages - but out going messages *always* goes through the main rules - and this is inconsistent and cannot be customized. This would lead to a cluttered main mediator for outgoing message handling. I think once the proposed changes by Ruwan are brought in, one can select a target endpoint for a proxy service - or a target in/out sequences. If any of the sequences are not specified, it will default to the main rules (i.e. current default behavior)
asankha
Saminda Abeyruwan wrote:Hi Devs,
In a sequence for ex: we could right as follows,
<sequence name="foo">
<in>
LIST OF MEDIATORS
</in>
<out>
LIST OF MEDIATORS
</out>
</sequence>
<in/> and <out/> mediators are filters and the switch happens according to MessageContext.isResponse() property. Couldn't we use this.
Saminda
On 11/7/06, Ruwan Linton <[EMAIL PROTECTED] > wrote:Inorder to do this improvement we will need to slightly change the Synapse Configuration Language as well.. The change will be as follows;
The target element of the proxy element currently contains sequence as an attribute as follows;
<proxy name=....>
......
<target sequence="......" ......../>
</proxy>
This sequence attribute of the target element of the proxy element need to be changed to inSequence and there need to be a new attribute to the target describing the outSequence as well as follows;
<proxy name=.......>
.....
<target inSequence="......." outSequence="....." ....../>
</proxy>
Any comments abt. the names used (inSequence, outSequence)??
Ruwan.
On 11/7/06, Asankha C. Perera < [EMAIL PROTECTED]> wrote:Yes please go ahead.. if you do not get your account created in time, I could apply this as a patch.. hopefully the last :-)--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ruwan Linton wrote:yeap, thats what I mean.... So shall I go ahead an implement this???
Ruwan
On 11/7/06, Asankha C. Perera <[EMAIL PROTECTED] > wrote:Well.. currently we send all responses through the default rules,
irrespective of whether the original [co-related] request message came
in through to Synapse by way of a proxy service or not.. The proposed
solution will allow proxy services to explicitly state the incoming and
outgoing sequences to be used for mediation. If either of these are
un-specified, it should default to the main rules
asankha
Paul Fremantle wrote:
> Sounds pretty good to me!
>
> I think thats pretty much what we do with responses already?
>
> Paul
>
> On 11/6/06, Ruwan Linton <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Currently we have only one aequence for proxyservices. ie. we can say a
>> proxyservice to go through a sequence when a message recieves to the
>> ProxyServiceMessageReceiver. But when the response is came to the MR
>> it will
>> go thru the main sequence i.e. thru MainMediator. But it is better if
>> we can
>> let the user define an out sequence as well for a particular
>> proxyservice.
>>
>> I thought this can be easily done by setting an outSequence to the
>> ProxyServiceMessageReceiver instance (that we are creating at the
>> serviece
>> build time using buildAxisService method of the ProxyService class) and
>> then;
>>
>> In the ProxyServiceMessageReceiver we can check weather the message is a
>> response or not by checking the synapse MessageContext.isResponse()
>> method
>> and if so we can mediate using the outSequence that we have
>> specified.......
>>
>> Can U please comment on this.....
>>
>> Thanks,
>> Ruwan.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
