synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <pzf...@gmail.com>
Subject Re: More on the processor/mediator divide
Date Fri, 06 Jan 2006 10:34:36 GMT
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 <deepalk@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 <pzfreo@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

Mime
View raw message