On Mon, Apr 27, 2009 at 2:20 PM, gaoxt1983 <[email protected]> wrote: > > I want to build the architecture like this: a server called > workflow_proxy receive the web service request, For starting a > workflow instance, the request contains the workflow name which > represents a workflow definition. then the workflow_proxy knows which > server of workflow it should contact with (there is a name-ip table in > workflow_proxy). Then the workflow server start an instance of the > specific definition, return the work item id of instance to > workflow_proxy. the workflow_proxy store the id-workflow_name > association in its own table. return the work item id to client. When > we want to manipulate the workitem(like update,delete the instance, > move forward) , we communicate with the proxy, not the workflow server > directly. The workflow server is per workflow definition per server, > which means, there should be multiple servers of workflow. These > servers share the same database and a NFS directory for definition > files.
Hi, NFS directory should be fine. But the "same" database for all the workflow engines would be a bit problematic. The same database server for all the workflow engines is OK though. Theoritically, as long as you don't store process variables bound at the "engine" level (ie variables whose name is prefixed with a "//" (double slash)) you can use the same database for all workflow engines. As soon as one or two workflow engines start using variables bound at the engine level, you will get into strange issues (i.e. one workflow engine will overwrite the engine-level variables of another). Best regards, -- John Mettraux - http://jmettraux.wordpress.com --~--~---------~--~----~------------~-------~--~----~ you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en -~----------~----~----~----~------~----~------~--~---
