----- Original Message -----
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
[EMAIL PROTECTED]"Oxygenating
the Web Service Platform",
www.wso2.com