synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <chinth...@opensource.lk>
Subject Re: Require <engage-addressing-in/>?
Date Mon, 16 Jan 2006 17:36:38 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 


ant elder wrote:

> So this sets the global default of whether or not to use addressing
> on outgoing messages doesn't it?

Nope. If you set this to MessageContext, this is per message. Likewise
it depends on where you set this. If you want to make this global, set
this in ConfigContext.

> Thats useful but doesn't Synapse also need to be able to set this
> for individual messages? And to say what version of addressing to
> use?

You can set anyContext.setProperty(WS_ADDRESSING_VERSION,
WSAVersionNSURI). For example,
msgContext.setProperty(WS_ADDRESSING_VERSION,
"http://www.w3.org/2005/08/addressing") will set the addressing
2005/08 version for *this* OUT message.

- -- Chinthaka


>
> ...ant
>
> On 1/16/06, Saminda Abeyruwan <samindaa@gmail.com> wrote:
>
>> Hi,
>>
>> Please see my comment below. Thank you.
>>
>> On 1/12/06, ant elder <ant.elder@gmail.com> wrote:
>>
>>> Why does Synapse require users to have <engage-addressing-in/>
>>> in their config? Synapse should sort this out automatically.
>>
>>
>> Please see commit message r365848.
>>
>> All <engage-addressing-in/> does is set things up so that the
>> SynapseMessage
>>
>>> WSA getters/setters work correctly, it doesn't actually do
>>> anything to the message.
>>>
>>> If a mediator calls SynapseMessage.getTo without first engaging
>>> addressing then null will be returned whether or not there is
>>> any WSA header . If a mediator calls setTo and then later in
>>> the config addressing is engaged then what the previous
>>> mediator set will get overwritten. What if a mediator sets a
>>> WSA header and then another mediator wants to get a different
>>> header? - You must have <engage-addressing-in/> before both of
>>> these mediators for this to work correctly.
>>
>>
>>
>>
>> All that seems messy and error prone. A user should be able to
>> write a
>>
>>> mediator that uses WSA headers without having to think about
>>> the order of other mediators or what else is in the config .
>>
>>
>>
>>
>> We can fix this by having Synapse do the engage addressing
>> processing
>>
>>> automatically the first time any of the SynapseMessage WSA
>>> getters/setters are called. And it simplifies the Synapse
>>> config XML.
>>>
>>> Outbound WSA headers are a different story, it does seem
>>> reasonable to have something like <engage-addressing-out/> or a
>>> WSA-Required property on the Send mediator so that a user can
>>> control if the outgoing message includes the WSA headers (and
>>> what WSA version).
>>
>>
>> I agree. If you look at prior commit messages and if you run
>> through the code in Axis2Sender.send(), setting the property in
>> SynapseEnvironement (
>> org.apache.synapse.Constants.ADDRESSING_PROCESSED, Boolean.True)
>> only enage AddresingOutHandler for outbound messages. This is
>> possible because of setting
>>
>> mc.setProperty(
>>
org.apache.axis2.Constants.Configuration.DISABLE_ADDRESSING_FOR_OUT_MESSAGES
>> , Boolean.TRUE); to switch on/off between AddressingOutHandler.
>> This all available in commit 365848. Please be kind enough to
>> read the commit message.
>>
>> Saminda
>>
>>
>> ...ant
>>
>>> On 1/6/06, Paul Fremantle <pzfreo@gmail.com > wrote:
>>>
>>>> Ant
>>>>
>>>> My only concern is that I think Synapse will be more useable
>>>> if the semantics of any flow are visible. Which means not
>>>> running addressing unless its told to.
>>>>
>>>> Paul
>>>>
>>>> On 1/6/06, ant elder <ant.elder@gmail.com> wrote:
>>>>
>>>>> The benefit is not forcing everyone to nearly always put
>>>>> <engage-addressing-in/> in their synapse.xml
>>>>>
>>>>> The requirements are:
>>>>>
>>>>> 1) Some mediators require addressing headers, some don't 2)
>>>>> Some mediators require addressing headers but aren't
>>>>> invoked through an AxisEngine 3) Don't want addressing
>>>>> module to run multiple times due to overwriting altered
>>>>> headers 4) Sometimes addressing headers aren't required at
>>>>> all so don't want addressing module run (for performance?)
>>>>>
>>>>> So the current solution is:
>>>>>
>>>>> A) Require explicit addressing when and where required in
>>>>> synapse.xml
>>>>>
>>>>> But there are other solutions:
>>>>>
>>>>> B) Synapse by default always calls addressing at start for
>>>>> every message. Optional <dont-engage-addressing/> for (4)
>>>>>
>>>>> C) Have a way for mediators to indicate they require
>>>>> addressing so Synapse can engage the module when required.
>>>>> And Synapse knows if it was already engaged for a previous
>>>>> mediator so only engages it once. (Or have the Axis2
>>>>> addressing code itself see its already run so doesn't need
>>>>> to again)
>>>>>
>>>>> Maybe I don't understand the Axis2 module stuff properly,
>>>>> but is there also:
>>>>>
>>>>> D) Iff a Mediator calls one of the WSA getter's/setters on
>>>>> SynapseMessage then if it hasn't already the addressing
>>>>> code gets run to populate the fields
>>>>>
>>>>> Surely (4) isn't so common, all of Synapse samples use
>>>>> addressing. So isn't (B) more appropriate than (A) for now,
>>>>> and look at (C) or (D) for later?
>>>>>
>>>>> ...ant
>>>>>
>>>>> On 1/6/06, Paul Fremantle <pzfreo@gmail.com > wrote:
>>>>>
>>>>>> Ant
>>>>>>
>>>>>> I don't agree that synapse should always do addressing.
>>>>>> Firstly, if we have addressing engaged and we make
>>>>>> multiple passes through Axis then it overwrites the
>>>>>> To/From/etc properties in the SynapseMessage every time.
>>>>>> Secondly, I don't agree that we always want to parse
>>>>>> those headers. In fact we decided at the very first F2F
>>>>>> not to.
>>>>>>
>>>>>> We started out making every mediator a pass through Axis2
>>>>>> for a specific benefit - QoS. However, we now have an
>>>>>> alternative model to get those QoSs (the
>>>>>> emptymessagereceiver) and I don't see the benefit. I
>>>>>> think there is a clearer model between Axis2 and Synapse
>>>>>> if we only call back into Axis2 when we need a specific
>>>>>> Axis2 service.
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> On 1/6/06, ant elder < ant.elder@gmail.com> wrote:
>>>>>>
>>>>>>> Is the ClassMediator really needed?
>>>>>>>
>>>>>>> In yesterdays IRC chat there was some discussion about
>>>>>>> mediators being Axis2 services vs. the ClassMediator
>>>>>>> which calls a Java class directly without going through
>>>>>>> an Axis engine. It was said the ClassMediator is easier
>>>>>>> to use as you don't need a service xml and is faster.
>>>>>>>
>>>>>>> Are these the only reasons for having the
>>>>>>> ClassMediator? Wouldn't having Synapse auto-deploy to
>>>>>>> Axis2 (as Glen suggested) fix the complexity problem,
>>>>>>> and if it really is so slow going through an empty
>>>>>>> AxisEngine shouldn't we try to get the Axis2 guys to
>>>>>>> fix that instead of us just not using Axis? Surely a
>>>>>>> pass through an empty engine should just be a few empty
>>>>>>> loops and a bunch of if statements which shouldn't add
>>>>>>> so much overhead?
>>>>>>>
>>>>>>> One thing this would help with is with the addressing
>>>>>>> stuff. i don't really like having
>>>>>>> <engage-addressing-in/> explicitly in the Synapse XML.
>>>>>>> Shouldn't Synapse just know when addressing is
>>>>>>> required? If you have a Mediator the routes based on a
>>>>>>> WSA header then if the mediator was an Axis2 service
>>>>>>> the addressing stuff could be engaged automatically on
>>>>>>> the pass through the engine.
>>>>>>>
>>>>>>> ...ant
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC
>>>>>> Co-chair
>>>>>>
>>>>>> http://bloglines.com/blog/paulfremantle paul@wso2.com
>>>>>>
>>>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>>>
>>>>>
>>>>
>>>> -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC
>>>> Co-chair
>>>>
>>>> http://bloglines.com/blog/paulfremantle paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
 
iD8DBQFDy9mmjON2uBzUhh8RAulGAJ4+XpBCK39tQpdBzC8+IUMcCFQ2rwCcCgJT
qCuZcp4+mdpxMi+H1G4YFMo=
=gjYT
-----END PGP SIGNATURE-----


Mime
View raw message