synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject IRC chat log on 13 October 2005
Date Thu, 13 Oct 2005 16:08:59 GMT
<antelder> hi
<paulfremantle> hi ant
<Harry> hi
<paulfremantle> hi
<saminda> Hi
<Harry> we'll be starting by another 30 / 20 mins right
<paulfremantle> yep
<paulfremantle> no 10?
<saminda> could we start now
<saminda> it's 8.00 pm here though
<paulfremantle> is it???
<antelder> is someone going to post a log? (never seem to be axis2 chat logs
posted these days)
<paulfremantle> are you volunteering?
<antelder> ok
<paulfremantle> :-)
<saminda> cool
<saminda> actually, we post axis2 logs
<saminda> ok, last week we didn't have the axis2 chat
<antelder> oh ok, i'm never sure if they go ahead or not
<saminda> they are going ahead, i assure you
<saminda> what would be the main topics tonight?
<paulfremantle> i think the main topic is early coding
<Harry> early coding ?
<saminda> before going to that, pls elaborate the true nature of the
mediators return value "true/false"
<paulfremantle> sure
<paulfremantle> well Saminda has posted some sample code
<paulfremantle> I am about to upload some
<saminda> cool
<saminda> there is a little ambiguity with the mediators retrun, could we
settle down it first
<paulfremantle> yes
<saminda> Paul, what is the url for take a checkout
<paulfremantle> also I would be interested in ideas from the Infravio team
on how the contributed code can be used in the F2F design
<paulfremantle> tho maybe that is for a later chat
<antelder> a return of false means the Mediator has consumed the MC and
Synapse should do nothing further with it?
<saminda> ok
<saminda> then, how should a mediator know to send "true", another rule if
exist
<saminda> my guess is that we should put the entire rule set pertaining to a
"message" and let the mediator to be inteligent
<saminda> we can use MessgeContext.setProperty(), through out the session
* pvikas has joined #apache-synapse
<paulfremantle> but the point is a rule itself can decide to end the flow
<paulfremantle> imagine a security rule
<paulfremantle> it finds a flaw and "kills" the message
<saminda> how a rule should decide ending a flow?
<paulfremantle> well the behaviour of the rule will be coded
<pvikas> sorry to interrupt..bu then should not the idea of a "end" be
decided by the rule engine
<paulfremantle> and the deployer will then choose that rule based on its
behaviour
<pvikas> mediators are like anyother service...
<pvikas> why put in extra sense...
<Harry> rule engine might be response for executing the rules ..,
<paulfremantle> because we need to be able to signal to the engine that this
message has been consumed by the mediator
<pvikas> do u mean..finished processing / that i am the endpoint??
<saminda> so Paul, some rules should be spcial
<saminda> and the mediator should know what do with it
<Harry> I think the mediatators and the rules should be seperate ..
<Harry> it should be in the engines control
<pvikas> calling a mediaton shld be like calling an ordinary
service..nothing special/nothing more..
<paulfremantle> not true, because multiple mediations may be called in turn
<paulfremantle> by the engine
<paulfremantle> a service consumes the message
<paulfremantle> but a mediator doesnt
<paulfremantle> except in some circumstances
<saminda> mediators and rules are different beasts but mediators should be
inteligent enough to takle with it
<Harry> yeah the mediations are called by the engine and the mediation has
some set of rules .. so the engine has the control over the call ??
<pvikas> that would make them seem less generic..
<paulfremantle> exactly
<paulfremantle> the engine has overall control
<paulfremantle> but the mediator needs to be able to signal to the engine
<pvikas> its like: a security mediation is called..
<pvikas> auth fails
<pvikas> so drop processing..
<paulfremantle> exactly
<saminda> return false
<pvikas> so no more rules are executed
<saminda> what if more rules are there pertaining to that service
* sanjiva has quit IRC (Read error: 110 (Connection timed out))
<pvikas> same doubt here
<saminda> sorry, service==messgae
<pvikas> say auth sucess goto service1
<pvikas> auth fails goto service2
<pvikas> if these r my rules
<pvikas> i ll never leave any scope for their evaluation
<pvikas> cause..false means stop eval of rules
<paulfremantle> saminda if there are more matching rules for that message it
doesnt matter. It is up to the deployer to order the rules correctly
<pvikas> but this scenario can be evaluated only after the mediation
returns..
<saminda> yes
<pvikas> and a false value return halts rule eval
<pvikas> so i am getting nowhere
<Harry> so the mediator would return a false if all rules fails ..
<paulfremantle> if you want that behaviour you can do two things
<paulfremantle> one is to code a mediation that implements that behavior
<paulfremantle> the second is to create a auth rule that doesnt kill the
message but marks it instead
<paulfremantle> and then route based on the marker
<pvikas> but then that would kill flexibility..
<Harry> paul : but why should that be done at the mediator level should that
be in the rule itself
<paulfremantle> the rule is just an expression+a mediator
<pvikas> rules shld be flexible enough to lend dynamism
<pvikas> say: if From=x goto service1
<pvikas> if fro=y goto service2
<paulfremantle> yes they do
<antelder> pvikas: would you prefer the Mediator have a void return and the
only way is for a mediator to set a flag in the MC?
<pvikas> the pt i am trying to put across is..
<pvikas> dont stop eval of rules based on true/false by mediaions
<pvikas> let the engine be intelligent enough
<pvikas> go by the rules
<paulfremantle> but that is the rules
<paulfremantle> the rule (i.e. the mediator) tells the engine
<saminda> so you are saying after a mediation, whether it's successful or
not let the rule engine to handle the multiple rules
<pvikas> ya
<Harry> +1 saminda
<paulfremantle> but
<paulfremantle> then the rule deployer has to know the behaviour of every
matching rule
<paulfremantle> suppose I want to deploy a rule
<paulfremantle> if message from ant then spam
<paulfremantle> then i have no way of stopping other rules from firing
<pvikas> well isnt that the reason we need a powerful and intelligent
engine...
<paulfremantle> except to check every rule
<paulfremantle> the intelligence is just code
<paulfremantle> and the code has to be able to either let the message
continue or not
<pvikas> ya.. and the way we work on the rules in it
<paulfremantle> if the code cant do that
<paulfremantle> how can we make the system useful
<antelder> can't you have a mediator that sets a MC flag for msgs from me
and have a rule if MCflag(X) then stop
<Harry> antelder's ideas seems to be good
<paulfremantle> but its just the same
<saminda> it's the same as sending "false/true"
<pvikas> sort of a work-around the issue
<antelder> yes I agree its very similar either way
<pvikas> no..the eval is done by the engine in this case
<paulfremantle> no
<saminda> no
<paulfremantle> the eval is still done by the engine
<paulfremantle> in both cases
<Harry> saminda ( true / false ) will be sent by the Mediator which is
different
<paulfremantle> so this is important.... the engine is simple, the mediators
are clever
<pvikas> make engine clever/mediations simple
<pvikas> ppl would like to make their own mediatios...
<paulfremantle> yes
<pvikas> keep it simple
<paulfremantle> vikas
<saminda> i think Paul is right
<paulfremantle> the idea is that the engine matches
<paulfremantle> and calls the user mediation code
<paulfremantle> which can be simple
<paulfremantle> or complex
<paulfremantle> but the matching engine has to be simple
<paulfremantle> because then it has a clear model
<paulfremantle> and can be used easily
<paulfremantle> the engine can't "know" what to do with a message
<paulfremantle> that is up to the rules and mediations that are deployed
<paulfremantle> so the mediations must be able to signal to the engine what
to do
<saminda> if we can allow mediators to be more intellegent and engine to
simple, that's pretty cool
* kar has quit IRC ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040803]")
<saminda> Paul, tha's my point mate
<Harry> paul + saminda can u please give us an example
<paulfremantle> so the engine has a really simple model
<paulfremantle> if message.matches then mediate(message)
<paulfremantle> if response = true keep going
<saminda> let say we have 4 rules petaining to wsa:to=http://abs.org
<paulfremantle> now using that model I can create a ruleset that does
anything you like
<saminda> and whith defferent mediator
<saminda> allowing mediators to be intellgent allows engine to do the
looping
<saminda> or send it to it's destination
<antelder> a bit low level, but in the prototype code it makes a new MC
before calling each Mediator. Is that really reqd, can't all the Mediators
work on the same MC?
<pvikas> but wouldn't making the engine intelligent allow us to use the
mediations designed by others with more flexibility
<saminda> yes, in axis2 notion
<saminda> see the defintion of MC is per message
<paulfremantle> vikas
<paulfremantle> you have to explain to me how you would make the engine more
intelligent
* Chinthaka has joined #apache-synapse
<Chinthaka> hi all
<paulfremantle> hi Chinthaka
<Chinthaka> is it over ?
<paulfremantle> no we are in full swing
<saminda> Hi Chinthaka aiya
<antelder> hi Chinthaka
<Harry> hi chinthaka u have entered at the right time
<pvikas> hi..
<Chinthaka> :)
<pvikas> consider ants idea.. mediations return void and sets flags
<paulfremantle> ok
<antelder> saminda: but isn't the point that the Mediators are all operating
on the same msg?
<pvikas> the rule-engine looks up the conditions in the rules and evals...
<pvikas> it compares the mentioned flag
<Chinthaka> Mediators opearte on the same message, but not on the same msg
ctx
<pvikas> executes the corresponding thing
<pvikas> executes the corresponding thing
<pvikas> say call mediation/service
<antelder> can you explain why not the same MC?
<paulfremantle> so vikas
<paulfremantle> at the moment
<paulfremantle> the model is
<Chinthaka> ant : message context, by definition is for one invocation
<paulfremantle> rule = expr + mediation
<paulfremantle> expr = xpath match on message
<paulfremantle> mediation = logic
<paulfremantle> so there is no flag until the mediation executes
<pvikas> ya..
<pvikas> but if the mediation returns false..
<pvikas> u ll never look for the flag/condition
<antelder> but aren't mediators are in some respects like handlers, and you
dont make a new MC for calling each handler?
<Chinthaka> ant : are u sure ?
<Chinthaka> mediators are not handlers but services
<paulfremantle> but vikas.... the engine looks for the condition when the
mediation returns
<Chinthaka> QoS stuff are modules
<Chinthaka> QoS stuff = RM, Sec, etc
<paulfremantle> it is just the same whether it looks at return value or
messagecontext.getproperty
<pvikas> but then the return value might stop the eval of rules itself
<pvikas> i might never get to the rule...
<paulfremantle> suppose there are three rules
<paulfremantle> 1. log everything
<paulfremantle> 2. if message comes from ant then stop
<paulfremantle> 3. send to paul
<paulfremantle> then engine executes 1
<paulfremantle> return is true so it executes 2
<paulfremantle> message is from ant
<paulfremantle> so return is false
<paulfremantle> engine then discards message
<pvikas> look at this scenario
<pvikas> rules:
<pvikas> 1) msg from x call mediation1
<paulfremantle> rule 3 only gets executed if message is not from ant
<pvikas> say a credit card thingy..quite a common realworld usecase
<Chinthaka> Paul : Basically the true or false means whether we execute more
rule on the message or not .. Isn't it ?
<pvikas> 2)if expired_flag=true goto reportabuse
<pvikas> 3)if expired_flag=false gotobank_service
<paulfremantle> chinthaka yes
<saminda> yes
<pvikas> now the mediation might be by the credit_card company
<pvikas> i cant ask them to return a true/false..they do their thing their
way
<pvikas> so i put in rules
<pvikas> thats flexibility and reusability
<saminda> can mediator dynamically allow what rule should execute
<pvikas> i wouldn't bank on that
<paulfremantle> vikas
<paulfremantle> the mediator they write is written to the synapse
<paulfremantle> model
<paulfremantle> pvikas: i cant ask them to return a true/false..they do
their thing their way
<paulfremantle> i dont understand that line
<pvikas> i was on ant's lines..say void return
<antelder> I'll have to go on another call shortly. I'd be interested in
what everyones plans are for participating over the next few weeks?
<Chinthaka> Ant : I will be there
<pvikas> me too..
<Chinthaka> BTW, Axis2 is on progress
<pvikas> why not try coding samples ...
<paulfremantle> i have written a little test framework
<paulfremantle> which i will checkin to SVN tofday
<paulfremantle> today
<antelder> I mean is there going to be a code base being developed?
<Chinthaka> and we are on track for 1.0
<paulfremantle> great :-)
<pvikas> {paul} for synapse??
<saminda> code i wrote is at
https://svn.apache.org/repos/asf/webservices/axis2/trunk/archive/java/scratch
<paulfremantle> yes
<pvikas> cool
<paulfremantle> saminda i havent had a chance to look ye
<paulfremantle> we can swap code :)
<saminda> wouldn't it be nice to have a scratch area for synapse too
<Chinthaka> ohh Saminda why did u put it there ?
<saminda> for the time being aiya, will move to another location shortly
<Chinthaka> no we have a Synapse place
<paulfremantle> you should put it
<paulfremantle> https://svn.apache.org/repos/asf/incubator/synapse/
<Chinthaka> let me check
<antelder> the AXIS2 MC has abstractions over some SOAP stuff like for WSA.
So must a mediator doing WSA things use the MC methods, or can it go
directly to the headers in the SOAP
envelope?
<saminda> we upload there and remove from the old plase asap
<paulfremantle> ant good question
<paulfremantle> i would like to prototype two options
<paulfremantle> one...
<paulfremantle> only uses the SOAPEnvelope
<paulfremantle> two....
<Chinthaka> ant : what I meant was msgCtx has a hook to the Synapsecontext
<paulfremantle> uses messagecontext
<Chinthaka> Paul : IMHO, u need some context
<paulfremantle> chinthaka
<antelder> Chinthaka:? i thought Synapse was going to use the AXIS2 MC?
<paulfremantle> probably
<Chinthaka> it may be one of the existing Axis2 contexts or Synapse own one
<Chinthaka> yes it will
<pvikas> +1 for synapseContext
<Chinthaka> but no one to one mapping
<saminda> for the scope of M1, we can use the Axis2's MC
<Chinthaka> Saminda : it is not good I think
<Chinthaka> MsgCtx can hold only one op context
<antelder> is it so hard to sort out the Mediator interface sooner ?
<Chinthaka> once u set, there is no way to remove it
<paulfremantle> -1 to having to copy data from one MC to another :-)
<antelder> paul: i agree
<saminda> antelder: yes whole Envelope is open for you
<pvikas> +1 for paul
<Chinthaka> Paul : u didn't get my point
<paulfremantle> i didnt!
<antelder> saminda: but then don't the MC getWSAXxx get out of date?
<Chinthaka> what I say is, Synapse context will hold the information
required for invocations
<Chinthaka> for example Synapse context, is like our Service Group Context
<Chinthaka> our = Axis2 :)
<paulfremantle> ah i see what you mean
<Chinthaka> Mediators are services
<Chinthaka> and all these services belons to one service group
<saminda> yes
<Chinthaka> belons = belongs
<paulfremantle> but another way of looking at it is that the service itself
doesnt see the context in Axis2
<paulfremantle> it only sees the body of the messag
<paulfremantle> e
<Chinthaka> that depends on the message receiver
<paulfremantle> i know
<Chinthaka> message receiver gets the context
<paulfremantle> but what im saying is that a synapsemessagerecieveer could
get an Axis2 MC
<Chinthaka> and he has the option of passing anything to the mediator
<saminda> now mediator ask for MC, so it get the whole envelope
<Chinthaka> Paul : ....
<paulfremantle> but then only passes on envelope to mediator
* Harry has quit IRC (Nick collision from services.)
<paulfremantle> its an option
<Chinthaka> Ok, I agree
<pvikas> same here
<paulfremantle> i would like to see both options
<paulfremantle> and understand the tradeoffs
<Chinthaka> BUT, from Axis2 experience
<Chinthaka> some times Services need the whole MC
* Harry_ has joined #apache-synapse
<Chinthaka> thats why we had MC injection in Axis2
<Chinthaka> but for a starter I'm ok with SOAPEnvelope
<saminda> full flexiblility
<paulfremantle> so that is a good reason why ants idea of MC injection is
good
<saminda> MC would be fine
<paulfremantle> because in many cases it isnt needed
<Chinthaka> Paul : didn't get that :(
<Harry_> me too
<pvikas> ??
<saminda> see if mediator to be more smart we need MC
<antelder> * I'm away, but will leave this up
<paulfremantle> so ant proposed that Mediator is
<paulfremantle> mediate(OMElement envelope)
<paulfremantle> and if it needs context
<paulfremantle> then it exposes
<pvikas> [let me confirm]MC=messageContext
<Chinthaka> Vikas : yes :)
<paulfremantle> public void setContext(MessageContext mc)
<saminda> yes, mate
<saminda> IOC
<pvikas> cool
<paulfremantle> yes
<saminda> i'm good with that
<Chinthaka> hmm, got it
<paulfremantle> and it makes the simple mediations simpler
<Chinthaka> so what you say is MR (Message Receiver)
<paulfremantle> and it also means that we can do unit test on mediations
with only a dependency on Axiom
<saminda> Just modiyfing the SynapseMessageReceiver just a little
<Chinthaka> always do Mediator.setMC(MC)
<pvikas> ya
<paulfremantle> yes if that exists
<Chinthaka> before calling Mediator.invoke(SOAPEnvelope)
<Chinthaka> ?
<paulfremantle> YES
<saminda> shouldn't it be Mediator.mediate(SOAPEnvelpe) :)
<paulfremantle> maybe
<paulfremantle> whats the difference?
<Chinthaka> Saminda : Sorry. It shoud be mediate
<saminda> we have the Mediator interface already
<saminda> and all mediators should implement it
<Harry_> yes
<saminda> it will make mediators more unique
<paulfremantle> yes all mediators can implement it
<paulfremantle> and if they want MC they can implement another interface
Contextual
<paulfremantle> public interface Contextual {
<paulfremantle> public setMC(MC mc)
<paulfremantle> }
<saminda> hey Paul, we have IOC
<Harry_> can someone please tell me the process flow
<saminda> guys, it's past 9.00 pm is Sri Lankan time
<pvikas> 9:45 in india
<saminda> what
<Chinthaka> If u r at office, time to go home :)
<saminda> i'm at the office
<pvikas> must be arnd 9:20 in SL
<saminda> aha you know Sri Lankan time :)
<Chinthaka> created the scratch area for synapse here :
https://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch
<saminda> cool
<paulfremantle> ok
<Chinthaka> so Saminda and Paul can commit the code there
<saminda> will do
<Chinthaka> better create folders from your names
<Chinthaka> as we did in Axis2
<saminda> will do
<pvikas> ok
<paulfremantle> ok
<paulfremantle> great lets continue this on email
<pvikas> can someone mail the complete log..
<antelder> yes
<Chinthaka> and put in the wiki too
<saminda> good ant
<Chinthaka> please :)
<paulfremantle> thanks
<pvikas> thanks a ton
<Chinthaka> thanks ant ...
<saminda> so our ingeral chat when good, isn't it
<Chinthaka> done for the day ?
<pvikas> +1
<saminda> me too +1
<Harry_> and one small suggesion .. when someone is taking let them type the
whole thing say a <done> and then others can proceed :)
<paulfremantle> sounds good harry
<saminda> <done>
<paulfremantle> <done>
<pvikas> we did have paralel convs going on..bit distractiong
<Chinthaka> Harry ... Normally cross communications happen
<pvikas> <done>
<Chinthaka> during IRC, I don't think its a problem
<Harry_> yeah .... but ina way we can try to do :)
<Chinthaka> some more overhead ;)
<Harry_> ;)
<pvikas> haha
<Chinthaka> ok guys, since we r done for the day, bye for now
<Chinthaka> see u all in mailing list :)
<pvikas> bye
<Harry_> bye chinthaka
<Chinthaka> bye all
<saminda> bye guys, <done>
<Chinthaka> <done> :)
* saminda has quit IRC ("Leaving")
* sanjiva has joined #apache-synapse
<pvikas> [its on, but i ll be gone] <done>
<sanjiva> hi guys ..
<Harry_> hi
<sanjiva> did u guys just finish? :)
<paulfremantle> hi
<paulfremantle> yes
<sanjiva> ah ok :) sorry to have missed it ...
<sanjiva> I assume smeone will post a log?
<paulfremantle> yep ant is doing it
<Harry_> rcom ?? u there
<paulfremantle> does someone want to give me svn advice ?
<Harry_> one question paul
<paulfremantle> sure
<Harry_> what's that someone was telling u that maintain the directories
with there own names ? just the way as axis1
<Harry_> sorry axis2
<paulfremantle> they meant
<paulfremantle> scratch/paul
<paulfremantle> scratch/harry
<paulfremantle> etc
<Harry_> and put there stuff in there directory
<paulfremantle> yes
<Harry_> ok
* paulfremantle has left #apache-synapse
<Harry_> Okay guys am out .. bye
* Harry_ has quit IRC ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040803]")
* pvikas has quit IRC ("ChatZilla 0.9.61 [Mozilla rv:1.7.12/20050915]")
* Chinthaka has quit IRC ("Chatzilla 0.9.68.5 <http://0.9.68.5> [Firefox
1.0.6/20050716]")

Mime
View raw message