* Now talking in #apache-synapse
<paulfremantle> hi
<asankha> hi
* saminda has joined #apache-synapse
* gdaniels has joined #apache-synapse
<gdaniels> good morning/afternoon all
<paulfremantle> hey
<paulfremantle> how are you?
<gdaniels> not too bad
<gdaniels> getting ready to head to SF tomorrow
<gdaniels> (JavaOne next wk)
<paulfremantle> ah should be fun
<paulfremantle> you going to any concerts while you are there??!
<gdaniels> probably :)
<gdaniels> J1 always has some cool band or other, plus there are a few
shows next wk I was eyeing if I have a chance
<gdaniels> did you ever get a chance to read over that article?
<paulfremantle> oh :(
<paulfremantle> can we take that offline where i can grovel more loudly?
<gdaniels> heh
<gdaniels> surely
<gdaniels> so are other folks here?
<asankha> yep.. :)
<paulfremantle> shall we start?
<paulfremantle> ant said he'd be a bit late
<gdaniels> :) hi Asankha
<asankha> sure
<asankha> hi Glen
<asankha> shall we start with the topic that Glen brought into the
mailing list?
<paulfremantle> yes
<asankha> Glen.. could you drive us through?
<gdaniels> woo hoo sending and receiving and MEPs, oh my!
<gdaniels> so basically I wanted to talk about how Synapse deals with
sending and receiving in general
<gdaniels> i.e. sanity check our notion of how sending should work in
various situations
<paulfremantle> yep
<gdaniels> and figure out what we eventually want
<gdaniels> this will hopefully lead us to a design for 1.0 that we don't
have to destroy and rebuild later
<gdaniels> this also relates to Asankha's recent msg about correlation
<asankha> yes.. i am waiting for replies on the message list.. but this
is a good time to talk about that too...
<gdaniels> so let's start with a simple basic assumption, which is that
<send> simply sends to the wsa:To in the message
<gdaniels> problems I see with that assumption include the ability to
send a copy of a message elsewhere
* dims waves to everyone, says hi and wanders off
<gdaniels> and dealing with responses
<gdaniels> i.e. if Synapse wants to act as a bidirectional proxy, it
needs to rewrite the <ReplyTo> on outgoing messages (might need to)
<paulfremantle> yep
<paulfremantle> and it also needs to be able to deal with the case where
the endpoint isnt WS-A aware....
<gdaniels> there are a lot of tricky issues here which we need to at
least think about a little, I think
<gdaniels> Paul: yes
<paulfremantle> so for example where it can't add ref params into the
reply to
<gdaniels> we should also be able to map sync-async and async-sync
<paulfremantle> yes
<saminda> yes
<gdaniels> that should come in really handy now that MSoft is promoting
a development model which locks down whether or not a particular channel
supports sync at all
<gdaniels> WCF services either MUST be anonymous ReplyTo, or MUST be
non-anonymous. No optionality.
<paulfremantle> hey i didnt know that
<gdaniels> so Synapse might come in handy to provide that optionality
<paulfremantle> interesting
<paulfremantle> where's that defined? apart from in the WCF codebase :)
<gdaniels> yeah, I think it's weird, but an 800-lb gorilla can't be
wrong, right? :)
<gdaniels> look up duplex channels
<paulfremantle> thanks
<gdaniels> so anyhoo
<saminda> glen got little problem with async-sync
<asankha> glen.. so if we rewrite the replyto of outgoing messages to
synapse, once we start getting the replies, it may turn out to be a bit
tricky to map them back to the correct replyto wouldnt it?
* ant_back1315 is now known as ant_
<gdaniels> asankha: if we're rewriting, it's easy to add a ref param for
correlation
<saminda> sync-async case for mutliple <send/> can be think of
<saminda> but otherway around ??
<gdaniels> saminda: could you give an example?
<saminda> i can't grasp the async-sync, pls help me with it
<asankha> i guess someone wants to get an async response from a
syncronous service? is that right saminda
<gdaniels> message comes in to Synapse with <replyto>A</>
<gdaniels> where A is a non-anon URL
<saminda> ok
<saminda> right
<saminda> so this is IN to Synapse right
<gdaniels> Synapse then either sends on that original message with an
edited <replyTo>anon</>, or just calls out itself on a totally new
message - in either case to a synch service
<gdaniels> saminda: yes, but then the OUT goes to a sync service
<saminda> thank you
<gdaniels> Synapse would then get the response back from the sync
service and either send it back <To>A</> or send back another message
that it creates <To>A</>
<paulfremantle> +1
<saminda> +1
<gdaniels> so if a given client wanted to use async/callback style, and
the "true" destination was a .Net "non-duplex" channel, we could use
something like this to make it work
<asankha> right.. i guess we could capture these example scenarios into
the wiki so we could always easily refer back?
<gdaniels> yes yes yes
<gdaniels> +1,000,000 to use-cases in the wiki
<gdaniels> so I see two architectural issues (at least) here
<saminda> ok
<gdaniels> 1) sending to destinations that are decided upon at runtime,
and not necessarily by rewriting the <To> header
<gdaniels> 2) correlation / understanding MEPs
<asankha> yes..
<gdaniels> a very simple version of (1) might be something like <send
destination="URL"/> or <send destProperty="propName"/>
<paulfremantle> so glen.... firstly.. i think that synapse could handle
the sync->async
<paulfremantle> and I think we can handle the async to sync too
<gdaniels> (destProperty would be a property containing a destination at
runtime)
<paulfremantle> what we aren't very good at handling.... is doing
something to a response based on what the request is
<gdaniels> paul: yes exactly
<gdaniels> despite Sanjiva's clear reservations, I think we need that in 1.0
<asankha> that applies to both sync and async messages
<gdaniels> or at least we need to seriously consider the architectural
ramifications so we don't design ourselves into a corner
<paulfremantle> well..... my reservation
<paulfremantle> is having something that makes it hard to cluster synapse
<gdaniels> hmm
<gdaniels> if we have well-modularized APIs for getting at state, then
we could always write backing stores that cluster (i.e. dbs)
<gdaniels> obviously that only works for serializable state and not
sockets, though!
<paulfremantle> well... there are some things we can do anyway tho
<paulfremantle> if we are calling a service using axis2
<gdaniels> when connections are being held open, you need to go back to
that exact process
<paulfremantle> then it lets us correlate the responses
<gdaniels> sure but we need to figure out what Synapse does WRT waiting
around for the responses
<gdaniels> i.e. do we block a thread, and if not we need to do some kind
of correlation
<asankha> the difficulty with clustering is to keep the correlation
available to all instances is it?
<paulfremantle> so there are two cases arent there.... same as axis2
<paulfremantle> either the reply to is anon
<paulfremantle> in which case the open socket is the correlator
<paulfremantle> or there is a real reply to
<paulfremantle> in which case the WSA is the correlator
<paulfremantle> i think axis2 can actually do the correlation we need
<paulfremantle> thats different to doing a clustered thing i think
<ant_> does that mean anon replyTos are not clusterable?
<paulfremantle> no
<paulfremantle> because they are the easy ones
<paulfremantle> they have to come back to the same instance
<gdaniels> ant: it's only doable if you have sharable sockets
<paulfremantle> welcome ant
<ant_> hi
<gdaniels> and hi :)
<paulfremantle> the real reply tos are the hard ones...
<paulfremantle> because they might come back to a different instance if
synapse isnt set up right
<asankha> what if we multicast the message id's and the replyto where
the response should go to to all instances in a cluster
<paulfremantle> well thats cool
<paulfremantle> but def v2!
<asankha> and once an instance received the response, it issues another
multicast to invalidate the entry from the clusterwide cache
<gdaniels> how the state is shared should be behind interfaces/APIs
which simply refuse to make assumptions that state comes from a
particular place
<gdaniels> the important part is that the Synapse core writes the
correlation info "somewhere" via a
well-defined api
<gdaniels> then we can plug in cluster support into that
state-management API later
<gdaniels> same with configuration
<paulfremantle> i think asankhas model (in email)
<paulfremantle> of using axis2's req-response correlation
<asankha> yes.. that was for the 'simple' case that you mentioned Paul...
<paulfremantle> and copying from the req context to the resp context
<paulfremantle> could handle a fair number of cases
<asankha> i guess it could handle cases where incoming is sync
<asankha> do you think its something we want to implement?..
<paulfremantle> yes i think its a good first step
<paulfremantle> but maybe we can implement it using a MEPcontext
<paulfremantle> in other words have a MEPContext
<paulfremantle> which manages properties that are copied across meps
<gdaniels> hmm
<gdaniels> now there's an idea
<paulfremantle> and it could also be used to help with reply tos
<gdaniels> sound, oh, *familiar* to anyone? :)
<paulfremantle> yeah
<paulfremantle> its your idea
<paulfremantle> Im not trying to steal it :)
<gdaniels> oh I didn't mean that
<paulfremantle> :)
<gdaniels> this leads to the question of "is it the right decision to
separate Synapse from Axis2, or would we gain a lot more from
integrating them more tightly"
<gdaniels> :)
<paulfremantle> well thats a fine question
<paulfremantle> i think... so far
<paulfremantle> that we've gained from the abstraction
<paulfremantle> its helped focus on whats necessary
<paulfremantle> and on the simple use cases
<ant_> i guess as one of the ones originally pushing for the seperation
i should say it doesn't really matter so much to me now. Everywhere i'm
likely to want to use Synapse would also have Axis2
<gdaniels> I'm not convinced yet either way, but I think there are a
number of cases where more direct reuse of Axis2 structure might really
help Synapse
<paulfremantle> i'm not strongly one way or the other either
<gdaniels> i.e. Modules, correlation, etc
<gdaniels> then again, I'm also in favor of moving towards the "virtual
service" model for configuration as well :)
<gdaniels> (i.e. multiple rulesets, with the first "implicit" rule being
a URL-based dispatch to a given set)
<paulfremantle> now that we have a fairly well defined end-user model
<paulfremantle> thats reasonably clean
<paulfremantle> i dont mind how connected the infrastructure is
<paulfremantle> but I think it has helped us keep our thinking clean
<gdaniels> I just wonder if anyone is really hoping to implement Synapse
over other engines... IIRC it was the IONA guys that were really talking
about that and they seem to have pretty much disapeared
<paulfremantle> yeah i dont think thats the important use case..... in
fact i dont think I ever did
<asankha> Paul.. so on what we have discussed today.. how much will we
consider for M2?
<saminda> got to go guys, bye!
* saminda has left #apache-synapse ("Leaving")
<paulfremantle> how about we try to get an M2 out fairly soon with the
changes we've made
<paulfremantle> plus the ability to handle responses in your scenario
asankha
<asankha> cool.. and in the meanwhile we could start documenting whats
in store for M3 and how we will implement them and use cases
<paulfremantle> i like the idea of making the startup tied to the axis2
startup and also the ability to simply specify the synapse xml
<paulfremantle> and a bunch of good samples
<paulfremantle> and DOC
<paulfremantle> that would make a nice release
<asankha> i have actually tried my use case with the approach i
emailed.. but we could probably have all messagecontext properties that
are correlate/* copied over as well.. is that ok?
<paulfremantle> that would be a good start
<asankha> yes.. im working on the samples.. but not yet in a good state
to send a patch.. and svn was having some trouble committing the
previous patches..
<asankha> ok.. will do this and send out a patch and get it committed by
early next week
<paulfremantle> ok
<ant_> does anyone know whats going on with SVN? been donw for ages now
<paulfremantle> well lets try and get you a committer asankha so you
dont have to do so much patching
<asankha> that'll be great Paul..
<gdaniels> +1
<ant_> i'll send the ws pmc a note about the vote right after this chat
<asankha> so shall we wind up for today.. or is there anything else for
discussion?
<paulfremantle> ant... no idea about svn...
<gdaniels> I've gotta run myself
<paulfremantle> yes i think we're done for today
<paulfremantle> thanks everyone
<paulfremantle> who will post the chat log?
<asankha> i will
<asankha> thanks.. see u all later..
<gdaniels> bye folks!
<ant_> bye
* gdaniels has quit IRC
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
