Last weeks chat

[Paul Fremantle <pz...@gmail.com>]

Did anyone log last week's IRC chat?

Paul

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

Re: Last weeks chat

[Paul Fremantle <pz...@gmail.com>]

Thanks!!!!

On 5/1/06, ant elder <an...@gmail.com> wrote:
>
> Not sure what I missed at the beginning but here's what I have:
>
> Session Start: Thu Apr 27 13:29:56 2006
> Session Ident: #apache-synapse
> * Now talking in #apache-synapse
> * ant_away is now known as ant_
> <ant_> hi, sorry so late
> <paulfremantle> you arent
> <paulfremantle> your early
> <paulfremantle> but we are adjusting the start time
> <ant_> oh. what is the start time?
> <paulfremantle> it was 1pm GMT
> <paulfremantle> next week will be 1pm BST
> <gdaniels> or 8AM Eastern
> <gdaniels> or 5AM Pacific
> <gdaniels> or 7PM Sri Lanka
> <paulfremantle> this week we are halfway :-)
> <gdaniels> ... the chatbot was a bit confused ;)
> <Deepal> :)
> * Hariharasudhan has joined #apache-synapse
> * Looking up Hariharasudhan user info...
> <Deepal> shall we start ?
> <paulfremantle> lets
> <ant_> ok
> <paulfremantle>
> http://wiki.apache.org/incubator/Synapse/SynapseConfigurationLanguage
> <paulfremantle> is the discussion point
> <asankha> didnt get many comments through the mailing list.. so hope we
> could talk about it now.. :)
> <paulfremantle> well overall I'm +1
> <paulfremantle> i think its pretty good
> <paulfremantle> i'll start nit picking in a minute :)
> <ant_> me too, its more clean and tidy than the old approach
> * Hariharasudhan has left #apache-synapse
> <Deepal> Asanka can u pls explain to us bit abt that
> <Deepal> then we can easily follow the doc
> <gdaniels> I don't see anything in here about extensibility/new mediators
> <paulfremantle> class
> <gdaniels> hm
> <ant_> so the list under 'mediators' (send, drop, log, etc) is the
> conclusive list, you can't add to that?
> <gdaniels> I'd like something along the lines of <mediator qname="ns:name"
> class="factoryClass"/>
> <gdaniels> then <ns:name><config.../></ns:name>
> <gdaniels> that way you can extend the "nice looking" set :)
> <paulfremantle> you can already
> <paulfremantle> create a mediatorfactory
> <gdaniels> ?
> <paulfremantle> and package it as a JAR
> <paulfremantle> and it gets auto registered
> <gdaniels> is that in here somewhere?
> <gdaniels> that's totally cool with me if so
> <Deepal> I did not see that in the doc
> <gdaniels> drop it in repo/mediators
> <Deepal> +1
> <paulfremantle> its described in
> http://wiki.apache.org/incubator/Synapse/Architecture
> <paulfremantle> The XML configuration model (see package
> org.apache.synapse.xml) is independent of the mediator model. The XML
> configuration model is based on an xml.MediatorFactory, which simply takes
> an XML tree and creates a mediator object. This is done recursively until
> the tree is built. The Java2 JAR file service provider model (see [WWW]
> http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider)
> is used to automatica
> <paulfremantle> we could do the "repo/mediators" - that would be another
> approach
> <gdaniels> "done recursively"... that's really up to your mediatorFactory,
> right?
> <paulfremantle> yes of course
> <paulfremantle> that only really applies to the "grouping" mediators
> <paulfremantle> leaf nodes dont recurse
> <Deepal> btw I might missing some thing why do we want mediatorFactory
> <paulfremantle> mediatorfactory is only if you want to extend the XML
> syntax
> <paulfremantle> its not required
> <Deepal> oh , thx
> <gdaniels> well, it's still the way things work even for the base config,
> right?
> <paulfremantle> yes - except if you just want to new up mediators by hand
> <Deepal> hmm
> <ant_> just so I'm clear, so it is possible to have:
> <ant_> <class name="org.apache.syanpse.RhinoInvoker ">
> <Deepal> you mean we have to do addition steps  , if we are going to hand
> create a new mediators
> <ant_>     <property name="scriptFile" value="MyScript.js"/>
> <ant_> </class>
> <paulfremantle> yes thats possible ant
> <ant_> or else with a mediator factory:
> <ant_> <script scriptFile="MyScript.js"/>
> <paulfremantle> exactly
> <ant_> ok cool
> <asankha> ant: on your question.. do you think we should have any other
> main mediators?
> <ant_> if its extensible like this it sounds fine. More could get added as
> they come up
> <gdaniels> so <send>...
> <gdaniels> how does that decide where to send the message?
> <asankha> if its just <send/> it will pick it from the current message
> <gdaniels> how exactly?  wsa:To?
> <paulfremantle> well to be precise
> <paulfremantle> synapseMessage.getTo()
> <gdaniels> I'm just trying to figure out how to use this to send a fault
> back to the client if a security check on the request fails, for instance.
> In this case I want the replyTo.
> <paulfremantle> ah true
> <paulfremantle> but that is taken care of
> <asankha> when you make a fault, the fault mediator would do that for
> you..
> <Deepal> so it will take was:faultTo
> <Deepal> ?
> <Deepal> as to
> <gdaniels> I don't think that totally works
> <gdaniels> there are some cases where you want to send a fault ONWARDS and
> other cases where you want to send it BACK
> <paulfremantle> interesting point
> <Deepal> ya
> <gdaniels> I think we need a clearer architecture for deciding which
> "virtual place" to send messages to
> <Deepal> hmm , how Axis2 handle this ?
> <paulfremantle> yes we have a "response" flag on the message
> <Deepal> i mean when there is faultTo
> <asankha> if a faultto: is available, cant we use it, else the replyto:?
> <gdaniels> I think Axis2 deals fine with faultTo
> <saminda> with faultto can't we handle Glens' scenarios?
> <paulfremantle> on the synapse message we have
> <Deepal> paul : why do we keep response flag in message
> <paulfremantle> isresponse and isfaultresponse
> <paulfremantle> seems like we dont have the idea it could be a onwards
> fault
> <saminda> it's how we decide is the message sendon or sendback
> <paulfremantle> yes
> <Deepal> if we have faultTo we dont need to send any thing back
> <Deepal> to the client
> <saminda> I think Synapse should support fault Onwards and back
> <asankha> so an onwards fault may be to something other than faulto or
> replyto?
> <Deepal> can we use replyTo send the fault ?
> <gdaniels> well let's consider the scenario here
> <Deepal> if we found a fault and we dont have a faultTo , then we have to
> send the fault to client
> <gdaniels> client -> synapse -> server
> <gdaniels> client sends request
> <gdaniels> goes through just fine
> <gdaniels> server sends response
> <gdaniels> response goes through Synapse and produces a problem of some
> kind
> <gdaniels> then we want to send a fault to the client
> <gdaniels> (since there's probably no way to send it to the server anyway)
> <asankha> does the server specify faultto: to the client?
> <gdaniels> so this is a "fault onwards" scenario
> <saminda> yes
> <gdaniels> asankha: nope
> <gdaniels> no need to, why would it?
> <gdaniels> it thinks it's sending the response to the "client"
> <gdaniels> everyone ok with that scenario?
> <paulfremantle> sure
> <asankha> yes
> <gdaniels> so Synapse has the MEP context somewhere, right?
> <gdaniels> otherwise it couldn't reply to the right place
> <paulfremantle> synapse knows this is a response
> <gdaniels> and where to send it
> <paulfremantle> yep
> <saminda> yes
> <gdaniels> ok, so who makes this decision then?
> <gdaniels> the fault mediator?
> <gdaniels> I guess maybe we should figure out what kind of fault we're
> talking about here to make this clearer
> <asankha> glen: from the servers point of view.. synapse is acting on
> behalf of the client.. maybe synapse found a validation error in the
> response.. so sending this fault back to the server would be correct.. isnt
> it? i mean unless a fault to is specified..
> <Deepal> how does synasep determine whether it is a fault or not
> <Deepal> ooops sorry :)
> <gdaniels> asankha: sure, but even in that case we want to send a fault
> back to the client as well, right?
> <asankha> you mean to both?
> <gdaniels> perhaps, yes
> <paulfremantle> then that would be a new directive to "create a new
> message"
> <asankha> the proposed fault mediator doesnt actually send the message..
> just transforms the current message into a fault message..
> <paulfremantle> exactly
> <asankha> then you could call the send mediator with two endpoints and
> send the fault to both
> <gdaniels> although you might want different faults
> <asankha> hmm ..even thats possible.. but you will then have to define it
> in the configuration that way...
> <gdaniels> I'm not sure about the whole "transforms the current message"
> thing
> <gdaniels> first off, it's "replaces" not "transforms"
> <paulfremantle> yep
> <gdaniels> and second, wouldn't that default to "send fault onwards"
> instead of "send fault back"?
> <gdaniels> typically "send fault back" is what we want, "onwards" will be
> rare, I think
> * sanjiva has joined #apache-synapse
> <gdaniels> hey Sanjiva
> <asankha> it should default to send to faultto: else replyto:
> <gdaniels> asankha: but what's the faultTo once the message has been
> replaced?
> <gdaniels> Is it the faultTo of the fault, or of the original request? :)
> <asankha> sorry i meant the faultto in the message, at the time we invoke
> the fault mediator
> <gdaniels> but how does that get to the <send>, then?
> <gdaniels> wouldn't it get replaced?
> <paulfremantle> nope its only the body thats replaced
> <gdaniels> well, the WSA headers have to be replaced too
> <gdaniels> at least in the message
> <Deepal> ya
> <gdaniels> the problem is that the WSA headers in a given message are not
> the same thing as the WSA properties in a message exchange
> <paulfremantle> is there a scenario where you want the fault sent to the
> server?
> <Deepal> can we replce whole message
> <gdaniels> I'm not sure, Paul
> <Deepal> and change reuired field ?
> <asankha> well the fault mediator should set the to: address to what was
> the faultto: at the time the mediator was invoked...
> <gdaniels> ok
> <asankha> if you want to create a second fault message to a different to:
> address.. now you need to set it explicitly before you call the send
> mediator again
> <gdaniels> alrighty.
> <gdaniels> so here's the thing
> <asankha> but i think this would be a rare scenario.. and so will require
> a bit of configuration stuff to set it so..
> <gdaniels> it's not so rare in one case, though
> <gdaniels> client sends req to Synapse, Synapse forwards, then problem
> processing response
> <paulfremantle> im not sure we can do that yet
> <gdaniels> whether or not there's a fault that goes back to the server
> about the faulty response, there should be a fault to the client about the
> failed MEP
> <Deepal> u mean to synapse ?
> <asankha> but i think we could easily do this.. with the configuration
> language proposed..
> <asankha> you create the fault message and invoke the send mediator with
> an explicit endpoint where it should go to..
> <gdaniels> the "explicit endpoint" isn't explicit, though - it's "the
> faultTo or replyTo of the original request" (which might be an HTTP response
> we're still waiting to fill)
> <paulfremantle> i think we need a diagram
> <sanjiva> hey guys
> <sanjiva> sorry for not being around .. but can't hang around for much
> today :(
> <asankha> but you could override it with a set-header if you want to ..
> <sanjiva> I see some conversation about faultTo of <makefault>: IMO it
> should be that there's no <faultTo> for the fault .. the <to> becomes the
> <faultTo> of the old message
> <gdaniels> right - but the q is just how to make that happen in all the
> cases
> <sanjiva> That is, <makefault> creates a fault message relative to the
> current message- that's a message targeted to the <FaultTo> addr of the
> message (or following the rules of ws-addr for how to send a fault
> <gdaniels> the scenario we're discussing is how to get a fault back to the
> client when there's a problem processing the RESPONSE
> <sanjiva> If you want to override, now step in and change the <to> of the
> currrent message .. that is, once <makefault> completes the current message
> is a "fault message" targeted to the right place
> <sanjiva> presumably u have some info about where to send the fault to,
> yes?
> <asankha> exactly...
> <gdaniels> you do, but it's not in the "current message" at all... it's in
> the MEP
> <asankha> you could actually save the to: address before you call
> makefault.. and then again set it back..
> <gdaniels> i.e. you're on the response, the faultTo you want comes from
> the request
> <Deepal> but u have to have original client info somewhere
> <asankha> no.. the response from the server to the client encounters a
> fault within synapse on its way..
> <asankha> now this message has the to: set to the clients address while
> the fault occurs..
> <sanjiva> if you have the info somewhere, then go get it from whereever u
> have it and stuff it into the message .. doesnt' matter where really
> <asankha> so you should be able to save it.. make a fault.. which may set
> the to: of the fault message to the server
> <sanjiva> all we need to do is make sure there's ways to access the larger
> context of the message
> <asankha> and then set it back to the saved value.. and send
> <paulfremantle> the question we need to answer: does this effect the
> config syntax. If the implementation of MakeFault works then it doesn't
> matter how
> <sanjiva> which can easily be done with xpath++
> <paulfremantle> as long as we are talking about the config syntax
> <gdaniels> I'd like to see an example of how to do this
> <sanjiva> it doesn't affect config syntax much .. just have to set to <to>
> prop of the message by computing its value
> <sanjiva> ok I'll send it! its easy :)
> <sanjiva> trust me for now :)
> <Deepal> :)
> <gdaniels> understand that in the case of one-way msgs, there may also be
> a faultTo on the response from the server....
> <sanjiva> yes understood- and your point is u want to ignroe than and send
> to some address computed from the mep right?
> <gdaniels> right
> <gdaniels> or potentially send to both - and in fact they might be
> different faults
> <gdaniels> which brings up another issue... splits/branching
> <sanjiva> so it'll be a combo of <makefault>..</mf> followed by a <send>
> with a computed endpoint addr where the addr is computed by looking up from
> context
> <asankha> yes
> <sanjiva> can do mult sends too .. just use <send> with multiple addrs
> <sanjiva> can we defer split/branch? if we do that we're *really*
> reinventing bpel :)
> <gdaniels> but you can only mult send the same/message
> <sanjiva> ah yes right now- 'cause <send/> finishes life. good point. so
> ok we do need branch to keep going ..
> <sanjiva> ok bpel here we come
> <gdaniels> hehehe
> <asankha> :)
> <gdaniels> I don't think we go that far
> <gdaniels> (thank goodness :))
> <sanjiva> <parallel><branch1/> .. <branchn/></parallel>
> <gdaniels> but branch is needed, I think
> <sanjiva> and I guess we should have the message context be cloned for
> each branch? not sure
> <paulfremantle> theres a diff between aggregation and disaggrefation
> <sanjiva> have to think about that
> <sanjiva> disaggrefation? :)
> <gdaniels> I think cloning sounds right
> <paulfremantle> disaggreGation :-)  is simple - aggregration is BPEL
> <gdaniels> yes, I agree, BPEL is aggravating.
> <ant_> can one of the addrs on a send be the local synapse?
> <sanjiva> ah :) true .. we do not have the part of bpel where we have to
> define a new service - just the programming language part ;-)
> <gdaniels> oh, aggreGATING!
> <gdaniels> sorry :)
> <sanjiva> soon we will have <onfault> .. and then compensation too? ;-)
> <sanjiva> ah :) it is aggravating too I have to agree
> <sanjiva> that's why I'm no longer a bpel language fan ... but a bpel
> concept fan ;)
> <sanjiva> anyway, we digress
> <gdaniels> I'm with you
> <sanjiva> so can we live w/o fork/join for now? it can be done .. just
> need another gizmo with clone the MC and let both go semantics
> * gdaniels thinks we need a use-cases/scenarios section, with detailed
> scenarios
> * sanjiva hmmm no infravio guys today
> * sanjiva yes glen and after that the requirements document and then then
> the arch document and the design document. then we'll offshore all that and
> we'll have the code. voila! ;-)
> <paulfremantle> yes we had hari
> <paulfremantle> but he left
> <sanjiva> hari wade?
> <sanjiva> definitely hari wade
> <paulfremantle> hariharisdhana
> <sanjiva> :) sorry .. sinhalese joke .. hari wade means "funny thing" or
> something of that nature ;)
> <gdaniels> :)
> <paulfremantle> k
> <sanjiva> qq about time: is it correct that UK is now GMT, Europe is
> GMT+1, US East is GMT-5?
> <sanjiva> (sorry unrelated)
> <gdaniels> heh
> <paulfremantle> no
> <gdaniels> that was our first topic
> <sanjiva> oh jeez
> <paulfremantle> UK is GMT+1
> <sanjiva> sorry
> <sanjiva> oh!
> <paulfremantle> EU is GMT+2
> <paulfremantle> US is GMT-4
> <paulfremantle> i think
> <sanjiva> is that just for another week or something ??
> <paulfremantle> east coast that was
> <paulfremantle> noooo
> <paulfremantle> for the summer
> <sanjiva> ah ok
> <gdaniels> time for the chat into the future is
> <gdaniels> 5AM PST, 8AM EST, 12PM GMT, 5:30PM SLT
> <gdaniels> until we switch back
> <gdaniels> I've updated the chatbot
> <paulfremantle> 8AM EDT dont you mean
> <gdaniels> yes
> <paulfremantle> 5AM PDT
> <gdaniels> EDT
> <gdaniels> PDT
> <gdaniels> ya
> <paulfremantle> 1PM BST
> <paulfremantle> ok cool
> <gdaniels> BST = British Standard?
> <gdaniels> BDT?
> <paulfremantle> british SUMMER time
> <gdaniels> SUMMER
> <gdaniels> right
> <sanjiva> ok ... have to go guys sorry. will check the log and follow up
> on the list.
> <paulfremantle> i know its an oxymoron
> <gdaniels> lol
> <paulfremantle> british + summer :)
> <paulfremantle> but we gotta have hope
> <gdaniels> BRT
> <sanjiva> btw we are also on summer time now .. except our summer will
> last until the next president comes in. we believe in longer seasons than u
> guys; so much more reasonable.
> <paulfremantle> lolol
> <gdaniels> (R = Rainy)
> <paulfremantle> yeah I guessed glen :-)
> <gdaniels> hey, if we could keep it warm here through 4 years of a given
> president we might try that too...
> <gdaniels> so are we winding down for today then?
> <asankha> does the rest of the config lang changes look ok?
> <paulfremantle> i like them on the whole
> <asankha> we could always add or change as necessary..
> <paulfremantle> i have a few minor issues but they are more likely to get
> resolved as we code this and play with it
> <gdaniels> certainly better than what we have now
> <paulfremantle> +1
> <gdaniels> +1 to move there and play with it
> <ant_> +1
> <saminda> +1
> <asankha> great.. we could start off on this and look at the other
> hopefully minor issues later..
> <paulfremantle> exactly
> <asankha> im all set then if we want to wind down now..
> <paulfremantle> great
> <paulfremantle> who has some time to implement?
> <asankha> i guess i could..?
> <paulfremantle> :)
> <paulfremantle> great
> <saminda> me too
> <ant_> i have to go. ttyal
> Session Close: Thu Apr 27 14:48:30 2006
>
>
>
> On 5/1/06, Paul Fremantle <pz...@gmail.com> wrote:
> >
> > Did anyone log last week's IRC chat?
> >
> > Paul
> >
> > --
> > 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

Re: Last weeks chat

[ant elder <an...@gmail.com>]

Not sure what I missed at the beginning but here's what I have:

Session Start: Thu Apr 27 13:29:56 2006
Session Ident: #apache-synapse
* Now talking in #apache-synapse
* ant_away is now known as ant_
<ant_> hi, sorry so late
<paulfremantle> you arent
<paulfremantle> your early
<paulfremantle> but we are adjusting the start time
<ant_> oh. what is the start time?
<paulfremantle> it was 1pm GMT
<paulfremantle> next week will be 1pm BST
<gdaniels> or 8AM Eastern
<gdaniels> or 5AM Pacific
<gdaniels> or 7PM Sri Lanka
<paulfremantle> this week we are halfway :-)
<gdaniels> ... the chatbot was a bit confused ;)
<Deepal> :)
* Hariharasudhan has joined #apache-synapse
* Looking up Hariharasudhan user info...
<Deepal> shall we start ?
<paulfremantle> lets
<ant_> ok
<paulfremantle>
http://wiki.apache.org/incubator/Synapse/SynapseConfigurationLanguage
<paulfremantle> is the discussion point
<asankha> didnt get many comments through the mailing list.. so hope we
could talk about it now.. :)
<paulfremantle> well overall I'm +1
<paulfremantle> i think its pretty good
<paulfremantle> i'll start nit picking in a minute :)
<ant_> me too, its more clean and tidy than the old approach
* Hariharasudhan has left #apache-synapse
<Deepal> Asanka can u pls explain to us bit abt that
<Deepal> then we can easily follow the doc
<gdaniels> I don't see anything in here about extensibility/new mediators
<paulfremantle> class
<gdaniels> hm
<ant_> so the list under 'mediators' (send, drop, log, etc) is the
conclusive list, you can't add to that?
<gdaniels> I'd like something along the lines of <mediator qname="ns:name"
class="factoryClass"/>
<gdaniels> then <ns:name><config.../></ns:name>
<gdaniels> that way you can extend the "nice looking" set :)
<paulfremantle> you can already
<paulfremantle> create a mediatorfactory
<gdaniels> ?
<paulfremantle> and package it as a JAR
<paulfremantle> and it gets auto registered
<gdaniels> is that in here somewhere?
<gdaniels> that's totally cool with me if so
<Deepal> I did not see that in the doc
<gdaniels> drop it in repo/mediators
<Deepal> +1
<paulfremantle> its described in
http://wiki.apache.org/incubator/Synapse/Architecture
<paulfremantle> The XML configuration model (see package
org.apache.synapse.xml) is independent of the mediator model. The XML
configuration model is based on an xml.MediatorFactory, which simply takes
an XML tree and creates a mediator object. This is done recursively until
the tree is built. The Java2 JAR file service provider model (see [WWW]
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider)
is used to automatica
<paulfremantle> we could do the "repo/mediators" - that would be another
approach
<gdaniels> "done recursively"... that's really up to your mediatorFactory,
right?
<paulfremantle> yes of course
<paulfremantle> that only really applies to the "grouping" mediators
<paulfremantle> leaf nodes dont recurse
<Deepal> btw I might missing some thing why do we want mediatorFactory
<paulfremantle> mediatorfactory is only if you want to extend the XML syntax
<paulfremantle> its not required
<Deepal> oh , thx
<gdaniels> well, it's still the way things work even for the base config,
right?
<paulfremantle> yes - except if you just want to new up mediators by hand
<Deepal> hmm
<ant_> just so I'm clear, so it is possible to have:
<ant_> <class name="org.apache.syanpse.RhinoInvoker">
<Deepal> you mean we have to do addition steps  , if we are going to hand
create a new mediators
<ant_>     <property name="scriptFile" value="MyScript.js"/>
<ant_> </class>
<paulfremantle> yes thats possible ant
<ant_> or else with a mediator factory:
<ant_> <script scriptFile="MyScript.js"/>
<paulfremantle> exactly
<ant_> ok cool
<asankha> ant: on your question.. do you think we should have any other main
mediators?
<ant_> if its extensible like this it sounds fine. More could get added as
they come up
<gdaniels> so <send>...
<gdaniels> how does that decide where to send the message?
<asankha> if its just <send/> it will pick it from the current message
<gdaniels> how exactly?  wsa:To?
<paulfremantle> well to be precise
<paulfremantle> synapseMessage.getTo()
<gdaniels> I'm just trying to figure out how to use this to send a fault
back to the client if a security check on the request fails, for instance.
In this case I want the replyTo.
<paulfremantle> ah true
<paulfremantle> but that is taken care of
<asankha> when you make a fault, the fault mediator would do that for you..
<Deepal> so it will take was:faultTo
<Deepal> ?
<Deepal> as to
<gdaniels> I don't think that totally works
<gdaniels> there are some cases where you want to send a fault ONWARDS and
other cases where you want to send it BACK
<paulfremantle> interesting point
<Deepal> ya
<gdaniels> I think we need a clearer architecture for deciding which
"virtual place" to send messages to
<Deepal> hmm , how Axis2 handle this ?
<paulfremantle> yes we have a "response" flag on the message
<Deepal> i mean when there is faultTo
<asankha> if a faultto: is available, cant we use it, else the replyto:?
<gdaniels> I think Axis2 deals fine with faultTo
<saminda> with faultto can't we handle Glens' scenarios?
<paulfremantle> on the synapse message we have
<Deepal> paul : why do we keep response flag in message
<paulfremantle> isresponse and isfaultresponse
<paulfremantle> seems like we dont have the idea it could be a onwards fault
<saminda> it's how we decide is the message sendon or sendback
<paulfremantle> yes
<Deepal> if we have faultTo we dont need to send any thing back
<Deepal> to the client
<saminda> I think Synapse should support fault Onwards and back
<asankha> so an onwards fault may be to something other than faulto or
replyto?
<Deepal> can we use replyTo send the fault ?
<gdaniels> well let's consider the scenario here
<Deepal> if we found a fault and we dont have a faultTo , then we have to
send the fault to client
<gdaniels> client -> synapse -> server
<gdaniels> client sends request
<gdaniels> goes through just fine
<gdaniels> server sends response
<gdaniels> response goes through Synapse and produces a problem of some kind
<gdaniels> then we want to send a fault to the client
<gdaniels> (since there's probably no way to send it to the server anyway)
<asankha> does the server specify faultto: to the client?
<gdaniels> so this is a "fault onwards" scenario
<saminda> yes
<gdaniels> asankha: nope
<gdaniels> no need to, why would it?
<gdaniels> it thinks it's sending the response to the "client"
<gdaniels> everyone ok with that scenario?
<paulfremantle> sure
<asankha> yes
<gdaniels> so Synapse has the MEP context somewhere, right?
<gdaniels> otherwise it couldn't reply to the right place
<paulfremantle> synapse knows this is a response
<gdaniels> and where to send it
<paulfremantle> yep
<saminda> yes
<gdaniels> ok, so who makes this decision then?
<gdaniels> the fault mediator?
<gdaniels> I guess maybe we should figure out what kind of fault we're
talking about here to make this clearer
<asankha> glen: from the servers point of view.. synapse is acting on behalf
of the client.. maybe synapse found a validation error in the response.. so
sending this fault back to the server would be correct.. isnt it? i mean
unless a fault to is specified..
<Deepal> how does synasep determine whether it is a fault or not
<Deepal> ooops sorry :)
<gdaniels> asankha: sure, but even in that case we want to send a fault back
to the client as well, right?
<asankha> you mean to both?
<gdaniels> perhaps, yes
<paulfremantle> then that would be a new directive to "create a new message"
<asankha> the proposed fault mediator doesnt actually send the message..
just transforms the current message into a fault message..
<paulfremantle> exactly
<asankha> then you could call the send mediator with two endpoints and send
the fault to both
<gdaniels> although you might want different faults
<asankha> hmm ..even thats possible.. but you will then have to define it in
the configuration that way...
<gdaniels> I'm not sure about the whole "transforms the current message"
thing
<gdaniels> first off, it's "replaces" not "transforms"
<paulfremantle> yep
<gdaniels> and second, wouldn't that default to "send fault onwards" instead
of "send fault back"?
<gdaniels> typically "send fault back" is what we want, "onwards" will be
rare, I think
* sanjiva has joined #apache-synapse
<gdaniels> hey Sanjiva
<asankha> it should default to send to faultto: else replyto:
<gdaniels> asankha: but what's the faultTo once the message has been
replaced?
<gdaniels> Is it the faultTo of the fault, or of the original request? :)
<asankha> sorry i meant the faultto in the message, at the time we invoke
the fault mediator
<gdaniels> but how does that get to the <send>, then?
<gdaniels> wouldn't it get replaced?
<paulfremantle> nope its only the body thats replaced
<gdaniels> well, the WSA headers have to be replaced too
<gdaniels> at least in the message
<Deepal> ya
<gdaniels> the problem is that the WSA headers in a given message are not
the same thing as the WSA properties in a message exchange
<paulfremantle> is there a scenario where you want the fault sent to the
server?
<Deepal> can we replce whole message
<gdaniels> I'm not sure, Paul
<Deepal> and change reuired field ?
<asankha> well the fault mediator should set the to: address to what was the
faultto: at the time the mediator was invoked...
<gdaniels> ok
<asankha> if you want to create a second fault message to a different to:
address.. now you need to set it explicitly before you call the send
mediator again
<gdaniels> alrighty.
<gdaniels> so here's the thing
<asankha> but i think this would be a rare scenario.. and so will require a
bit of configuration stuff to set it so..
<gdaniels> it's not so rare in one case, though
<gdaniels> client sends req to Synapse, Synapse forwards, then problem
processing response
<paulfremantle> im not sure we can do that yet
<gdaniels> whether or not there's a fault that goes back to the server about
the faulty response, there should be a fault to the client about the failed
MEP
<Deepal> u mean to synapse ?
<asankha> but i think we could easily do this.. with the configuration
language proposed..
<asankha> you create the fault message and invoke the send mediator with an
explicit endpoint where it should go to..
<gdaniels> the "explicit endpoint" isn't explicit, though - it's "the
faultTo or replyTo of the original request" (which might be an HTTP response
we're still waiting to fill)
<paulfremantle> i think we need a diagram
<sanjiva> hey guys
<sanjiva> sorry for not being around .. but can't hang around for much today
:(
<asankha> but you could override it with a set-header if you want to ..
<sanjiva> I see some conversation about faultTo of <makefault>: IMO it
should be that there's no <faultTo> for the fault .. the <to> becomes the
<faultTo> of the old message
<gdaniels> right - but the q is just how to make that happen in all the
cases
<sanjiva> That is, <makefault> creates a fault message relative to the
current message- that's a message targeted to the <FaultTo> addr of the
message (or following the rules of ws-addr for how to send a fault
<gdaniels> the scenario we're discussing is how to get a fault back to the
client when there's a problem processing the RESPONSE
<sanjiva> If you want to override, now step in and change the <to> of the
currrent message .. that is, once <makefault> completes the current message
is a "fault message" targeted to the right place
<sanjiva> presumably u have some info about where to send the fault to, yes?
<asankha> exactly...
<gdaniels> you do, but it's not in the "current message" at all... it's in
the MEP
<asankha> you could actually save the to: address before you call
makefault.. and then again set it back..
<gdaniels> i.e. you're on the response, the faultTo you want comes from the
request
<Deepal> but u have to have original client info somewhere
<asankha> no.. the response from the server to the client encounters a fault
within synapse on its way..
<asankha> now this message has the to: set to the clients address while the
fault occurs..
<sanjiva> if you have the info somewhere, then go get it from whereever u
have it and stuff it into the message .. doesnt' matter where really
<asankha> so you should be able to save it.. make a fault.. which may set
the to: of the fault message to the server
<sanjiva> all we need to do is make sure there's ways to access the larger
context of the message
<asankha> and then set it back to the saved value.. and send
<paulfremantle> the question we need to answer: does this effect the config
syntax. If the implementation of MakeFault works then it doesn't matter how
<sanjiva> which can easily be done with xpath++
<paulfremantle> as long as we are talking about the config syntax
<gdaniels> I'd like to see an example of how to do this
<sanjiva> it doesn't affect config syntax much .. just have to set to <to>
prop of the message by computing its value
<sanjiva> ok I'll send it! its easy :)
<sanjiva> trust me for now :)
<Deepal> :)
<gdaniels> understand that in the case of one-way msgs, there may also be a
faultTo on the response from the server....
<sanjiva> yes understood- and your point is u want to ignroe than and send
to some address computed from the mep right?
<gdaniels> right
<gdaniels> or potentially send to both - and in fact they might be different
faults
<gdaniels> which brings up another issue... splits/branching
<sanjiva> so it'll be a combo of <makefault>..</mf> followed by a <send>
with a computed endpoint addr where the addr is computed by looking up from
context
<asankha> yes
<sanjiva> can do mult sends too .. just use <send> with multiple addrs
<sanjiva> can we defer split/branch? if we do that we're *really*
reinventing bpel :)
<gdaniels> but you can only mult send the same/message
<sanjiva> ah yes right now- 'cause <send/> finishes life. good point. so ok
we do need branch to keep going ..
<sanjiva> ok bpel here we come
<gdaniels> hehehe
<asankha> :)
<gdaniels> I don't think we go that far
<gdaniels> (thank goodness :))
<sanjiva> <parallel><branch1/> .. <branchn/></parallel>
<gdaniels> but branch is needed, I think
<sanjiva> and I guess we should have the message context be cloned for each
branch? not sure
<paulfremantle> theres a diff between aggregation and disaggrefation
<sanjiva> have to think about that
<sanjiva> disaggrefation? :)
<gdaniels> I think cloning sounds right
<paulfremantle> disaggreGation :-)  is simple - aggregration is BPEL
<gdaniels> yes, I agree, BPEL is aggravating.
<ant_> can one of the addrs on a send be the local synapse?
<sanjiva> ah :) true .. we do not have the part of bpel where we have to
define a new service - just the programming language part ;-)
<gdaniels> oh, aggreGATING!
<gdaniels> sorry :)
<sanjiva> soon we will have <onfault> .. and then compensation too? ;-)
<sanjiva> ah :) it is aggravating too I have to agree
<sanjiva> that's why I'm no longer a bpel language fan ... but a bpel
concept fan ;)
<sanjiva> anyway, we digress
<gdaniels> I'm with you
<sanjiva> so can we live w/o fork/join for now? it can be done .. just need
another gizmo with clone the MC and let both go semantics
* gdaniels thinks we need a use-cases/scenarios section, with detailed
scenarios
* sanjiva hmmm no infravio guys today
* sanjiva yes glen and after that the requirements document and then then
the arch document and the design document. then we'll offshore all that and
we'll have the code. voila! ;-)
<paulfremantle> yes we had hari
<paulfremantle> but he left
<sanjiva> hari wade?
<sanjiva> definitely hari wade
<paulfremantle> hariharisdhana
<sanjiva> :) sorry .. sinhalese joke .. hari wade means "funny thing" or
something of that nature ;)
<gdaniels> :)
<paulfremantle> k
<sanjiva> qq about time: is it correct that UK is now GMT, Europe is GMT+1,
US East is GMT-5?
<sanjiva> (sorry unrelated)
<gdaniels> heh
<paulfremantle> no
<gdaniels> that was our first topic
<sanjiva> oh jeez
<paulfremantle> UK is GMT+1
<sanjiva> sorry
<sanjiva> oh!
<paulfremantle> EU is GMT+2
<paulfremantle> US is GMT-4
<paulfremantle> i think
<sanjiva> is that just for another week or something ??
<paulfremantle> east coast that was
<paulfremantle> noooo
<paulfremantle> for the summer
<sanjiva> ah ok
<gdaniels> time for the chat into the future is
<gdaniels> 5AM PST, 8AM EST, 12PM GMT, 5:30PM SLT
<gdaniels> until we switch back
<gdaniels> I've updated the chatbot
<paulfremantle> 8AM EDT dont you mean
<gdaniels> yes
<paulfremantle> 5AM PDT
<gdaniels> EDT
<gdaniels> PDT
<gdaniels> ya
<paulfremantle> 1PM BST
<paulfremantle> ok cool
<gdaniels> BST = British Standard?
<gdaniels> BDT?
<paulfremantle> british SUMMER time
<gdaniels> SUMMER
<gdaniels> right
<sanjiva> ok ... have to go guys sorry. will check the log and follow up on
the list.
<paulfremantle> i know its an oxymoron
<gdaniels> lol
<paulfremantle> british + summer :)
<paulfremantle> but we gotta have hope
<gdaniels> BRT
<sanjiva> btw we are also on summer time now .. except our summer will last
until the next president comes in. we believe in longer seasons than u guys;
so much more reasonable.
<paulfremantle> lolol
<gdaniels> (R = Rainy)
<paulfremantle> yeah I guessed glen :-)
<gdaniels> hey, if we could keep it warm here through 4 years of a given
president we might try that too...
<gdaniels> so are we winding down for today then?
<asankha> does the rest of the config lang changes look ok?
<paulfremantle> i like them on the whole
<asankha> we could always add or change as necessary..
<paulfremantle> i have a few minor issues but they are more likely to get
resolved as we code this and play with it
<gdaniels> certainly better than what we have now
<paulfremantle> +1
<gdaniels> +1 to move there and play with it
<ant_> +1
<saminda> +1
<asankha> great.. we could start off on this and look at the other hopefully
minor issues later..
<paulfremantle> exactly
<asankha> im all set then if we want to wind down now..
<paulfremantle> great
<paulfremantle> who has some time to implement?
<asankha> i guess i could..?
<paulfremantle> :)
<paulfremantle> great
<saminda> me too
<ant_> i have to go. ttyal
Session Close: Thu Apr 27 14:48:30 2006


On 5/1/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> Did anyone log last week's IRC chat?
>
> Paul
>
> --
> 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
>