synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <>
Subject Re: inter-synapse links
Date Thu, 13 Dec 2007 10:04:45 GMT
Hi Paul,

Well, a nice scenario Paul.

AFAIK, Upul has already implemented pined services on synapse. That is if
you specify the proxy with the pinedServers attribute listing the set of
node names space separated as we specify transports, then that service will
only be started on the specified pined servers not on the other servers on
the cluster.

eg: if there are three nodes named "NodeA", "NodeB" and "NodeC", the
following proxy will only start on NodeA and B but not on C.
<proxy pinedServers="NodeA NodeB" .../>

As you explained there is a command line option to specify the synapse
server name (node name) as a system property to the command line (i.e. you
need to use the -DSynapseServerName=$SERVER_NAME).

So in effect what is left is just the calculation of the the refereed
service URL, which you left as an exercise :). I think we can do this fairly
easily, by storing the server urls indexed with the server names (provided
through the command line) in the axis2 configuration context which will e
replicated among all the nodes in the cluster.



On Dec 13, 2007 2:50 PM, Paul Fremantle <> wrote:

> Hi
> I have a scenario where a Synapse user needs to do processing on two
> Synapse nodes. Basically one node sits in one office and reads files from
> the file system and then processes them into an XML message. These are then
> sent ( e.g. via HTTP) to another Synapse node in another office where the
> actual processing of that XML takes place.
> Now, of course when we are building a development environment, there is no
> need to have two Synapse nodes - a single Synapse instance can do both
> parts. This got me thinking about having one Synapse config that could be
> "deployed" in either a single node or two nodes, and how we might do that.
> In other words there would be a "logical" model and then a specific
> deployment.
> Suppose I have proxyA which is listening on the filesystem, which then
> calls sequence A (file->XML), then sends the message to endpoint B. [First
> office]. Endpoint B is pointing to Proxy B, which then calls Sequence B (all
> happening in the second office).
> So here is a sketch of the synapse config
> <proxy name=A transport="vfs">
>    <inSequence>
>       <seq ref=seqA>
>    </inSequence>
>    <target><endpoint ref="endB"/></target>
> </proxy>
> <proxy name=B transport="http">
>   <inSequence><seq ref=seqB></inSequence>
> </proxy>
> Here is one way we could solve this. First, we need a way of pointing endB
> to proxyB that is automatic ( i.e. not based on hardcoded URLs but
> basically calculated by Synapse). Suppose we have a syntax like this:
> <target>
>    <endpoint name="endB">
>       <synapseProxy ref="B"/>
>    </endpoint>
> </target>
> So now Synapse automatically somehow calculates the actual URL. Details
> are left to the reader as an exercise :)
> The second thing we need is a way to map the proxies onto real servers.
> What we could do here is to extend the <proxy> definition not just to
> include transport, but also a virtual name for a particular server. I guess
> I'm thinking something similar to SOAP Roles, where a particular node could
> be playing the part of one or more logical servers.
> So then we would change the definitions to say
> <proxy name=A transport=vfs node=OfficeA>
> <proxy name=B transport=http node=OfficeB>
> So now all we need is some way of saying which node this particular server
> is running as. In the devt environment, both logical nodes would be running
> in a single instance. In the real environment, the exact same config would
> be run on two different nodes. We could configure which nodes a server was
> acting as via commandline params, or environment variables, or maybe a
> properties file.
> I hope I've explained it clearly!
> Thoughts? Other approaches?
> Paul
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
> blog:
> "Oxygenating the Web Service Platform",

Ruwan Linton - "Oxygenating the Web Services Platform"

View raw message