synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: inter-synapse links
Date Thu, 13 Dec 2007 10:18:54 GMT
Great! I didn't know the pinned servers existed even. Can we fix the typo.
Pined means you are sad because you are missing someone. Pinned means you
have used a pin to attach something somewhere.

Of course we can't rely on clustering in the case I've suggested, because
the two servers are in different offices... so probably not part of a
cluster. I think we need a flexible way of finding the URLs of the actual
deployed proxies. Here are three further potential approaches beyond
clustering (we might want to implement them all)

1. We have a table of hard coded URLs somewhere (I know not great but easy
to implement)
2. We have a central registry and each Synapse node publishes to that
3. We have URL on each node which the other nodes can use to query and post
their own endpoint definitions. This could even be federated (in other
words, I don't need to specify the URLs of ALL the other Synapse nodes, just
one. As long as each Synapse node is connected the mesh, then it can get
info on all the others via the mesh, then all the addresses propogate. This
could be really cool... sort of a distributed mesh registry of Synapse info.
No central server required and no single point of failure.

Paul

On Dec 13, 2007 10:04 AM, Ruwan Linton <ruwan.linton@gmail.com> wrote:

> 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.
>
> WDYT?
>
> Thanks,
> Ruwan
>
>
> On Dec 13, 2007 2:50 PM, Paul Fremantle <pzfreo@gmail.com> 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: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"




-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Mime
View raw message