You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2006/01/06 11:12:31 UTC
More on the processor/mediator divide
Folks
Yesterday on the chat I gave a quick overview of the idea of removing the
processor/mediator divide. I don't take credit for this idea. Ant suggested
it - I think it was on a previous chat. Anyway, at the time I didn't like it
much. But since then it has slowly wormed its way into my head.
Here is a better description (I hope).
The idea is that for any given message, it goes to a single instance of a
class that implements the mediator interface. This "master mediator" is
typically a "tree" node - in other words it has references to other
mediators which it executes.
How does the tree of mediators get built?
Well the standard way is this: There is an interface xml.MediatorFactory.
This takes the XML, parses it and creates a Mediator instance. The xml is
just the same as today. The MediatorFactory is pretty much the new name for
the existing ProcessConfigurator interface.
Of course another way of creating a tree of mediators is to new up different
kinds of mediators and then "wire" them together using Java calls. Or
someone could write a different kind of Factory.
So the basic runtime structure is almost the same as today. The user can use
<mediator> tags to use their own mediators (API). The extension writer can
create a new MediatorFactory and Mediator to create a new extension - which
then appears in the XML file as a new tag. The only difference is that the
design is simpler, cleaner, lighter. And then the decision about
processor/mediator is gone.
The only other change is that we need to make sure the SynapseEnvironment is
always available. So to keep the mediator interface simple, we could add a
method onto the SynapseMessage interface -
SynapseMessage.getSynapseEnvironment(). This also means we can ditch the
EnvironmentAware interface so we also make the API simpler too.
Please take time to think this through... and feel free to ask me questions
if I haven't explained it clearly.
Whatever we decide - this won't upset the M1 plan.
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
Re: More on the processor/mediator divide
Posted by Paul Fremantle <pz...@gmail.com>.
Deepal
+1 to your comment.
In fact that is what we do today - we create a single instance of the tree
and then run all messages through it.
Paul
On 1/6/06, Deepal Jayasinghe <de...@gmail.com> wrote:
>
> Hi paul;
>
> +1 for the approach , I added some comment have a look at those
>
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
> ----- Original Message -----
> *From:* Paul Fremantle <pz...@gmail.com>
> *To:* synapse-dev@ws.apache.org
> *Sent:* Friday, January 06, 2006 4:12 PM
> *Subject:* More on the processor/mediator divide
>
> Folks
>
> Yesterday on the chat I gave a quick overview of the idea of removing the
> processor/mediator divide. I don't take credit for this idea. Ant suggested
> it - I think it was on a previous chat. Anyway, at the time I didn't like it
> much. But since then it has slowly wormed its way into my head.
>
> Here is a better description (I hope).
>
> The idea is that for any given message, it goes to a single instance of a
> class that implements the mediator interface. This "master mediator" is
> typically a "tree" node - in other words it has references to other
> mediators which it executes.
>
> How does the tree of mediators get built?
>
> Well the standard way is this: There is an interface xml.MediatorFactory.
> This takes the XML, parses it and creates a Mediator instance. The xml is
> just the same as today. The MediatorFactory is pretty much the new name for
> the existing ProcessConfigurator interface.
>
> >>>>>>>>>>>>
> I think its better rather than creating instance for each invocation ,
> cant we create Mediators at the initiation time and reuse them , I think
> mediators are state less , if they want to keep some status they will do
> them via some kind of context.
> >>>>>>>>>>>>>>
>
> Of course another way of creating a tree of mediators is to new up
> different kinds of mediators and then "wire" them together using Java calls.
> Or someone could write a different kind of Factory.
>
> So the basic runtime structure is almost the same as today. The user can
> use <mediator> tags to use their own mediators (API). The extension writer
> can create a new MediatorFactory and Mediator to create a new extension -
> which then appears in the XML file as a new tag. The only difference is that
> the design is simpler, cleaner, lighter. And then the decision about
> processor/mediator is gone.
>
> The only other change is that we need to make sure the SynapseEnvironment
> is always available. So to keep the mediator interface simple, we could add
> a method onto the SynapseMessage interface -
> SynapseMessage.getSynapseEnvironment (). This also means we can ditch the
> EnvironmentAware interface so we also make the API simpler too.
>
> Please take time to think this through... and feel free to ask me
> questions if I haven't explained it clearly.
>
> Whatever we decide - this won't upset the M1 plan.
>
> 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
Re: More on the processor/mediator divide
Posted by Deepal Jayasinghe <de...@gmail.com>.
Hi paul;
+1 for the approach , I added some comment have a look at those
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: Paul Fremantle
To: synapse-dev@ws.apache.org
Sent: Friday, January 06, 2006 4:12 PM
Subject: More on the processor/mediator divide
Folks
Yesterday on the chat I gave a quick overview of the idea of removing the processor/mediator divide. I don't take credit for this idea. Ant suggested it - I think it was on a previous chat. Anyway, at the time I didn't like it much. But since then it has slowly wormed its way into my head.
Here is a better description (I hope).
The idea is that for any given message, it goes to a single instance of a class that implements the mediator interface. This "master mediator" is typically a "tree" node - in other words it has references to other mediators which it executes.
How does the tree of mediators get built?
Well the standard way is this: There is an interface xml.MediatorFactory. This takes the XML, parses it and creates a Mediator instance. The xml is just the same as today. The MediatorFactory is pretty much the new name for the existing ProcessConfigurator interface.
>>>>>>>>>>>>
I think its better rather than creating instance for each invocation , cant we create Mediators at the initiation time and reuse them , I think mediators are state less , if they want to keep some status they will do them via some kind of context.
>>>>>>>>>>>>>>
Of course another way of creating a tree of mediators is to new up different kinds of mediators and then "wire" them together using Java calls. Or someone could write a different kind of Factory.
So the basic runtime structure is almost the same as today. The user can use <mediator> tags to use their own mediators (API). The extension writer can create a new MediatorFactory and Mediator to create a new extension - which then appears in the XML file as a new tag. The only difference is that the design is simpler, cleaner, lighter. And then the decision about processor/mediator is gone.
The only other change is that we need to make sure the SynapseEnvironment is always available. So to keep the mediator interface simple, we could add a method onto the SynapseMessage interface -
SynapseMessage.getSynapseEnvironment (). This also means we can ditch the EnvironmentAware interface so we also make the API simpler too.
Please take time to think this through... and feel free to ask me questions if I haven't explained it clearly.
Whatever we decide - this won't upset the M1 plan.
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
Re: More on the processor/mediator divide
Posted by ant elder <an...@gmail.com>.
+1 from me (unsurprisingly).
...ant
On 1/6/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> Folks
>
> Yesterday on the chat I gave a quick overview of the idea of removing the
> processor/mediator divide. I don't take credit for this idea. Ant suggested
> it - I think it was on a previous chat. Anyway, at the time I didn't like it
> much. But since then it has slowly wormed its way into my head.
>
> Here is a better description (I hope).
>
> The idea is that for any given message, it goes to a single instance of a
> class that implements the mediator interface. This "master mediator" is
> typically a "tree" node - in other words it has references to other
> mediators which it executes.
>
> How does the tree of mediators get built?
>
> Well the standard way is this: There is an interface xml.MediatorFactory.
> This takes the XML, parses it and creates a Mediator instance. The xml is
> just the same as today. The MediatorFactory is pretty much the new name for
> the existing ProcessConfigurator interface.
>
> Of course another way of creating a tree of mediators is to new up
> different kinds of mediators and then "wire" them together using Java calls.
> Or someone could write a different kind of Factory.
>
> So the basic runtime structure is almost the same as today. The user can
> use <mediator> tags to use their own mediators (API). The extension writer
> can create a new MediatorFactory and Mediator to create a new extension -
> which then appears in the XML file as a new tag. The only difference is that
> the design is simpler, cleaner, lighter. And then the decision about
> processor/mediator is gone.
>
> The only other change is that we need to make sure the SynapseEnvironment
> is always available. So to keep the mediator interface simple, we could add
> a method onto the SynapseMessage interface -
> SynapseMessage.getSynapseEnvironment (). This also means we can ditch the
> EnvironmentAware interface so we also make the API simpler too.
>
> Please take time to think this through... and feel free to ask me
> questions if I haven't explained it clearly.
>
> Whatever we decide - this won't upset the M1 plan.
>
> 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
>
Re: More on the processor/mediator divide
Posted by Saminda Abeyruwan <sa...@gmail.com>.
+1
On 1/6/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> Folks
>
> Yesterday on the chat I gave a quick overview of the idea of removing the
> processor/mediator divide. I don't take credit for this idea. Ant suggested
> it - I think it was on a previous chat. Anyway, at the time I didn't like it
> much. But since then it has slowly wormed its way into my head.
>
> Here is a better description (I hope).
>
> The idea is that for any given message, it goes to a single instance of a
> class that implements the mediator interface. This "master mediator" is
> typically a "tree" node - in other words it has references to other
> mediators which it executes.
>
> How does the tree of mediators get built?
>
> Well the standard way is this: There is an interface xml.MediatorFactory.
> This takes the XML, parses it and creates a Mediator instance. The xml is
> just the same as today. The MediatorFactory is pretty much the new name for
> the existing ProcessConfigurator interface.
>
> Of course another way of creating a tree of mediators is to new up
> different kinds of mediators and then "wire" them together using Java calls.
> Or someone could write a different kind of Factory.
>
> So the basic runtime structure is almost the same as today. The user can
> use <mediator> tags to use their own mediators (API). The extension writer
> can create a new MediatorFactory and Mediator to create a new extension -
> which then appears in the XML file as a new tag. The only difference is that
> the design is simpler, cleaner, lighter. And then the decision about
> processor/mediator is gone.
>
> The only other change is that we need to make sure the SynapseEnvironment
> is always available. So to keep the mediator interface simple, we could add
> a method onto the SynapseMessage interface -
> SynapseMessage.getSynapseEnvironment (). This also means we can ditch the
> EnvironmentAware interface so we also make the API simpler too.
>
> Please take time to think this through... and feel free to ask me
> questions if I haven't explained it clearly.
>
> Whatever we decide - this won't upset the M1 plan.
>
> 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
>