synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <ruwan.lin...@gmail.com>
Subject Re: inter-synapse links
Date Thu, 13 Dec 2007 10:47:59 GMT
Paul,

On Dec 13, 2007 3:48 PM, Paul Fremantle <pzfreo@gmail.com> wrote:

> 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.


Sorry my bad, it is just my spelling mistake. Implementation is in the
correct spelling.


>
>
> 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)


May be we can declare them (the other nodes) within the synapse
configuration with the name of the node and the address


>
> 2. We have a central registry and each Synapse node publishes to that


This will work when the whole configuration is stored in the registry.


>
> 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, I am sorry, but I don't really get this idea.

Thanks,
Ruwan


>
>
> 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
>



-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Mime
View raw message