synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Require <engage-addressing-in/>?
Date Thu, 12 Jan 2006 16:09:10 GMT
Why does Synapse require users to have <engage-addressing-in/> in their
config? Synapse should sort this out automatically.

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).

   ...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
>

Mime
View raw message