My comments are in line.
On 2/27/06, Hendrik Jander <[EMAIL PROTECTED]> wrote:
Consider the following sample synapse.xml, which is the one that contains the rules for which mediator(s) should execute, when a message is entered in to synapse.
<synapse xmlns="http://ws.apache.org/ns/synapse">
<!-- start by reading ws-a headers if they exist -->
<engage-addressing-in/>
<!-- now log the message using log4j -->
<log/>
<!-- Check if the URL matches the stockquote gateway/dumb case -->
<regex message-address="to" pattern="/StockQuote.*">
<refdefine ref="stockquote"/>
</regex>
<!-- check if the URL matches the virtual url - either the proxy or ws-add case -->
<regex message-address="to" pattern="http://stockquote.*">
<refdefine ref="stockquote"/>
</regex>
<!-- send the message on -->
<send/>
<!-- these are only called if referenced above-->
<define name="stockquote">
<!-- set the To address to the real endpoint -->
<header type="to" value="http://www.webservicex.net/stockquote.asmx "/>
<!-- check if the symbol is MSFT -->
<xpath expr="//*[wsx:symbol='MSFT']" xmlns:wsx="http://www.webserviceX.NET/ ">
<!-- if it is throw a fault -->
<fault/>
</xpath>
</define>
</synapse>
Every element such as <engage-addressing-in/>, <regex/>, <xpath/>, <define/> etc etc. is a mediator and at deployment time they are mapped to a Mediator, (earlier known as a Processor) and configured via a MediatorConfigurator (earlier know as ProcessorConfigurator). <regex/> and <xpath/> mediators match for a pattern and if true they called the underline mediators. All the above mediators are "in-line" mediators but <define/> mediator. <define/> mediator should be referenced. So there are in line mediators and reference mediators.
ex:
<regex message-address="to" pattern="/StockQuote.*">
<refdefine ref="stockquote"/>
</regex>
@pattern contains a virtual url, and <regex/> is true it will reference "stockquote" and set the message's "wsa:to" to a physical address.
Now if the body has a 'MSFT' the client will receive a Fault response.
So rules are mediators and some are composite. Rules can be global as well.
<regex/> is one way of mapping between virtual url and endpoints. We are developing these mediator as we speak.
Synapse uses Axis2 SOAP Engine as the underline infrastructure for communication among web services and AXIOM as the xml manipulator. So the underline protocol is SOAP.
We are building a notification mechanism to update synapse.xml and resources for mediators when they are changed. At the moment information is static. Resources notification will be available with the M2 release. So the ultimate goal is to use any distributed repository and updated the Mediators and resources needed to mediators.
SOAP
This could even be JMS, which Synapse will be handling right now.
ex: for a point-to-point transaction there can be multiple number of Synapse nodes, where the message has to pass through. Some nodes may encrypt the message, some nodes proves WS-RM etc.
If the sending/receiving end point is a legacy system, and if the sender/receive needs WS-SEC or WS-RM, a Synapse can be installed in front of it and work as a proxy and provide this quality of services. So that's Synapse. :-).
Thank you
Saminda
Hi Paul,
thanks for the instant reply.
But your anwser is raising new questions.
Please find questions inside.
Hendrik
> Hendrik
>
> Nice to meet you!
> Firstly, I should let you know that some of the Synapse team are based in
> Sri Lanka!
>
> So the distributed model we are going for in synapse is based on multiple
> brokers having a global set of rules. So for example, broker1 may receive a
> message and mediate it. It can then pass the message to a virtual URL. That
> may resolve to broker2 which can mediate more before passing it to the
> endpoint.
1. which rules ? :) (are mediators rules?)
Consider the following sample synapse.xml, which is the one that contains the rules for which mediator(s) should execute, when a message is entered in to synapse.
<synapse xmlns="http://ws.apache.org/ns/synapse">
<!-- start by reading ws-a headers if they exist -->
<engage-addressing-in/>
<!-- now log the message using log4j -->
<log/>
<!-- Check if the URL matches the stockquote gateway/dumb case -->
<regex message-address="to" pattern="/StockQuote.*">
<refdefine ref="stockquote"/>
</regex>
<!-- check if the URL matches the virtual url - either the proxy or ws-add case -->
<regex message-address="to" pattern="http://stockquote.*">
<refdefine ref="stockquote"/>
</regex>
<!-- send the message on -->
<send/>
<!-- these are only called if referenced above-->
<define name="stockquote">
<!-- set the To address to the real endpoint -->
<header type="to" value="http://www.webservicex.net/stockquote.asmx "/>
<!-- check if the symbol is MSFT -->
<xpath expr="//*[wsx:symbol='MSFT']" xmlns:wsx="http://www.webserviceX.NET/ ">
<!-- if it is throw a fault -->
<fault/>
</xpath>
</define>
</synapse>
Every element such as <engage-addressing-in/>, <regex/>, <xpath/>, <define/> etc etc. is a mediator and at deployment time they are mapped to a Mediator, (earlier known as a Processor) and configured via a MediatorConfigurator (earlier know as ProcessorConfigurator). <regex/> and <xpath/> mediators match for a pattern and if true they called the underline mediators. All the above mediators are "in-line" mediators but <define/> mediator. <define/> mediator should be referenced. So there are in line mediators and reference mediators.
ex:
<regex message-address="to" pattern="/StockQuote.*">
<refdefine ref="stockquote"/>
</regex>
@pattern contains a virtual url, and <regex/> is true it will reference "stockquote" and set the message's "wsa:to" to a physical address.
Now if the body has a 'MSFT' the client will receive a Fault response.
So rules are mediators and some are composite. Rules can be global as well.
2. where is the mapping between virtual url and endpoint stored and,even more
important, how are this informations kept up to date. So which infrastructure
is the synapsis team planning to use for a distributed repository?
<regex/> is one way of mapping between virtual url and endpoints. We are developing these mediator as we speak.
Synapse uses Axis2 SOAP Engine as the underline infrastructure for communication among web services and AXIOM as the xml manipulator. So the underline protocol is SOAP.
We are building a notification mechanism to update synapse.xml and resources for mediators when they are changed. At the moment information is static. Resources notification will be available with the M2 release. So the ultimate goal is to use any distributed repository and updated the Mediators and resources needed to mediators.
3. how communicate Med.brokers under each other?
SOAP
4. if med.brokers a sends a msg to med.broker b, which medium is he using?
(i'm asking for something like a bus)
This could even be JMS, which Synapse will be handling right now.
5.why is distribution important for synapsis?
ex: for a point-to-point transaction there can be multiple number of Synapse nodes, where the message has to pass through. Some nodes may encrypt the message, some nodes proves WS-RM etc.
If the sending/receiving end point is a legacy system, and if the sender/receive needs WS-SEC or WS-RM, a Synapse can be installed in front of it and work as a proxy and provide this quality of services. So that's Synapse. :-).
Thank you
Saminda
> If all the brokers share a common repository for configuration, and each
> broker is essentially stateless (with respect to message flows), then that
> creates a distributed mediation broker.
>
> Paul
>
>
>
> On 2/27/06, Hendrik Jander < [EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > I'm working actually for a Sri Lankan Software company and doing some
> > research
> > about ESB concept there, while i also found the Synapsis project.
> >
> > My questions regard the following statement from the Proposal:
> >
> > "The Synapse project will create a robust, lightweight implementation of a
> > highly scalable and distributed service mediation framework based on Web
> > services specifications."
> >
> > As far as i had understood, synapsis focus is to provide an infrastrucure
> > for
> > manipulating messages exchanged between WS. I actually wonder how this
> > task is
> > related to distribution.
> > This raises the question how u plan to realize the distribution of the
> > container.
> >
> > excuse me if this question misses the topic or is noob at all.
> >
> > Regards,
> > Hendrik
> >
> > ----------------------------------------------------------------
> > This mail was sent through http://webmail.uni-jena.de
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> 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
>
----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
