inline ... On 8/18/06, Assaf Arkin <[EMAIL PROTECTED]> wrote:
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?
This is a distinction that I understood Maciej to be making so I will let him chime in. 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..
Okay, let's go with "started/stopped"I forgot to add one thing to the list that we actually discussed earlier in the context versioning and I will define it as: A process definition + version can be "active/retired" ( a process defintion must be "started" before it + version can be "active/retired". "Active" means a process definition + version is available to the ODE runtime message router to instantiate new processes. "Retired" means a process definition + version is not available to he ODE runtime message router to instantiate a new process however messages can be routed to existing process instances. 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
