Maciej, I would like to get a bit of clarification on this. Does BpelServer.deploy(File) always imply a BpelServer.startDeploymentUnit(File) or should we add an element into the DD that allows "start" on deployment to be specified?
Lance On 8/17/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
Lance, Yes, that makes sense; but there is a caveat. The activate() method potentially does two things: 1. Update the state of the process in the DB to be "active". 2. Instantiate the process in memory. Certainly (1) belongs in the PMAPI as you suggest. (2) is more complicated: it depends on (1) and also on the integration layer deciding that it wants the process started. For example, in JBI we don't actually want to instantiate the process in memory until the service unit life cycle method start() is called. What I would propose is: * create a suspend() / resume() method on the process management API that would control the process state in the DB. * remove activate/deactivate methods on the BpelServer. * add startAll(), startProcess(QName pid), and startDeploymentUnit(File du) to BpelServer as well as corresponding stop...() methods for use by the Integration Layer. startProcess(..) would load the given process in memory (so long as it is not suspended). startDeploymentUnit(..) would call startProcess(..) for all processes in the deployment unit. startAll() would call startDeploymentUnit(..) for all known deployment units. -maciej On Wed, 2006-08-16 at 22:17 -0600, Lance Waterman wrote: > So if I understand correctly this is a start/stop for the process > definition and are process definition lifecycle operations. > > What do you think about moving these operations to the > ProcessManagement interface and renaming to "suspend"/"resume" ( > following the precedence on the InstanceManagement interface)? > > Lance
