You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2007/12/13 10:20:02 UTC
inter-synapse links
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
Re: inter-synapse links
Posted by Paul Fremantle <pz...@gmail.com>.
Actually I think given what you said yesterday - that we can effectively do
a little of this today - so I'm very happy to leave the second part till
later. However, if anyone has any creative ideas how to simply link two
servers that would be cool. For example, we could have each Synapse endpoint
export a Synapse XML that describes its proxy endpoints. Then another
Synapse node could simply import that as a URL? WDYT? That ought to be
really simple.
I will raise a few JIRAs.
Paul
On Dec 14, 2007 3:23 AM, Ruwan Linton <ru...@gmail.com> wrote:
> Paul,
>
> On Dec 13, 2007 10:38 PM, Paul Fremantle <pz...@gmail.com> wrote:
>
> > Ruwan
> >
> >
> > > 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.
> > >
> >
> OK, got it you mean the proxies as endpoints in synapse right?
>
>
> >
> > Well it doesn't need to be the whole configuration. It simply needs to
> > be just the endpoints.
> >
> > 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.
> > >
> >
> > Ok let me try and explain again.
> >
> > Imagine there is a web service by which a synapse node can:
> > 1) publish a map of proxy services to endpoint URLs that are supported
> > on this node
> > e.g. {thisnode->{{proxy1: url1,url2,url2}, {proxy2: url4}}}
> > 2) read a map of proxy services to endpoint URLs that are available on
> > all Nodes
> >
> >
> > I guess to do this properly you might need a global revision number like
> > SVN so you stay completely consistent and you know which updates are fresh.
> > (There might be some complexity if two systems think they have the latest
> > info and have never communicated before, but I bet there is a nice algorithm
> > for this)
> > Given this interface every node can find every endpoint for every
> > deployed proxy, as long as each node can contact at least one other node (
> > i.e. there is a *mesh*). http://en.wikipedia.org/wiki/Mesh_network
> >
> > Now actually this need not just be for Synapse endpoints. If you had the
> > same config for all endpoints, you could also use this to distribute the
> > config. So a server could be started with only two pieces of information -
> > which role(s) its playing, and the URL(s) of one (or more) other server(s)
> > in the mesh.
> >
> > [We could also have this for Axis2 so that Axis2 endpoints can also
> > become part of the list, but that is another conversation I think needs to
> > wait]
> >
> > Does that make more sense?
>
>
> Yes, I think I got it :) but lets not plan this implementation to go for
> the 1.1.1 release. Shall we keep this feature post 1.1.1, and it is better
> if we have an improvement JIRA on this I guess.
>
> Thanks,
> Ruwan
>
> --
> 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
Re: inter-synapse links
Posted by Ruwan Linton <ru...@gmail.com>.
Paul,
On Dec 13, 2007 10:38 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Ruwan
>
>
> > 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.
> >
>
OK, got it you mean the proxies as endpoints in synapse right?
>
> Well it doesn't need to be the whole configuration. It simply needs to be
> just the endpoints.
>
> 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.
> >
>
> Ok let me try and explain again.
>
> Imagine there is a web service by which a synapse node can:
> 1) publish a map of proxy services to endpoint URLs that are supported on
> this node
> e.g. {thisnode->{{proxy1: url1,url2,url2}, {proxy2: url4}}}
> 2) read a map of proxy services to endpoint URLs that are available on all
> Nodes
>
>
> I guess to do this properly you might need a global revision number like
> SVN so you stay completely consistent and you know which updates are fresh.
> (There might be some complexity if two systems think they have the latest
> info and have never communicated before, but I bet there is a nice algorithm
> for this)
> Given this interface every node can find every endpoint for every deployed
> proxy, as long as each node can contact at least one other node (i.e.
> there is a *mesh*). http://en.wikipedia.org/wiki/Mesh_network
>
> Now actually this need not just be for Synapse endpoints. If you had the
> same config for all endpoints, you could also use this to distribute the
> config. So a server could be started with only two pieces of information -
> which role(s) its playing, and the URL(s) of one (or more) other server(s)
> in the mesh.
>
> [We could also have this for Axis2 so that Axis2 endpoints can also become
> part of the list, but that is another conversation I think needs to wait]
>
> Does that make more sense?
Yes, I think I got it :) but lets not plan this implementation to go for the
1.1.1 release. Shall we keep this feature post 1.1.1, and it is better if we
have an improvement JIRA on this I guess.
Thanks,
Ruwan
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: inter-synapse links
Posted by Paul Fremantle <pz...@gmail.com>.
Ruwan
> 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.
>
Well it doesn't need to be the whole configuration. It simply needs to be
just the endpoints.
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.
>
Ok let me try and explain again.
Imagine there is a web service by which a synapse node can:
1) publish a map of proxy services to endpoint URLs that are supported on
this node
e.g. {thisnode->{{proxy1: url1,url2,url2}, {proxy2: url4}}}
2) read a map of proxy services to endpoint URLs that are available on all
Nodes
I guess to do this properly you might need a global revision number like SVN
so you stay completely consistent and you know which updates are fresh.
(There might be some complexity if two systems think they have the latest
info and have never communicated before, but I bet there is a nice algorithm
for this)
Given this interface every node can find every endpoint for every deployed
proxy, as long as each node can contact at least one other node (i.e. there
is a *mesh*). http://en.wikipedia.org/wiki/Mesh_network
Now actually this need not just be for Synapse endpoints. If you had the
same config for all endpoints, you could also use this to distribute the
config. So a server could be started with only two pieces of information -
which role(s) its playing, and the URL(s) of one (or more) other server(s)
in the mesh.
[We could also have this for Axis2 so that Axis2 endpoints can also become
part of the list, but that is another conversation I think needs to wait]
Does that make more sense?
Paul
Re: inter-synapse links
Posted by Ruwan Linton <ru...@gmail.com>.
Paul,
On Dec 13, 2007 3:48 PM, Paul Fremantle <pz...@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 <ru...@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"
Re: inter-synapse links
Posted by Paul Fremantle <pz...@gmail.com>.
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 <ru...@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 <pz...@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
Re: inter-synapse links
Posted by Ruwan Linton <ru...@gmail.com>.
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 <pz...@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"