Okay - I understand the use case. I'm not sure logically I see the difference between having a process loaded into memory in a suspended state vs not loaded into memory. Does loading a process into memory in a suspended state by default and then allow the IL to "start"/"resume" the process accomplish the same thing as startAll()? The terms may be getting in the way here.
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
