Session Start: Thu Oct 27 10:02:19 2005 Session Ident: #apache-synapse [10:02] * Now talking in #apache-synapse [10:02] * Topic is 'Apache Synapse http://incubator.apache.org/synapse/' [10:02] * Set by Chinthaka on Thu Oct 27 09:56:10 [10:02] <Ajith_> Hi Glen [10:03] <gdaniels> Hi all [10:03] <Deepal> hi glen [10:04] <Chinthaka> hi all [10:04] <dims> hi Ajith_ [10:04] <dims> :) [10:04] <Vikas> hi [10:04] * dims is in the listening mode [10:04] <Deepal> Sathish and Vikas came to SL and we had a whole day discusion and we came up with a new archi for Synapse [10:04] <gdaniels> <rule>[text.contains("hi")]</rule><mediation>sendHello</mediation> [10:04] <dims> Can we release 1.0 tomorrow :) [10:04] <Deepal> and I just sent that to maling list and shall we discuss on that [10:05] <Vikas> basically saminda's synapse1 protoype with a few modifications [10:05] <Chinthaka> Dims : yes ;) [10:05] <dims> :) [10:06] <gdaniels> *can* we, sure. We *can* also release Microsoft Word 15.0 tomorrow, as an open source project. *Will* we? :) [10:06] <Ajith_> Dims : :D [10:06] <Deepal> Vikas , basically it combination of both Samindas and Pauls [10:07] <saminda> Hi guys [10:07] * dims has a trial version that expires end of the month...no ppt or word after that :( [10:08] <Ajith_> Hey go for open office [10:08] * dims already installed oo [10:08] <Ajith_> works fine for me for almost all .doc / .ppt stuff [10:09] <Ajith_> Ok back to the discussion [10:09] <dims> back to business...have u run through RM scenario with this new arch? [10:09] <saminda> aha [10:09] <Deepal> nope [10:09] <saminda> here we go... [10:09] <dims> transparently adding RM to a service not under our control (on another box) [10:10] * paulfremantle has joined #apache-synapse [10:10] * paulfremantle has quit IRC (Client Quit) [10:10] <Ajith_> Well.... RM is quite err..... 'complax' [10:10] <Ajith_> complex I mean [10:10] * paulfremantle has joined #apache-synapse [10:11] <Deepal> hi paul [10:11] <Vikas> hi paul [10:11] <paulfremantle> sorry im late [10:11] <saminda> Hi Paul [10:11] <paulfremantle> have i missed a lot? [10:11] <Ajith_> nope [10:11] <Deepal> not so [10:11] <paulfremantle> ok good :-) [10:11] <saminda> we have a modified version of you pic [10:11] <Deepal> we were discussion on the recent mail I sent to the list [10:12] <paulfremantle> can you send a link [10:12] <Deepal> can u pls take a look at that [10:12] <saminda> we need to go deep in to it and have a proper framwork for Synapse [10:12] <dims> In my mind, transparently adding RM and SecureConversation to a service on another box (not under our control) are a must (at least while thinking about architecture...., not for 1.0) [10:12] <paulfremantle> is it the pic with Rx [10:12] <paulfremantle> Ry etc [10:13] <Ajith_> oh BTW NPE in the picture refers to Native provider Endpoitn [10:13] <dims> hehe [10:13] <Ajith_> point [10:13] <dims> i thought it was the good old NullPointerException [10:13] <gdaniels> I had that same thought :) [10:13] <Deepal> he he [10:14] <Deepal> initially I thout so :) [10:14] <paulfremantle> so can you explain how R1->R2 works? [10:14] <gdaniels> So I'm not sure what the "big idea" in this new picture is [10:14] <Vikas> the segregation of mediators into phases.. [10:15] <Deepal> here we have divide execution into three phase [10:15] <Deepal> s [10:15] <gdaniels> (listening) [10:15] <Deepal> 1. Some rules whcih are run witout considering pre-condition [10:15] <gdaniels> What do you mean "pre-condition"? [10:16] <Deepal> so they can as a sequnce (in a while loop) [10:16] <Ajith_> it's like this [10:16] <Deepal> wt that mean is , Say there are three rules A,B,C [10:16] <Ajith_> there are three types of rules [10:16] <Ajith_> Ok I'll let deepal have a go first [10:16] <Deepal> then if B does not want to care abt wt A has doe [10:16] <Deepal> n [10:17] <Chinthaka> Deepal : better start with a explanation ;) [10:17] <Deepal> then they can run in a sequnce [10:17] <Deepal> Ajith : pls go ahead [10:17] <gdaniels> It sounds like you mean "mediations" not "rules" [10:18] <gdaniels> Are you talking about allowing sequences of mediation components that run without inter-component rule checking? [10:18] <Ajith_> ok : there are three types of rules [10:18] <Deepal> Glen : Rule is one to one map into mediator [10:18] <gdaniels> Deepal: Not as we've been discussing it before now [10:18] <Deepal> glen : yes [10:18] <gdaniels> We've been saying a rule *references* a mediation, not that there is a 1-1 mapping [10:19] <paulfremantle> so till now rule = condition + mediator [10:19] <Ajith_> the first type is the rule (or mediator to be exact ) that should run once only before things happen (Say a logger) [10:19] <paulfremantle> and i agree it is a reference [10:19] <gdaniels> i.e. I could have <rule>To==Glen</rule><mediation>M1</mediation> <rule>To==Deepal</rule><mediation>M1</mediation> [10:19] <Deepal> still we have taht [10:20] <Deepal> I mean thsose A, B, C are independent [10:20] <gdaniels> when you say "A", what are you talking about? [10:20] <Deepal> they will execute depnding on the condition [10:20] <Chinthaka> Ajith better explain first and then lets discuss on that [10:20] <Vikas> [i think Deepal is trying to convey that they r not decision points where you branch out] [10:21] <gdaniels> They are decision points though? [10:21] <Ajith_> the second type is the types of rules that need to be evaluated in a loop - Where the message gets processed over and over in the rule processor [10:21] <Ajith_> the third type is the type of rule that needs to execute after all this happens [10:21] <paulfremantle> so I thought until now we were doing all of this thru special mediators [10:21] <gdaniels> This sounds like a lot of added complexity. What's the use case? [10:22] <Ajith_> the idea behind this is that we do not want some types of rulesto be reevaluated [10:22] <Ajith_> say the logging [10:22] <paulfremantle> because we can do all this thru composing mediators [10:22] <paulfremantle> LoopMediator [10:22] <paulfremantle> BranchMediator [10:22] <paulfremantle> etc [10:22] * antelder has joined #apache-synapse [10:22] <antelder> hi guys, really late sorry [10:22] <paulfremantle> hi ant [10:23] <Ajith_> so if we inject the message back and the message needs to be re-proceesed from squre 1 which means that the logger will act twice [10:23] <Ajith_> which we do not want [10:23] <paulfremantle> yes [10:23] <gdaniels> maybe we do [10:23] <Ajith_> so effectively rules have a sort of phase that they belong to [10:23] <gdaniels> If the message has been changed, we might want to log it again [10:23] <Deepal> We try to minimize the rule calculation , no need to calculate for each rule processing [10:24] <Ajith_> the "pre" phase, the "loop" phase and the "post" phase [10:24] <gdaniels> ugh [10:24] <paulfremantle> but i thought we had a proposal for that [10:24] <Deepal> after each rule processing [10:24] <paulfremantle> which is simply to inject a new message if i want reprocessing [10:24] <Ajith_> only the rules that are there in the loop phase gets evaluated over and over again [10:25] <Ajith_> BTW the credit for the idea should go to Sanjiva :) [10:25] <Vikas> so reprocessing happens for the mediators in the processing phase rules and the in/out chains are one time call only.. [10:25] <Deepal> ??? [10:26] <paulfremantle> ok so I'm being stupid here :-) [10:26] <paulfremantle> can you guys explain the phases from the start [10:26] <gdaniels> So you're saying Synpase really has two different entry points [10:26] <paulfremantle> because I haven't got it yet [10:26] <gdaniels> One at the beginning, and one at the "loop" [10:26] <Deepal> we came up with this architecture by considering a use case came up be Vikas [10:26] <Vikas> the entry point remains one.. [10:26] <gdaniels> (ah ha! use case!) [10:27] <Deepal> Vikas can u pls explian that , [10:27] <gdaniels> (listens eagerly) [10:27] <Vikas> consider ant's usecase in the mailing list [10:27] <Vikas> u have a mediator that changes the WSATo [10:27] <Vikas> now there might be certain rules that depend on the WSATo value [10:28] <Vikas> and there r other rules that actually independent of this value.. like the * log [10:28] <Ajith_> the first type is the rule (or mediator to be exact ) that should run once only before things happen (Say a logger) [10:28] <Ajith_> the second type is the types of rules that need to be evaluated in a loop - Where the message gets processed over and over in the rule processor [10:28] <Ajith_> the third type is the type of rule that needs to execute after all this happens [10:28] <Vikas> say.. mark all requests which leave synapse [10:28] * gdaniels thinks Ajith hit "paste" :) [10:29] <Ajith_> GlenD : yes it was for paul actually [10:29] <Vikas> now all rules which are not dependent on the property being considered [10:29] <Vikas> so we can segregate the mediators[the rules which refer to them] into phases [10:30] <Vikas> if the mediator changes a particular propety(which can cause new rules to evaluate to true] it goes into the processing phase [10:30] <paulfremantle> so i guess another way of doing this would be to mark the mediators with metadata [10:31] <gdaniels> In-phase rules are basically rules for which the condition is "*"? [10:31] <Deepal> yup , most of the time [10:31] <Ajith_> Paul : Hmmm... with what kind of Meta Data ? [10:31] <saminda> so this can eliminate "int" retrun from mediators right [10:31] <Vikas> the rules / mediators which come before that mediator and are independent of the property will also fall into the in-phase [10:31] <paulfremantle> maybe a marker on what it changes [10:31] <Ajith_> saminda : yes [10:31] <Deepal> Pual : I think we should try to meke mediator as much as simple [10:32] <paulfremantle> yes i agree [10:32] <Deepal> meaning that we can not always assume that user do the right thing [10:32] <gdaniels> Vikas: didn't understand that last [10:32] <Deepal> so most of the logic processing should be done by Synapse core [10:32] <Vikas> ya [10:33] <Deepal> in axis2 we have not give much of work to service writer [10:33] <Deepal> so same thing shuld apply to mediator too (this is wt I think) [10:33] <gdaniels> Deepla: In Axis2 all the work is done by the handlers [10:33] <gdaniels> s/Deepla/Deepal/ [10:34] <Deepal> :) [10:34] <Deepal> glen : if Im understad corrct each rule finally endup beaing a axisEngine [10:34] <Deepal> with some kind of flow [10:34] <Deepal> being [10:35] <Deepal> inflowhandler : MR : mediator [10:35] <Vikas> [glen]the inPhase/outPhase are something like the partial chains we were talking in the last IRC.. [10:35] <Deepal> so here mediator is like aixs2 service , isnt it [10:36] <gdaniels> Deepal: right, we've been saying mediators == axis2 services, so that hasn't changed [10:36] <saminda> now in this pic, with every rule we need to fire out a new AxisConfiguration, isn't it [10:36] <Deepal> great [10:37] <Vikas> ya [10:37] <gdaniels> saminda: "fire out a new AxisConfiguration"? [10:37] <Deepal> so paul : if we try to give metadata to mediator and ask him to do the right thing , will that be OK all the time [10:37] <paulfremantle> well i think the big problem with this [10:38] <paulfremantle> is that there could be two mediators [10:38] <paulfremantle> both modify the wsa:to [10:38] <paulfremantle> and in one case the deployer wants the rules to be evaluated based on new wsa:to [10:38] <paulfremantle> and in the other case the deployer doesnt [10:38] <Ajith_> hmmm.... [10:39] <saminda> every rule should create a new AxisConfiguration, based on pervious Rule [10:39] <paulfremantle> so we have to have some way that the coder or deployer signifies this to synapse [10:39] <Ajith_> based on the previous rule ? No [10:39] <Vikas> there will be no 'based on previous rule' [10:39] <Deepal> Paul : understand , but can not that be done by RuleEngine or SyanpseEngine [10:39] <Ajith_> an axisConfig and a rule are bound 1 to 1 IMHO [10:39] <paulfremantle> yes i agree deepal [10:40] <Vikas> and we can have listeners to reset that mapping if the rules are changed [10:40] <Ajith_> yes [10:40] <Deepal> so my personal feeling is as developer we should do the hard job and [10:40] <Ajith_> which would be rare [10:40] <Deepal> give user to do the simple job [10:40] * gdaniels thinks this is getting way more complicated than it needs to be :( [10:40] <Ajith_> Deepal : sure We agree [10:40] <antelder> vikas: is there no ordering in the rules? [10:41] <Deepal> glen : hmm yes [10:41] <Vikas> we aren't into rule-ordering and hierarchy/priority yet [10:41] <Deepal> I even did not think till today [10:41] <Ajith_> GlenD : ooops ! are we crossing the line ?? [10:41] <Deepal> that this has to that complicated [10:42] <antelder> Would it be possible to have all this rule processing encapsulated somewhere, eg a MessageReceiver like in Pauls picture so that we can have some people prototyping diff rule engines while others get on with the implementing/prottyping the rest of Synapse framework? [10:42] <paulfremantle> +1 ant [10:42] <gdaniels> Personally, I think so, Ajith. But then again I still really prefer the dead-simple approch where we simply dispatch to ONE component and then if more complex rule processing wants to happen, that component can do the job internally. [10:42] <Deepal> +1 [10:42] <saminda> there should be ordering wrt "pre" "processing" "post"
[10:42] <paulfremantle> because i am much more interested in writing mediators [10:42] <Vikas> ant: what you are hinting at is basically the rule-processors [10:43] <Chinthaka> ... [10:43] <paulfremantle> this is definitely moving away from the simple idea of attaching mediation logic to messages using selectors [10:43] <gdaniels> I still think the way to do this is to focus more on the use-cases, starting simple. [10:43] * Deepal41 has joined #apache-synapse [10:43] <Deepal41> sorry [10:44] <gdaniels> Take the most basic form of Synapse, a passthrough. [10:44] <antelder> everyone seemd real kean on use cases last IRC, what happened? [10:44] <Deepal41> did I miss smy [10:44] <Deepal41> smt [10:44] <Deepal41> N/W problem [10:45] <gdaniels> All you need for that is for a message to come into Synapse/Axis and get to a MessageReceiver that sends the message to a hardcoded address, right? [10:45] <Ajith_> A small explanation on the terminology : Rule processing is referred toin the sense of invoking the mediator, not in the sense of only evaluating only the rules [10:45] <gdaniels> s/hardcoded/configured/ [10:45] <Deepal41> so to support that wt the problem with this archi diagram [10:46] <Deepal41> there wont be any looping rules [10:46] <saminda> for the time being.. [10:46] <Ajith_> let me make this straight - I mean the use case [10:47] <Ajith_> what we are looking at is a way of having mediators that only run once (even when reinjected) - Say the logging handler [10:47] <Ajith_> ooops [10:47] <Ajith_> I mean the "logging mediator" [10:47] <Deepal41> ajith ? [10:47] <antelder> glen: so ok, yes? [10:48] <gdaniels> (scribbling in background) [10:48] <paulfremantle> so let me try to replay the proposed model [10:48] <Deepal41> great :) [10:49] <paulfremantle> 1. the rule engine has three phases [10:49] <paulfremantle> 2. the first phase executes all rules without ordering [10:49] <paulfremantle> 2b. always [10:49] <paulfremantle> 3. the second phase always re-injects messages? [10:50] <Deepal41> paul: they will be excute in order [10:50] <Chinthaka> Paul : is it ? [10:50] <Ajith_> to the second phase itself [10:50] <Chinthaka> the first phase will contain mediators [10:50] <paulfremantle> can you point out which line your comments are aimed at [10:50] <Chinthaka> which do not repeat [10:50] <Deepal41> Paul : I mean phse 1 [10:50] <paulfremantle> ok i see thanks deepal [10:51] <antelder> i don't see? [10:51] <paulfremantle> 2. the first phase executes all mediators in that phase with ordering [10:51] <paulfremantle> is that better [10:51] <Vikas> ya [10:51] <antelder> 2: rules or mediators? [10:52] <Vikas> [rules decide the mediators..] [10:52] <paulfremantle> well i think mediators, because i understood that all the things in phase 1 are * [10:52] <paulfremantle> ie. they match all messages [10:52] <saminda> mediators pertaining to that rule [10:52] <Chinthaka> Paul : well the condition for phase 1 mediators should be, IMO, is that they should not repeat [10:52] <antelder> so phase 1 doesn't need rules at all then, just a set of mediators? [10:53] <paulfremantle> so guys [10:53] <paulfremantle> i think i have a meta proposal [10:53] <paulfremantle> it seems to me that what you are trying to do here [10:53] <paulfremantle> is define a way of saying WHERE messages should be reinjected [10:54] <Vikas> positive [10:54] <saminda> phase 1 need rules to create the "chain" of rules in phase 1 [10:54] <paulfremantle> so..... [10:54] <gdaniels> (paul: that's what I meant by "entry points" before) [10:54] <paulfremantle> yes glen [10:54] <paulfremantle> i just got it [10:54] <Deepal41> Saminda : I did not get u [10:54] <Vikas> look at it as revaluate certain rules and not as re-inject into Synapse [10:54] <paulfremantle> there were a lot of shots last night and im a bit slow [10:54] <Ajith_> :D [10:55] <gdaniels> on a Wednesday night? :) [10:55] <paulfremantle> its a tradition at this conference [10:55] <paulfremantle> weds night at the goat [10:55] <gdaniels> lol [10:55] <sanjiva> hi all .. can I try to explain the picture? [10:55] <paulfremantle> its not a long tradition - this is the second year [10:55] <paulfremantle> hi sanjiva [10:55] <Vikas> hi [10:55] <gdaniels> so it's a coincidence still... NEXT year it's a tradition :) [10:55] <sanjiva> sorry was not able to join earlier .. [10:56] <gdaniels> anyway, back to mediating [10:56] <sanjiva> although after all the shots meditating may be more practical [10:56] <gdaniels> :) [10:56] <gdaniels> medicate, mediate, then meditate [10:56] <sanjiva> ah yes :) [10:56] <sanjiva> ok, let me take a shot at this :) [10:57] <sanjiva> So, earlier we had (at least what I gathered from the list) a model like this: [10:57] <paulfremantle> glen I like that [10:57] <sanjiva> .. message comes into synapse [10:57] <sanjiva> .. synapse figures out what rules are satisfied and goes into a loop executing the mediators [10:58] <sanjiva> .. until one of the mediators say "done" (aka I took care of it) or no more rules match [10:58] <paulfremantle> yes [10:58] <sanjiva> So in effect, there was one outer loop [10:58] <sanjiva> The scenario Vikas brought up seemed very real: you want to log messages but if you're looping around then you don't want them logged mult times [10:58] <paulfremantle> yes [10:59] <gdaniels> (unless you do - i.e. for changed messages) [10:59] <paulfremantle> but that wasnt the default behaviour of the old model [10:59] <sanjiva> So the proposal was, trivially, to put some stuff before the loop and some stuff after the loop. Phases are born: pre-loop phase, the loop-phase and post-loop phase. [11:00] <sanjiva> now when u define a rule, you need 3 things: condition, phase, mediator. So if the condition matches then the mediator is executable in the given phase. [11:00] <sanjiva> That's it. No rocket science ... [11:00] <gdaniels> you can also just do this with the rules themselves, right? [11:01] <paulfremantle> sanjiva is it: [11:01] <paulfremantle> \"rule"= (phase, condition) -> (mediator) [11:01] <paulfremantle> or [11:01] <paulfremantle> "rule"= (phase, condition) -> (mediator, nextphase) [11:01] <gdaniels> i.e. "if [message just came in from transportListener] log" as opposed to "if [*] log" [11:01] * Deepal has quit IRC (Read error: 110 (Connection timed out)) [11:02] <sanjiva> yes but you'd ask the user to do a bit more work. Again, not a huge big deal but it seemed reasonable to say sometimes you have some stuff that's to be done without a fancy honking rule engine etc. [11:02] <gdaniels> paul: I think the suggestion was to have fixed phases, not customizable ones... so nextphase wouldn't be necessary [11:02] <sanjiva> Right, no next phase stuff: dirt simple phases .. before-loop, loop, after-loop. That's *it*. [11:02] <gdaniels> the "loop" phase would act like our current model - keep going until someone says done [11:02] <sanjiva> +1 [11:02] <gdaniels> oop, it's WSDL time [11:03] <paulfremantle> so in the first phase EVERY mediator would be run? [11:03] <gdaniels> no [11:04] <gdaniels> every rule in the initial phase would run [11:04] <gdaniels> if the rule conditions match, then those mediators would go [11:04] <paulfremantle> so in the middle phase after every mediator the message is rematched?? [11:04] * dims wonders if there is any prior art that we can learn from [11:04] <gdaniels> paul: yes [11:04] <antelder> can phase1 mediators return false [11:04] <antelder> ? [11:04] <gdaniels> but only against the rules in the middle phase [11:04] <paulfremantle> dims: aspectj pointcuts is the prior art I think [11:04] <gdaniels> ant: hehehe [11:05] <Ajith_> ping! [11:05] <Deepal41> are we done , I am not getitng any thing [11:05] <Vikas> [anyone of the mediators can return false] [11:05] <saminda> ping [11:05] * dims googling [11:05] <sanjiva> mediators can return false but I think the init phase stuff need to all execute. Need to think more. [11:06] <sanjiva> Time to call it quits? These guys need to go get dinner :) [11:06] <sanjiva> Plus it is WSDL time .. [11:06] <paulfremantle> yes [11:06] <paulfremantle> i will post comments on the mailing list [11:06] <dims> bye all [11:06] <sanjiva> bye [11:06] <dims> someone please add these to the wiki [11:06] <dims> s/these/decisions/ [11:06] <gdaniels> Who's posting the log? [11:06] <gdaniels> I can do it unless someone else is planning to [11:06] <paulfremantle> i wasnt here at the start [11:07] <paulfremantle> so please do glen [11:07] <gdaniels> +1, will do. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
