synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <>
Subject chat log
Date Thu, 12 Jan 2006 14:15:31 GMT
[13:09] gdaniels: good morning, fols
[13:09] gdaniels: folks
[13:09] paulfremantle: hey!
[13:09] paulfremantle: hi Glen
[13:09] saminda_: Hi
[13:10] paulfremantle: so i have a few things to talk about today!!!
[13:10] paulfremantle: 1. M1 release
[13:10] gdaniels: Really?
[13:10] paulfremantle: 2. Classmediator -> mediator
[13:10] gdaniels: I am so surprised because you're usually so reticent,
[13:10] *** pvikas has joined #apache-synapse.
[13:10] paulfremantle: lol yeah
[13:11] paulfremantle: im nearly as quiet as you Glen :)
[13:11] gdaniels: :)
[13:11] pvikas: [did i miss a joke]
[13:11] pvikas: hi
[13:11] paulfremantle: 3. servicemediator
[13:11] paulfremantle: 4. mediator properties
[13:11] paulfremantle: 5. switch processing
[13:11] gdaniels: Hey Vikas :)
[13:12] paulfremantle: hi Vikas
[13:12] pvikas: whats being discussed?
[13:12] paulfremantle: well i have some suggestions
[13:12] paulfremantle: but before i repeat them
[13:13] paulfremantle: who else has things they want on the agenda
[13:13] *** Hariharasudhan has joined #apache-synapse.
[13:13] gdaniels: did we finish the mediator/processor discussion?  I need
to catch up on the emails....
[13:13] Hariharasudhan: hi guys
[13:14] paulfremantle: hi Hari
[13:14] Hariharasudhan: hi paul
[13:14] pvikas: i think the final idea is to settle for the terms
mediators/mediator factory.. no 'processors' [hope i got it right]
[13:14] paulfremantle: thats the way the email has been going
[13:15] gdaniels: ok...
[13:15] gdaniels: so a QName in synapse.xml maps to a MediatorFactory then?
[13:16] paulfremantle: yes
[13:16] paulfremantle: exactly
[13:16] gdaniels: and that thing reads the XML inside and generates/finds
the right Mediator?
[13:16] paulfremantle: yes
[13:17] gdaniels: okee
[13:17] pvikas: there is only one instance of the mediator??
[13:18] paulfremantle: yes
[13:18] saminda_: umm..<regex/> is kind a composite mediator right
[13:18] paulfremantle: each instance is designed to handle multiple
mediate() invocations at the same time
[13:18] paulfremantle: yes there are composite mediators and non-composite
[13:19] saminda_: yes
[13:19] paulfremantle: but the framework doesn't worry about that because it
simply calls mediate
[13:19] saminda_: understand
[13:19] paulfremantle: the composite nature is "hidden" inside that mediator
[13:19] pvikas: [this is coming out-of turn] when is M1 release planned??
[13:20] saminda_: so what is the different between <classmediator/> and
[13:20] paulfremantle: well i was planning M1 release tuesday or before
[13:21] saminda_: if a <foo/> element is map to a Mediator, how are we gonna
introduce properies to a mediator via synapse.xml
[13:21] paulfremantle: ah
[13:21] *** saminda has signed off IRC (Read error: 113 (No route to host)).
[13:21] *** sanjiva has signed off IRC (Read error: 113 (No route to host)).
[13:21] paulfremantle: so we ought to support a simple way of doing
[13:21] paulfremantle: here is my proposal
[13:21] paulfremantle: <mediator .....>
[13:22] paulfremantle:    <property name="foo">
[13:22] paulfremantle:      value
[13:22] paulfremantle: </property>
[13:22] paulfremantle: </mediator>
[13:22] paulfremantle: this causes synapse to do
[13:22] paulfremantle: mediator.setFoo("value");
[13:23] paulfremantle: just after it instantiates mediator
[13:23] paulfremantle: and before it calls mediator.mediate() for the first
[13:23] pvikas: IMHO, mediator.setProperty("FOO",value);
[13:24] paulfremantle: the reason I propose setFoo()
[13:24] paulfremantle: is because (1) i like dependency injection systems
like Spring
[13:24] paulfremantle: (2) Axis2 has a similar model
[13:24] paulfremantle: (3) because it keeps the mediator interface as simple
as possible
[13:25] saminda_: so the check will be on <property/> right
[13:25] paulfremantle: yes that is the proposal
[13:25] saminda_: i like it
[13:26] paulfremantle: glen.... i know you have thoughts on dependency
injection :)
[13:27] saminda_: so what's on your mind with prior
[13:27] pvikas: What happes if the mediator requires complex objects
[13:27] paulfremantle: ah
[13:27] paulfremantle: so we could either
[13:28] paulfremantle: 1) wait till we need it
[13:28] paulfremantle: 2) say if you need complex objects you need to write
a MediatorFactory and a new xml tag
[13:28] paulfremantle: or 3) we could allow complex XML inside <property>
[13:28] paulfremantle: and then call
[13:28] paulfremantle: setFoo(OMElement)
[13:28] gdaniels: (sorry was distracted by real life here for a few...
reading back the log...)
[13:30] gdaniels: hm
[13:30] pvikas: do you think we can decouple the configuration details from
the mediator so that is generic and can be shared between mediators
[13:30] gdaniels: I have a couple of questions/comments
[13:30] paulfremantle: go ahead !
[13:30] gdaniels: 1) if you like setFoo(), why wouldn't you also want
<foo>value</foo> instead of <property>? :)
[13:31] paulfremantle: hmmmm because <property> is like all the other dep
inj systems so it would be consistent
[13:31] gdaniels: 2) Generic properties (or at least having a way to do
generic properties) allows you to extend components without changing their
interfaces.  That can be nice.
[13:31] gdaniels: i.e. setProperty(String, Object) is a pretty handy thing
[13:32] gdaniels: it's DEFINITELY the way to go for MessageContext type
usage... not sure about Mediators
[13:32] paulfremantle: i agree for MC usage
[13:32] paulfremantle: for Mediators I prefer the injection approach.... but
I completely admit is just preference
[13:32] paulfremantle: both are good ways
[13:33] gdaniels: I think the question is - is there a use case where you'd
want to set a property on a Mediator that hasn't been defined in the
Mediator's Java interface?
[13:33] paulfremantle: thats a good question
[13:33] gdaniels: And the answer for me lies in the "scoped" mediators
[13:33] paulfremantle: scoped?
[13:34] gdaniels: i.e. if we can have Mediators that "contain" others, it
really might be useful to pass a property that the top layer one doesnt
understand down
[13:34] gdaniels: by setting on the top one instead of on each individual
[13:34] gdaniels: does that make sense?
[13:34] paulfremantle: true.... but all of those mediators
[13:34] paulfremantle: are done using mediator factories
[13:34] paulfremantle: (at least so far)
[13:35] gdaniels: ok - don't see how that relates yet
[13:37] gdaniels: paul?  you thinking or did you get pulled away?
[13:38] paulfremantle: sorry someone called me :)
[13:38] gdaniels: (figured :))
[13:38] paulfremantle: what i mean is i imagined the property tag only
applied to <mediator>
[13:39] paulfremantle: not <regex> or <stage> or whatever
[13:39] saminda_: if it the case, we dont have a situation what Glen has
[13:39] pvikas: Guys, think of  a situation where we do a client
Authentication and enforce a Service Level Aggrement..
[13:39] pvikas: We have 2 mediators one does Client Identification other
does SLA enforcement, both need access to client details.
[13:40] pvikas: Both are independent mediators..hence we would need global
access to values/parameters...
[13:40] gdaniels: but wouldn't it be nice if it did?  So you could set a
"scoped" property in a <stage> or in a <customThing> with children?
[13:40] saminda_: yes
[13:40] gdaniels: how about this...
[13:41] gdaniels: let's support both syntaxes
[13:41] saminda_: vikas, you will be benifited from SynapseEnvironement
[13:41] paulfremantle: well hold on vikas
[13:41] saminda_: to keep states
[13:41] gdaniels: if we see <foo>, we'll have a framework which allows
easily calling setFoo().  But we can also use <property name value> to set
generic scoped ones.
[13:42] gdaniels: (this is clearer in my head than it sounded)
[13:42] paulfremantle: do you want shared context per instance
[13:42] paulfremantle: or shared context per message
[13:42] paulfremantle: we have shared context per message already
[13:42] gdaniels: if it's configuration-type stuff it's per instance
[13:43] saminda_: Glen's right, what we have is context per instance
[13:44] gdaniels: there is certainly also per-message context
[13:44] gdaniels: but per-instance config is important too
[13:44] paulfremantle: so I think the case Vikas described is per message
[13:44] paulfremantle: thats why I brought it up
[13:45] paulfremantle: I think the scoped property could be really nice
[13:45] saminda_: Paul, per message we initiate Synapse message receiver
[13:45] paulfremantle: but I'd like to hold off till we have a use case
[13:45] saminda_: so if multiple messages needed to be share same
[13:46] saminda_: we need a context above SynapeEnvironment
[13:46] paulfremantle: hold on saminda
[13:47] paulfremantle: that is a very complex scenario you are discussing
[13:47] paulfremantle: where we manage state across interactions
[13:47] paulfremantle: its known as a workflow engine
[13:47] paulfremantle: and there is a great model for that
[13:47] paulfremantle: its called BPEL
[13:49] pvikas: Consumer identification needs to happen before a service
level aggrement can be enforced...SLA is nested within CI [hope u ppl got
the idea] So we would need scoped properties that these two mediators would
[13:49] paulfremantle: vikas
[13:49] paulfremantle: i assume what happens
[13:49] paulfremantle: is that the message arrives
[13:49] paulfremantle: hits the ident med
[13:49] paulfremantle: which sets context on the message
[13:50] paulfremantle: which is read by the SLA med
[13:51] gdaniels: eep - I gotta run guys, sorry!  Will catch up on the
mailing list ASAP.  Talk to you all soon.
[13:51] paulfremantle: isnt that what is needed?
[13:52] *** gdaniels has signed off IRC ().
[13:52] saminda_: i think he needs the states later in for another message,
it is Vikas
[13:53] paulfremantle: well in that case i think its up to the mediator
writer to use a separate state table (i.e. database)
[13:53] paulfremantle: but i didn't think that was vikas scenario
[13:54] pvikas: for SLA we need state across messages as it is independent
of the single request and depends on the relative priority of the clients
who sent in the requests...
[13:54] paulfremantle: but a mediator can keep some state for itself
[13:55] pvikas: so i need client details to be passed from Ident mediator to
SLA mediator on a per message basis and also request details on multiple
[13:55] paulfremantle: so the SLA mediator can manage a measure of the
current hitrate for example
[13:55] saminda_: i hate to say this
[13:55] saminda_: we can Use ConfigurationContext of Axis2 for this
[13:56] saminda_: see when we create SynapseMessage out of MessageContext
[13:56] pvikas: going to the environment or configuration level is not
desireable.... or is it??
[13:56] saminda_: that messagecontext has the ConfiguraitonContext
[13:57] paulfremantle: vikas, saminda
[13:57] saminda_: which will exist for as long as the server is up
[13:57] paulfremantle: i would like a really clear explanation of what
contexts you are requiring
[13:57] saminda_: but we don't use it thought
[13:57] paulfremantle: i think we are mixing LOTS of things up
[13:57] paulfremantle: we started out talking about static config
[13:57] paulfremantle: and ended up talking about SLA management which is
completely dynamic data
[13:57] pvikas: ok, lets stick to that first...
[13:58] paulfremantle: i think we ought to categorise the different
[13:58] saminda_: well the best way is to wait till good use case :)
[13:58] pvikas: <property name="foo"> value</property>
[13:58] pvikas: how do we pass complex objects??
[13:58] paulfremantle: 1) wait till we need it
 [13:28] paulfremantle: 2) say if you need complex objects you need to write
a MediatorFactory and a new xml tag
 [13:28] paulfremantle: or 3) we could allow complex XML inside <property>
[14:00] saminda_: yes we need to wait till we nee it and a use case
[14:00] saminda_: :)
[14:01] pvikas: That's what I was getting at (complex xml)... just wanted to
separate the config details from the mediator so that mediator will  have a
"has a " relation with property.
[14:01] paulfremantle: so either 2 or 3 solves it
[14:02] pvikas: 3.. with properties as a separate entity that can be related
to mediators with a "has a" relation
[14:03] paulfremantle: vikas can you give an example
[14:04] saminda_: mail list perhapse :)
[14:04] paulfremantle: ok we have run out of time
[14:06] saminda_: hows gonna do the honor of mailing the chat :)
[14:06] saminda_: oops who's
[14:06] pvikas: <property name="client id">
[14:06] pvikas:    <ip>some ip</ip>
[14:06] pvikas:    <category>internal</category>
[14:07] pvikas:    <priority>x</priority>
[14:07] pvikas: </property>
[14:07] pvikas: <mediator name="CID"  property="client id">
[14:07] pvikas: ......
[14:07] pvikas: </mediator>
[14:07] pvikas: <mediator name="SLA" property="client id">
[14:07] pvikas: .....
[14:07] pvikas: </mediator>
[14:07] pvikas: this is a quick sample!
[14:07] paulfremantle: ah ok vikas
[14:07] paulfremantle: i get you
[14:07] paulfremantle: just like the ref for mediators
[14:07] pvikas: property can be referenceable...
[14:07] paulfremantle: seems like a cool idea
[14:07] paulfremantle: maybe we can have property's at the top level
[14:07] paulfremantle: and then
[14:08] paulfremantle: <property ref="name">
[14:08] paulfremantle: inside a mediator
[14:08] saminda_: so we alreay has the solution
[14:08] paulfremantle: which uses the higher level setting
[14:08] paulfremantle: nearly.... its not quite the same
[14:08] saminda_: <never/> contains a <property/> ?
[14:08] paulfremantle: something like that
[14:10] saminda_: what is the approach to vikas complex Object
[14:10] paulfremantle: well they are completely orthogona
[14:10] saminda_: are we gonna give a generic one for it
[14:10] paulfremantle: thats why i want some clarity in the discussion
[14:10] pvikas: will try prototyping and sending in something or both the
complex and referenceable properties..
[14:11] paulfremantle: cool
[14:11] paulfremantle: thanks
[14:12] saminda_: owsome mate
[14:14] pvikas: so who is sending the log?? i think paul was there from the

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

"Oxygenating the Web Service Platform",

View raw message