On 8/18/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
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.
I'm not clear on the distinction. Why would I want to deploy and not install? 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.
I would suggest opposite words, either started/stopped or active/suspended.. 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"?
+1 on anything we do that gives you generally useful default behavior with less API calls. Assaf 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 > > > > > > > > > >
-- CTO, Intalio http://www.intalio.com
