Here is my current understanding to date: A process definition can be "deployed"/"undeployed". "Deployed" means a process definition has been compiled and exists in the ODE process definition repository. "Undeployed" means that a process definition does not exist in the ODE process definition repository.
A process definition can be "installed"/"not installed" ( a process must be "deployed" before it can be "installed"/"uninstalled" ). "Installed" means that the process definition resides in the ODE process definition repository and is available to be managed through the PMAPI. "Uninstalled" means that the process definition resides in the ODE process definition repository but is not available for management through the PMAPI. A process definition can be "started"/"suspended" ( a process must be "installed" before it can be "started"/"suspended". "Started" means a process definition is available to the ODE runtime message router. "Suspended" means the process defintion is not available to the ODE runtime message router. Based on these definitions I would like to try to define engine startup behaviour: When the ODE engine is started ( BpelServer.start() ): 1) Should we enable the concept of "InstallAtStartup" which means the engine iterates through the process definition repository and "installs" any processes that are marked for "InstallAtStartup"? 2) Should we enable the concept "StartAtStartup" which means the engine iterates through the "installed" process definitions and sets their state to "started"? Likewise I would like to try to define deploy behaviour. 1) At deployment a process is only "deployed". A separate call to the engine is required to "install" the process after it is deployed. 2) Should we enable some default behaviour that enables a process to be "deployed" and "installed" in the same call? And finally install behaviour: 1) When a process is "installed" by default it is in a "suspended" state. A separate call to the engine is require to set state to "started". 2) Should we enable some default behavior that enables a process to be "installed" and "started" in the same call? 3) Should we enable some default behavior that enables a process to be "deployed", "installed" and "started" in the same call? Lance On 8/18/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
Ok, If I get your meaning you are after the ability to deploy a process and mark it as either "suspended" or not suspended (active). Basically the initial value of the flag that can be later controlled by the PMAPI suspend/resume method. To this I have no objection. -maciej On Fri, 2006-08-18 at 10:45 -0600, Lance Waterman wrote: > This could be a misleading question in that I think this "autostart" > concept should remain ( for deploy and forget IL implementations ). > Therefore I am suggesting we add something into the DD that identifies > a process should auto start when the BpelServer is started. > > Lance > > On 8/18/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > What about this concept of "process autostart" on > BpelServer.start()? Is this something you see going away from > a design standpoint? > > I'm trying to tease out the requirements from the "hacks". > > > Lance > > > On 8/18/06, Maciej Szefler <[EMAIL PROTECTED]> wrote: > Lance, > > In this scheme, deploy() should only deploy. If the IL > wants to start > the deployment unit it should call start() after > calling deploy(). > There's a bunch of confusing logic in the code right > now about > auto-activation, stickiness, etc... Those are just > hacks and should not > be used as guidance. > > -maciej > > On Fri, 2006-08-18 at 10:16 -0600, Lance Waterman > wrote: > > 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 > > > >
