Paul, On Dec 13, 2007 3:48 PM, Paul Fremantle <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 > > > [EMAIL PROTECTED] > > > > > > "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 > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
