synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: Last weeks chat
Date Mon, 01 May 2006 17:33:48 GMT
Thanks!!!!

On 5/1/06, ant elder <ant.elder@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 <pzfreo@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

Mime
View raw message