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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
