synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Abeyruwan <>
Subject Re: More on the processor/mediator divide
Date Fri, 06 Jan 2006 10:49:29 GMT

On 1/6/06, Paul Fremantle <> 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
> "Oxygenating the Web Service Platform",

View raw message