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 2005/11/03 17:01:34 UTC
YASP
Yet Another Synapse Prototype
Ok... Ant and I had a discussion. I personally have yet to be convinced of
the need for the "3 phase" approach. I am meeting F2F with Sanjiva tomorrow
who is going to persuade me :-)
In the meantime, I have taken my first prototype and with some debugging and
good coding advice from Ant I have made it work in Axis2.
The prototype is at
http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/paul2/synapsejoint/
The aim of this is to try out the very simple rule semantics that we talked
about at the first F2F.
The RuleEngine code is this:
public void process(MessageContext messageContext) {
Iterator iterator = rl.iterator();
while (iterator.hasNext()) {
Rule r = (Rule) iterator.next();
Expression e = r.getExpression();
if (e.match(messageContext))
{
boolean cont = MediatorExecutor.execute(r.getMediatorName(),
messageContext);
if (!cont) return;
}
}
// send now
Sender.send(messageContext);
}
Which is pretty much identical to before.
Mediators are deployed as services in Axis2. So it fits the picture I posted
a while ago. (http://fremantle.org/synapse_in_axis.PNG)
The same ruleset gets applied to requests and responses. Here is a sample
ruleset that logs requests and responses and redirects StockQuote queries to
Xmethods.
<rulelist name="rules1"
xmlns:sq="urn:xmethods-delayed-quotes"
xmlns="http://ws.apache.org/synapse/ns/rulelist/1">
<rule xpath="*" mediator="logbean"/>
<rule xpath="//*[Symbol='MSFT']" mediator="dummysq"/>
<rule xpath="//sq:getQuote" mediator="redirect"/>
</rulelist>
Here is a picture of whats going on:
ftp://fremantle.org/interaction2.png
It works using a blocking call to the endpoint (which I would like to
replace with a non-blocking call but that needs improvements to Axis2 async
code).
It only works for req-resp so far.
We need to enhance the xpath to match against the whole messagecontext and
not just the soap envelope.
Take a look.
Paul
Re: YASP
Posted by Paul Fremantle <pz...@gmail.com>.
Vikas
1. Yes the engine calls send mediator and it sends the request and returns
false, so it is the last mediator to be called on the request-path. Of
course you could have a copy-to mediator that sends the request and then
processing continues as well.
I think it was Glen who suggested that the sending of requests was itself a
mediator. I wasn't that keen originally but when I started playing with a
real system it seemed like its much easier to see whats happening with a
ruleset when you can explicitly see in the rules the point at which a
message gets sent.
2. The whole async/sync approach is difficult. We need to fix Axis2 a bit.
For example the async service implementation model only works with full
WS-Addressing and not anonymous replyTos.
3. Yes the order of the rules matters. I believe that is also true in the 3
phase model. So the log will happen first. Then we will check for MSFT and
fault those requests, then we will redirect quoterequests, and then the back
stop is send.
Paul
On 11/4/05, Vikas <vi...@infravio.com> wrote:
>
> Hi Paul/All...
> Just a few passing thoughts and doubts inlined..
>
> ----- Original Message -----
> *From:* Paul Fremantle <pz...@gmail.com>
> *To:* synapse-dev@ws.apache.org
> *Sent:* Friday, November 04, 2005 5:54 AM
> *Subject:* Re: YASP
>
> I have done more work on this and checked it in. Its pretty kludgy at the
> moment but I will try and fix up tomorrow and the weekend.
>
> The main differences are in the rules. Firstly I have added support for
> Spring based mediators. This allows you to parameterise the mediators in the
> rule file: e.g.<rule xpath="//sq:getQuote"
> mediator="redirect"><beans><bean id="redirect" class="
> redirect.SpringRedirect"><property name="uri" value="
> http://64.124.140.30:9090/soap" /></bean></beans></rule>
>
> Set's the uri property on the redirect bean using Dependency Injection.
> The redirect bean offers setUri(String uri).
>
> Secondly, I have removed the default final send. It is now a rule:
> <rule xpath="*" mediator="org.apache.synapse.mediator.SendMediator"/>
> <Vikas>
> Does this mean that the engine calls the SendMediator and the mediator
> has the logic and the information necessary to call the actual
> ProviderEndpoint..
> Wouldn't this be the last mediator to be called?
> ***Are we falling back to the discussions we had in the first IRC?***
> </Vikas>
>
> <Vikas>
> Mediators are to return a true/false..The discussions have centred around
> mediating requests, we delegate a separate class(not a mediator) to call the
> service as a in-only..
> Are we approaching a
> Client---->Synapse----->ProviderEndPoint (for request)
> ProviderEndpoint---->Synapse----->client (for response) irrespective of
> wether the response needs to be mediated or not.
> </Vikas>
>
>
> So as to make it easier to deploy "standard" mediators that ship with
> Synapse, I also made it possible to add mediators that are just class names
> (as above). So in this prototype there are three ways of deploying
> mediators: 1. Axis2 services, 2. classname, 3. spring bean reference.
>
> I also added a FaultMediator that returns an empty fault. This would be
> better done using spring so I could inline the fault details in parameters.
>
> At the moment the spring bean xml is a subelement of the rule - that
> probably is one option. Maybe it would be nice to have it separate. I'm not
> sure. Certainly it would be better to have <rule expr='xpath'
> medtype='class|service|spring|pico|whatever'
> mediator='classname|beanname|servicename|etc'>.
>
>
> The following rules log requests and responses. They fault any requests
> for MSFT's stock price, and they redirect any stock quotes to xmethods.
>
> Paul
>
> <rulelist name="rulespace1"
> xmlns:other=" http://test.other.org/ns/1"
> xmlns:sq="urn:xmethods-delayed-quotes"
> xmlns="http://ws.apache.org/synapse/ns/rulelist/1 ">
>
> <rule xpath="*" mediator="logbean"/>
> <rule xpath="//*[Symbol='MSFT']" mediator="
> org.apache.synapse.mediator.FaultMediator" />
>
> <rule xpath="//sq:getQuote" mediator="redirect"><beans><bean id="redirect"
> class="redirect.SpringRedirect"><property name="uri" value="http://64.124.140.30:9090/soap"
> /></bean></beans></rule>
> <rule xpath="*" mediator="org.apache.synapse.mediator.SendMediator"/>
>
> </rulelist>
> <Vikas>
> Since both the first (logbean) and the last (SendMediator) rules have a
> condition *, how are we supposed to tell the engine to not club them...
> My naive understanding of the rule processing aspects tells me that the *
> condition rules are like global rules and would come before request specific
> rules..
> *Are you suggesting a rule prioritization based on their ordering in the
> xml file?
> The 3 stage idea proposed by us (the last IRC) does help solve this..
> Put the last rule (SendMediator) into the post-processing or Out phase...
> </Vikas>
>
> <Vikas>
> Am i jumping out or am i missing things?
> Bye!
> </Vikas>
> On 11/3/05, Paul Fremantle <pz...@gmail.com> wrote:
> >
> > Yet Another Synapse Prototype
> >
> > Ok... Ant and I had a discussion. I personally have yet to be convinced
> > of the need for the "3 phase" approach. I am meeting F2F with Sanjiva
> > tomorrow who is going to persuade me :-)
> >
> > In the meantime, I have taken my first prototype and with some debugging
> > and good coding advice from Ant I have made it work in Axis2.
> >
> > The prototype is at
> > http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/paul2/synapsejoint/
> >
> > The aim of this is to try out the very simple rule semantics that we
> > talked about at the first F2F.
> >
> > The RuleEngine code is this:
> > public void process(MessageContext messageContext) {
> >
> >
> > Iterator iterator = rl.iterator();
> > while (iterator.hasNext()) {
> > Rule r = (Rule) iterator.next();
> > Expression e = r.getExpression();
> > if (e.match(messageContext))
> > {
> >
> > boolean cont = MediatorExecutor.execute(r.getMediatorName (),
> > messageContext);
> > if (!cont) return;
> > }
> > }
> > // send now
> >
> > Sender.send(messageContext);
> > }
> >
> > Which is pretty much identical to before.
> > Mediators are deployed as services in Axis2. So it fits the picture I
> > posted a while ago. (http://fremantle.org/synapse_in_axis.PNG )
> >
> > The same ruleset gets applied to requests and responses. Here is a
> > sample ruleset that logs requests and responses and redirects StockQuote
> > queries to Xmethods.
> >
> > <rulelist name="rules1"
> > xmlns:sq="urn:xmethods-delayed-quotes"
> > xmlns=" http://ws.apache.org/synapse/ns/rulelist/1">
> > <rule xpath="*" mediator="logbean"/>
> > <rule xpath="//*[Symbol='MSFT']" mediator="dummysq"/>
> > <rule xpath="//sq:getQuote" mediator="redirect"/>
> > </rulelist>
> >
> > Here is a picture of whats going on:
> > ftp://fremantle.org/interaction2.png
> >
> > It works using a blocking call to the endpoint (which I would like to
> > replace with a non-blocking call but that needs improvements to Axis2 async
> > code).
> > It only works for req-resp so far.
> > We need to enhance the xpath to match against the whole messagecontext
> > and not just the soap envelope.
> >
> > Take a look.
> >
> > Paul
> >
> >
>
Re: YASP
Posted by Vikas <vi...@infravio.com>.
Hi Paul/All...
Just a few passing thoughts and doubts inlined..
----- Original Message -----
From: Paul Fremantle
To: synapse-dev@ws.apache.org
Sent: Friday, November 04, 2005 5:54 AM
Subject: Re: YASP
I have done more work on this and checked it in. Its pretty kludgy at the moment but I will try and fix up tomorrow and the weekend.
The main differences are in the rules. Firstly I have added support for Spring based mediators. This allows you to parameterise the mediators in the rule file: e.g.
<rule xpath="//sq:getQuote" mediator="redirect"><beans><bean id="redirect" class="redirect.SpringRedirect"><property name="uri" value="http://64.124.140.30:9090/soap" /></bean></beans></rule>
Set's the uri property on the redirect bean using Dependency Injection. The redirect bean offers setUri(String uri).
Secondly, I have removed the default final send. It is now a rule:
<rule xpath="*" mediator="org.apache.synapse.mediator.SendMediator"/>
<Vikas>
Does this mean that the engine calls the SendMediator and the mediator has the logic and the information necessary to call the actual ProviderEndpoint..
Wouldn't this be the last mediator to be called?
***Are we falling back to the discussions we had in the first IRC?***
</Vikas>
<Vikas>
Mediators are to return a true/false..The discussions have centred around mediating requests, we delegate a separate class(not a mediator) to call the service as a in-only..
Are we approaching a
Client---->Synapse----->ProviderEndPoint (for request)
ProviderEndpoint---->Synapse----->client (for response) irrespective of wether the response needs to be mediated or not.
</Vikas>
So as to make it easier to deploy "standard" mediators that ship with Synapse, I also made it possible to add mediators that are just class names (as above). So in this prototype there are three ways of deploying mediators: 1. Axis2 services, 2. classname, 3. spring bean reference.
I also added a FaultMediator that returns an empty fault. This would be better done using spring so I could inline the fault details in parameters.
At the moment the spring bean xml is a subelement of the rule - that probably is one option. Maybe it would be nice to have it separate. I'm not sure. Certainly it would be better to have <rule expr='xpath' medtype='class|service|spring|pico|whatever' mediator='classname|beanname|servicename|etc'>.
The following rules log requests and responses. They fault any requests for MSFT's stock price, and they redirect any stock quotes to xmethods.
Paul
<rulelist name="rulespace1"
xmlns:other=" http://test.other.org/ns/1"
xmlns:sq="urn:xmethods-delayed-quotes"
xmlns="http://ws.apache.org/synapse/ns/rulelist/1 ">
<rule xpath="*" mediator="logbean"/>
<rule xpath="//*[Symbol='MSFT']" mediator="org.apache.synapse.mediator.FaultMediator" />
<rule xpath="//sq:getQuote" mediator="redirect"><beans><bean id="redirect" class="redirect.SpringRedirect"><property name="uri" value=" http://64.124.140.30:9090/soap" /></bean></beans></rule>
<rule xpath="*" mediator="org.apache.synapse.mediator.SendMediator"/>
</rulelist>
<Vikas>
Since both the first (logbean) and the last (SendMediator) rules have a condition *, how are we supposed to tell the engine to not club them...
My naive understanding of the rule processing aspects tells me that the * condition rules are like global rules and would come before request specific rules..
*Are you suggesting a rule prioritization based on their ordering in the xml file?
The 3 stage idea proposed by us (the last IRC) does help solve this..
Put the last rule (SendMediator) into the post-processing or Out phase...
</Vikas>
<Vikas>
Am i jumping out or am i missing things?
Bye!
</Vikas>
On 11/3/05, Paul Fremantle <pz...@gmail.com> wrote:
Yet Another Synapse Prototype
Ok... Ant and I had a discussion. I personally have yet to be convinced of the need for the "3 phase" approach. I am meeting F2F with Sanjiva tomorrow who is going to persuade me :-)
In the meantime, I have taken my first prototype and with some debugging and good coding advice from Ant I have made it work in Axis2.
The prototype is at http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/paul2/synapsejoint/
The aim of this is to try out the very simple rule semantics that we talked about at the first F2F.
The RuleEngine code is this:
public void process(MessageContext messageContext) {
Iterator iterator = rl.iterator();
while (iterator.hasNext()) {
Rule r = (Rule) iterator.next();
Expression e = r.getExpression();
if (e.match(messageContext))
{
boolean cont = MediatorExecutor.execute(r.getMediatorName (), messageContext);
if (!cont) return;
}
}
// send now
Sender.send(messageContext);
}
Which is pretty much identical to before.
Mediators are deployed as services in Axis2. So it fits the picture I posted a while ago. (http://fremantle.org/synapse_in_axis.PNG )
The same ruleset gets applied to requests and responses. Here is a sample ruleset that logs requests and responses and redirects StockQuote queries to Xmethods.
<rulelist name="rules1"
xmlns:sq="urn:xmethods-delayed-quotes"
xmlns=" http://ws.apache.org/synapse/ns/rulelist/1">
<rule xpath="*" mediator="logbean"/>
<rule xpath="//*[Symbol='MSFT']" mediator="dummysq"/>
<rule xpath="//sq:getQuote" mediator="redirect"/>
</rulelist>
Here is a picture of whats going on:
ftp://fremantle.org/interaction2.png
It works using a blocking call to the endpoint (which I would like to replace with a non-blocking call but that needs improvements to Axis2 async code).
It only works for req-resp so far.
We need to enhance the xpath to match against the whole messagecontext and not just the soap envelope.
Take a look.
Paul
Re: YASP
Posted by Paul Fremantle <pz...@gmail.com>.
I have done more work on this and checked it in. Its pretty kludgy at the
moment but I will try and fix up tomorrow and the weekend.
The main differences are in the rules. Firstly I have added support for
Spring based mediators. This allows you to parameterise the mediators in the
rule file: e.g.
<rule xpath="//sq:getQuote" mediator="redirect"><beans><bean id="redirect"
class="redirect.SpringRedirect"><property name="uri" value="
http://64.124.140.30:9090/soap" /></bean></beans></rule>
Set's the uri property on the redirect bean using Dependency Injection. The
redirect bean offers setUri(String uri).
Secondly, I have removed the default final send. It is now a rule:
<rule xpath="*" mediator="org.apache.synapse.mediator.SendMediator"/>
So as to make it easier to deploy "standard" mediators that ship with
Synapse, I also made it possible to add mediators that are just class names
(as above). So in this prototype there are three ways of deploying
mediators: 1. Axis2 services, 2. classname, 3. spring bean reference.
I also added a FaultMediator that returns an empty fault. This would be
better done using spring so I could inline the fault details in parameters.
At the moment the spring bean xml is a subelement of the rule - that
probably is one option. Maybe it would be nice to have it separate. I'm not
sure. Certainly it would be better to have <rule expr='xpath'
medtype='class|service|spring|pico|whatever'
mediator='classname|beanname|servicename|etc'>.
The following rules log requests and responses. They fault any requests for
MSFT's stock price, and they redirect any stock quotes to xmethods.
Paul
<rulelist name="rulespace1"
xmlns:other="http://test.other.org/ns/1"
xmlns:sq="urn:xmethods-delayed-quotes"
xmlns="http://ws.apache.org/synapse/ns/rulelist/1">
<rule xpath="*" mediator="logbean"/>
<rule xpath="//*[Symbol='MSFT']" mediator="
org.apache.synapse.mediator.FaultMediator" />
<rule xpath="//sq:getQuote" mediator="redirect"><beans><bean id="redirect"
class="redirect.SpringRedirect"><property name="uri" value="
http://64.124.140.30:9090/soap" /></bean></beans></rule>
<rule xpath="*" mediator="org.apache.synapse.mediator.SendMediator"/>
</rulelist>
On 11/3/05, Paul Fremantle <pz...@gmail.com> wrote:
>
> Yet Another Synapse Prototype
>
> Ok... Ant and I had a discussion. I personally have yet to be convinced of
> the need for the "3 phase" approach. I am meeting F2F with Sanjiva tomorrow
> who is going to persuade me :-)
>
> In the meantime, I have taken my first prototype and with some debugging
> and good coding advice from Ant I have made it work in Axis2.
>
> The prototype is at
> http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/paul2/synapsejoint/
>
> The aim of this is to try out the very simple rule semantics that we
> talked about at the first F2F.
>
> The RuleEngine code is this:
> public void process(MessageContext messageContext) {
>
>
> Iterator iterator = rl.iterator();
> while (iterator.hasNext()) {
> Rule r = (Rule) iterator.next();
> Expression e = r.getExpression();
> if (e.match(messageContext))
> {
>
> boolean cont = MediatorExecutor.execute(r.getMediatorName (),
> messageContext);
> if (!cont) return;
> }
> }
> // send now
>
> Sender.send(messageContext);
> }
>
> Which is pretty much identical to before.
> Mediators are deployed as services in Axis2. So it fits the picture I
> posted a while ago. (http://fremantle.org/synapse_in_axis.PNG)
>
> The same ruleset gets applied to requests and responses. Here is a sample
> ruleset that logs requests and responses and redirects StockQuote queries to
> Xmethods.
>
> <rulelist name="rules1"
> xmlns:sq="urn:xmethods-delayed-quotes"
> xmlns="http://ws.apache.org/synapse/ns/rulelist/1">
> <rule xpath="*" mediator="logbean"/>
> <rule xpath="//*[Symbol='MSFT']" mediator="dummysq"/>
> <rule xpath="//sq:getQuote" mediator="redirect"/>
> </rulelist>
>
> Here is a picture of whats going on:
> ftp://fremantle.org/interaction2.png
>
> It works using a blocking call to the endpoint (which I would like to
> replace with a non-blocking call but that needs improvements to Axis2 async
> code).
> It only works for req-resp so far.
> We need to enhance the xpath to match against the whole messagecontext and
> not just the soap envelope.
>
> Take a look.
>
> Paul
>
>