synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <>
Subject inter-synapse links
Date Thu, 13 Dec 2007 09:20:02 GMT

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

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">
      <seq ref=seqA>
   <target><endpoint ref="endB"/></target>

<proxy name=B transport="http">
  <inSequence><seq ref=seqB></inSequence>

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:
   <endpoint name="endB">
      <synapseProxy ref="B"/>

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 Fremantle
Co-Founder and VP of Technical Sales, WSO2


"Oxygenating the Web Service Platform",

View raw message