Saminda
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 :-)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
