Here's a transcript of today's IRC chat.
[09:19:29] <boisvert> Alright, let's get started
[09:19:44] <boisvert> What shall we talk about first?
[09:19:50] <boisvert> deployment state terminology?
[09:19:58] <mszefler> ooh. that sounds like fun.
[09:19:59] <lance> that would be great
[09:20:19] <lance> I think Assaf has an oustanding question
[09:21:33] <assaf> then I don't remember what it was :-)
[09:21:48] <mszefler> why would i want to deploy and not install
[09:21:53] <mszefler> i think that is the question
[09:21:53] <boisvert> i think so far we had the following for process
definitions:
[09:21:58] <boisvert> active/retired
[09:22:01] <lance> you where asking about the distinction between
"deployed" and "installed"
[09:22:01] <boisvert> started/stopped
[09:22:17] <assaf> yep
[09:22:37] prb_ [EMAIL PROTECTED] has joined #apache-ode
[09:22:43] <prb_> Hi, All.
[09:22:47] <boisvert> isn't stopped the equivalent of "deployed" but not
"installed" ?
[09:22:54] <mszefler> ok , before we get any further we should nail down
all those things that are not controversial
[09:23:10] <mszefler> if i may, i can summarize.
[09:24:19] <mszefler> deploy and undeploy have the conventional meaning.
by deploying, a user makes a certain deployment unit known to the server.
[09:24:34] <mszefler> undeploying has the opposite effect. it removes
all traces of the deployment unit from the server.
[09:24:45] <mszefler> everyone ok with that?
[09:24:56] <lance> I am
[09:24:59] <assaf> so far
[09:25:08] <mszefler> ok. next one is activated/retired
[09:26:03] <mszefler> A process is activated if it can create new
instances. if it cannot create new instances it is considered retired.
So ,work can occur on behalf of retired and activated process, but only
activated processes can "createInstance"
[09:26:14] <mszefler> ok?
[09:26:24] <assaf> +1
[09:26:41] <lance> I think we have skipped a state
[09:26:57] <mszefler> Which one?
[09:27:13] <lance> before it can be active does it need to be
"started"/"installed"?
[09:27:16] <mszefler> ok..
[09:27:22] <mszefler> that is what i consider "controversial"
[09:27:31] <mszefler> i want to get the agreed definitions down
[09:28:05] <mszefler> (first)
[09:28:16] <lance> sorry - I thought we were walking a state transition
as well - so - I'm okay with the active definition
[09:28:40] <mszefler> alright. so lets agree to use deploy/undeploy,
active/retire only when referring to these states
[09:28:44] <mszefler> otherwise it get confusing.
[09:28:57] <lance> yep - I agree with those definitions
[09:29:23] <mszefler> now I see another use case that our present
definitions dont cover.
[09:29:52] <mszefler> i.e. the user wants to temporarily prevent work
from being performed on behalf of a process
[09:30:07] <mszefler> that is, no process instances will make any
progress when the process is in this state
[09:31:21] <mszefler> comments welcome at this point.
[09:31:53] <assaf> bulk suspend process instances?
[09:32:04] <mszefler> kind of
[09:32:10] <mszefler> more like an on/off switch for the process
[09:32:18] <lance> so - based on the mailing list - I think we have been
calling this state - "started"/"stopped"
[09:32:21] <mszefler> no current instances proceed, no new instances
created.
[09:32:34] <assaf> shouldn't we keep it that way?
[09:32:35] <mszefler> we've been using all sorts of terminology
[09:32:54] <mszefler> i actually don't like start/stop for reasons i
will describe in a second.
[09:33:17] <boisvert> how about enabled/disabled ?
[09:33:21] <assaf> regardless of terminology, we're adding a state for
what is already covered by two other states
[09:33:42] <lance> enabled/disabled is fine with me
[09:34:05] <mszefler> what is covered by what assaf?
[09:34:28] <boisvert> i see a slight semantic difference between
suspending all instances + retiring the process definition and
"disabling" the process definition
[09:34:29] <assaf> retire + suspend => no instance is executed or started
[09:34:59] <mszefler> you mean retire + (forall isntances) suspend
[09:35:08] <lance> I don't think we have introduced suspend yet?
[09:35:17] <mszefler> exactly.
[09:35:54] <boisvert> Ode currently has suspend/resume on instances, yes
[09:36:13] <boisvert> (which hasn't been discussed yet)
[09:36:23] <mszefler> but not on the process as a whole.
[09:36:31] <boisvert> Correct
[09:37:01] <mszefler> we could include this new state on the same state
dimension, i.e. process can be active, retired, or suspended
[09:37:45] <boisvert> I think that's a good idea
[09:37:53] <lance> can we talk about scope on that
[09:38:00] <mszefler> sure
[09:38:23] <lance> I have been thinking the scope of active/retired was
at the PID+version level
[09:39:12] <lance> where enabled/disabled or suspend ( not sure were we
are on that ) was at the PID level
[09:39:36] <mszefler> or process level vs deployment unit level
[09:40:17] <lance> yeah - perhaps it makes sense to finish the
definitions and then apply scope
[09:41:16] <mszefler> ok. so whatever scope we use, lets reserve
enabled/disabled and suspended for this use case
[09:41:32] <mszefler> i.e. user wants to prevent work from happening
[09:41:35] <lance> agreed
[09:42:19] <mszefler> Now i think there is a completely separate
dimension that I like to call started/stopped
[09:42:43] <lance> did we agree on "enabled"/"disabled"?
[09:42:44] <mszefler> this is unlike the other dimensions in that it is
there for the benefit of the IL, not the user.
[09:43:06] <mszefler> i'm good with reserving all three terms
[09:43:25] <mszefler> dependning on the scope either disabbled or
suspened may turn out to be more appropriate
[09:43:34] <lance> okay
[09:44:01] <mszefler> ok. so back to start/stoped.
[09:44:38] <mszefler> unlike the other dimensions, this state is
transient, and unknown to the user
[09:45:11] <mszefler> it is necessary in order to facilitate an orderdly
startup to the intergration layer
[09:45:28] <mszefler> for example:
[09:46:34] <mszefler> an il may deploy a binding together with a
process, it may need to ensure that before work starts on behalf of a
process that the necessary sockets are created. so the bpelserver
provides a way the IL to defer startup of processes
[09:47:21] <mszefler> these are the start(..), startAll().. methods i
suggested
[09:47:30] <mszefler> does this make sense?
[09:48:11] <lance> are processes availble to the management API prior to
start()?
[09:48:36] <mszefler> i would think so yes.
[09:49:33] <lance> so there would need to be some state implied - no?
[09:50:04] <lance> can a process be "enabled" prior to start()?
[09:50:07] <mszefler> yes
[09:50:09] <mszefler> definately
[09:50:10] <assaf> like a starting state
[09:50:46] <mszefler> enabled survives shutdown, "started" does not.
[09:51:15] <mszefler> so if a process were enabled, and the system came
back up the process would continue to be enabled, although it would not
be started until the IL chose to start it
[09:52:32] <lance> right - but if I were to query the repository - would
I know that a particular process was not running because it was not started?
[09:53:26] <mszefler> depends if we want to expose this
[09:54:03] <lance> if I am trying to figure out why my messages a
bouncing I think we need to
[09:54:21] <mszefler> yeah good point.
[09:54:47] <mszefler> theoretically, the il should make sure that all
processes are started.
[09:55:11] <mszefler> but i guess that could be violated.
[09:55:11] <Matthieu> are there use cases where we wouldn't have an
error and this state would last more than a second?
[09:55:28] <mszefler> they are kind of degenerate use cases
[09:55:32] <mszefler> if for example in jbi
[09:55:49] <mszefler> I undepoy the SA, but for some reason, the server
is not notified of the undeployment
[09:56:03] <mszefler> then the JBI IL might not start a process even if
it is deployed on the server
[09:56:47] <mszefler> although i could imagine more legitimate use cases too
[09:57:36] <assaf> can the user fix that?
[09:57:48] <mszefler> they can undeploy using the PMAPI
[09:58:18] <mszefler> or maybe not.... lets see
[09:58:24] <assaf> but they can't fix the JBI code the way you flip a
process from activated to retired?
[09:59:01] <assaf> that definitely should end up as an error in the log
[09:59:13] <assaf> but unless we expect it to happen frequently ...
[09:59:23] <mszefler> yeah. it seems like if the IL is written correctly
everything will start
[09:59:52] <Matthieu> or fail with an error
[09:59:55] <mszefler> yeah
[10:00:21] <assaf> then I suggest we don't expose it, API or UI
[10:01:28] <lance> so I am hearing that we internally have this state
"started"/"stopped" however it is not exposed to the client ( other than
implicitly through the start() to the IL )?
[10:01:46] <mszefler> yeah. the problem you pointed out should happen
only if the deployment state of the server and IL gets out of synch.
Which of course, should not happen.
[10:02:17] <lance> and the recourse is to restart the IL?
[10:02:41] <mszefler> Well if the IL is written poorly, then there is no
recourse.
[10:02:49] <assaf> undeploy the process?
[10:02:57] <mszefler> yeah, hard undeploy
[10:03:12] <mszefler> i view this as an IL bug though.
[10:03:24] <mszefler> since the IL has a lot of methods that can inspect
the deployment state of the server
[10:03:28] <mszefler> it has no excuse for messing it up
[10:03:33] <lance> right - I should have said - fix the IL and retart
[10:05:07] <lance> this sounds okay to me
[10:06:29] <mszefler> Ok, any other comments on this issue?
[10:07:12] <lance> when you say "since the IL has a lot of methods ..."
- it would not see this "stopped" state - correct?
[10:07:35] <mszefler> no. implicitly it knows the process is stopped
(because it has not started it)
[10:08:02] <mszefler> every process is stopped when the IL starts up.
[10:08:23] <lance> right "implicitly" - there is no way for the IL to
explicitly ask using some management method - correct?
[10:08:28] <mszefler> correct
[10:08:38] <lance> okay - thanks for the clarification
[10:10:16] <Matthieu> cool, any other state? like "maybe started"?
[10:10:26] <lance> do folks have time to talk about scope or should we
save that? I think Alex has a few things to discuss as well?
[10:10:27] <mszefler> So I think now we have the terminology we can all
agree on (active,retired) (enabled/disabled|suspended) and
(started,stopped). and hopefully we'll all know what we mean from now on .
[10:10:45] <lance> agreed
[10:10:55] <mszefler> scope seems like a natural next step
[10:11:06] <mszefler> alex what did you have on the agenda?
[10:11:32] <assaf> I'm lost: deployed undeployed?
[10:12:02] <mszefler> huh?
[10:12:31] <boisvert> We could talk about the Content API next --
assuming we are clear on the deployment terminology :)
[10:12:46] <mszefler> is assaf really lost?
[10:13:08] <lance> I would rather finish out the scope discussion before
moving on the to Content API.
[10:13:11] <assaf> what happened to deployed/undeployed?
[10:13:19] <mszefler> oh. forgot about that.
[10:13:34] <mszefler> should be on the list
[10:13:43] <boisvert> Yes, I think it's a good idea to complete the
scope discussion
[10:13:45] <assaf> I'm counting how many things I can do with a process
definition
[10:14:03] <assaf> and wondering, where's the cheatsheet :-)
[10:14:29] <boisvert> Maciej, could you summarize your understanding for
Assaf?
[10:14:43] <boisvert> (and the rest of us!)
[10:14:57] <mszefler> in an email i take it?
[10:15:12] <boisvert> i think it would help before we move on to scope
[10:15:34] <mszefler> OK.
[10:15:35] <mszefler> summary
[10:15:41] <mszefler> User-Level Process States
[10:15:59] <mszefler> - Undeployed - Process is unknown to the server.
Blissful ignorance.
[10:16:48] <mszefler> Deployed - Process has been made available to the
BpelServer by the user (mediated by the IL). Process is in server's
persistent storage and accessible to PMAPI methods.
[10:17:29] <mszefler> Active - Process is acting "normally". Can create
new instances.
[10:17:52] <mszefler> Retired - existing instances of a process can
execute, but new instances cannot be created.
[10:18:21] <mszefler> Disabled/Suspended - Existing instances of a
process cannot execute, new instances cannot be created.
[10:18:43] <mszefler> INTEGRATION LAYER STATES
[10:19:20] <mszefler> Stopped - No activity occurs on behalf of the
process regardless of USER-level state
[10:19:36] <mszefler> Started - Activity occurs on behalf of process per
USER-level state restriction.
[10:20:11] <mszefler> When BPelServer is started, all processes are in
the STOPPED state. IL must start each process, by invoking the
start(PID), start(DU), or startAll methods.
[10:20:21] <mszefler> -fin-
[10:20:48] <boisvert> (i'm digesting)
[10:22:24] <assaf> I'm clear
[10:23:51] <lance> sorry - just had a few more thoughts - when the IL is
starting up wouldn't it starve a process of events until everything (
i.e. sockets ) is ready?
[10:24:24] <lance> perhaps timers would not fall into that
[10:24:26] <mszefler> there may be timer events in the engine
[10:24:32] <lance> :)
[10:24:52] <lance> I'm done
[10:24:59] <lance> with questions
[10:25:40] <h2o> I have one.. what about some auto-start after IL startup?
[10:26:05] <mszefler> autostart?
[10:26:38] <h2o> you said - "IL must start each process, by invoking..."
etc.
[10:26:55] <mszefler> well, instead of autostart. it can call startAll()
[10:27:08] <mszefler> depending on the IL, that may be all that is necessary
[10:27:20] <h2o> and having the IL call startAll would be external or a
prefs setting
[10:27:30] <mszefler> it would be up to the IL implementation.
[10:27:45] <h2o> OK, thats it
[10:28:18] <h2o> was thinking about unattended operation and rebooting etc.
[10:28:53] <mszefler> the theory is that the IL will call start on all
the things that need starting. So after reboot, the IL would do this.
[10:29:35] <mszefler> again, these are not user-visible states, so a
restart will be indistinguishable from a normal startup
[10:30:20] <mszefler> ok. scope?
[10:30:33] <lance> yep
[10:32:08] <lance> can we define the different scope levels ( i.e.
Package,PID,PID+version)?
[10:32:37] <mszefler> Sounds good, go ahead.
[10:33:14] <lance> I noticed that you/Matthieu have defined something
called a DeploymentUnit?
[10:34:00] <mszefler> i thought that was from the deployment spec.
[10:34:08] <lance> so the scope levels would be DeploymentUnit,process
definition,process definition + version
[10:34:28] <boisvert> Yes
[10:34:51] <boisvert> how about "package", "process" and "version" scope ?
[10:35:13] <boisvert> to simplify the terminology
[10:35:37] <boisvert> Am I correct to say that a package (deployment
unit) can have multiple processes?
[10:35:38] <mszefler> did we come to a conclusion on the concept of
version as distinct from process?
[10:35:46] <lance> yes - I did define a deployment unit however I was
thinking it would not be maintained by the ODE process definition
repository. If folks think it makes sense to retain the concept in the
repository I'm okay with a that
[10:36:29] <lance> my understanding is that a package can have n processes
[10:36:39] <assaf> I think it does
[10:36:42] <mszefler> yes
[10:37:00] <lance> yes - I think version is distinct from process
[10:37:33] <mszefler> does version n+1 of a process have the same PID
and version n
[10:37:34] <mszefler> ?
[10:37:53] <boisvert> i think we go back to the definition of a version
[10:37:53] <mszefler> (s/and/as/)
[10:37:54] <lance> that has been my thinking
[10:38:15] <assaf> PID no, process name yes?
[10:38:36] <mszefler> process name is kind of an ambiguous concept
[10:38:43] <mszefler> there is the process definition name
[10:38:46] <mszefler> then there is the PID
[10:38:50] <mszefler> often the two are the same
[10:40:06] <lance> In this context I was thinking PID = process QName
[10:40:27] <mszefler> as distinct from process definition qname?
[10:40:38] <mszefler> or you mean PID=process definition qname?
[10:40:40] <lance> so when talking about scope (package,PID,version) I
am thinking about what is visible to the user
[10:41:02] <mszefler> ok perhaps we should have a naming interlude here
[10:41:33] <mszefler> the way PID is used in the API right now is
distinct from the process definition qname
[10:41:58] <mszefler> you can for example deploy the same process
definition in two deployment units (or in the same unit for that matter)
under different PIDs
[10:42:30] <mszefler> so to use the Java Analogy, Process Definition
QName is like a class. PID is like an object.
[10:43:07] <boisvert> Wouldn't this be confusing for the user?
[10:43:16] <lance> right - however the PID is user defined - correct?
[10:43:20] <mszefler> yes
[10:43:32] <mszefler> although it defaults to the process definition
namespace
[10:43:46] <mszefler> s/namespace/QName
[10:44:10] <lance> right - but its not some ID assigned by the
engine/compiler
[10:44:21] <mszefler> correct
[10:44:59] <mszefler> i think reuse of process requires this distinction
[10:45:06] <boisvert> given a PID, I can retrieve a unique process qname
and version?
[10:45:24] <lance> so when the user is interacting with the PMAPI they
will want to manage things through this PID
[10:45:30] <mszefler> lance- yes
[10:45:36] <mszefler> boisvert- no version in the api yet
[10:45:51] <mszefler> boisvert- but yes you could get the definition
qname given the pid
[10:46:22] <lance> so from a scoping standpoint that is why I see a PID
having multiple versions
[10:46:30] <boisvert> is it the intent to have a one-to-one mapping
between PID <-> Process QName + Version ?
[10:46:47] <mszefler> i dont think so
[10:47:05] <lance> I think its one to many
[10:47:12] <boisvert> so if I undeploy a process through the PM-API, do
I pass PID (only) or PID + Version ?
[10:47:13] <mszefler> i think its PID+version 1-->*Process QNAME
[10:47:22] <mszefler> right now PID
[10:47:25] <mszefler> future ?
[10:47:48] <boisvert> I thought we agreed that multiple versions of a
process have the same process qname
[10:48:11] <mszefler> i doubt that
[10:48:18] <mszefler> perhaps the same pid
[10:48:32] <mszefler> the process definition would change from version
to version, so it will have a different name
[10:48:38] <mszefler> or should at least
[10:48:39] <lance> yes - same PID but the process QName could change
[10:48:39] <assaf> how many names can a process have?
[10:49:11] <mszefler> well. one
[10:49:12] <boisvert> I'm confused here; given a PID can I retrieve a
single process definition?
[10:49:18] <boisvert> if not, I don't see the need for the PID
[10:49:38] <mszefler> of course you can.
[10:49:45] <mszefler> given a pid you can get the definition
[10:49:53] <boisvert> not if it has multiple versions
[10:50:20] <mszefler> well in that case you need pid+version
[10:50:21] <assaf> so two processes can have different names but the
same pid name, that's three names
[10:51:44] <lance> I have been thinking that the PID is what the IL uses
for the EPR - the process name doesn't matter
[10:52:07] <mszefler> No, PIDs dont really matter to the IL
[10:52:20] <mszefler> the partnerlinks are given arbitrary qnames
[10:52:27] <mszefler> that have no relation to the PID
[10:53:14] <mszefler> assaf: There is one name for a process its the PID
[10:53:40] <mszefler> the process definition qname is not the same thing
[10:54:19] <assaf> then what is it?
[10:54:28] <mszefler> its the name of the definition.
[10:54:39] <mszefler> i can create a process definition to model a fifo
queue call it "FIFO"
[10:54:56] <mszefler> then i create a PID "ReservationFIFO" that uses
defintiont "FIFO"
[10:55:04] <mszefler> is that not clear?
[10:55:12] <assaf> the use case is not clear
[10:55:25] <mszefler> reuse of process definitions
[10:55:29] <mszefler> is the use case
[10:56:03] <assaf> isn't that just like extending one class to another
without changing a single method?
[10:56:13] <mszefler> no
[10:56:18] <mszefler> its not extension
[10:56:20] <mszefler> its instantiation
[10:56:25] <mszefler> (the analogy)
[10:56:46] <mszefler> each PID can be connected to different endpoint
[10:56:52] <mszefler> it can have different process properties
[10:57:06] <mszefler> only the behavior is the same
[10:57:41] <assaf> that's a deployment
[10:57:53] <mszefler> yep
[10:58:03] <mszefler> depoyment ~ instantitation
[10:58:16] <mszefler> process definition ~ type
[10:58:20] <mszefler> pid ~ instance
[10:58:24] <assaf> (and I'm not too big on deploying the same process
twice either)
[10:59:03] <mszefler> same process definition, different process
[11:00:11] <boisvert> can't you achieve the same thing by copying a
definition and changing the process qname ?
[11:01:05] <mszefler> of course. but thats like rewriting a class
everytime we neeed a new object.
[11:01:16] <mszefler> if we want that, we dont need deploy.xml
[11:01:25] <boisvert> an object is the instantiation of a class
[11:01:26] <mszefler> we can stick all sorts of stuff in .bpel
[11:01:52] <boisvert> same as a process instance being the instantiation
of a process definition, no?
[11:02:01] <mszefler> no
[11:02:14] <mszefler> a process is the instantiation of a process definition
[11:02:38] <mszefler> a process instance is more like a thread
[11:03:37] <boisvert> if a process is the instantiation of a process
definition, what is a process instance?
[11:04:03] <mszefler> a process instance is more like a thread
[11:04:56] <boisvert> i understand want you mean, but i'm uncomfortable
with the concepts
[11:05:20] <boisvert> am i the only one having this issue here?
[11:06:06] <assaf> I'm comfortable with the concepts, just worried that
I'll need a pilot license to deploy my first process
[11:07:54] <lance> I understand the concepts and think we are injecting
flexibility over complexity
[11:08:26] <mszefler> as far as i can tell there are two alternatives:
[11:08:52] <mszefler> 1) process definition is a reusable definition
[11:09:10] <mszefler> 2)process definition is the instantitation of a
process
[11:09:27] <boisvert> process definition ==(instantiate)=> process
==(instantiate)=> instance?
[11:09:29] <mszefler> if you want (2), and want simplicity, you need to
get rid of deploy.xml
[11:09:35] <boisvert> do you see were it gets confusing?
[11:09:58] <mszefler> that's because we're using instantiate twice
[11:10:07] <mszefler> conceptually its not complciated
[11:10:16] <mszefler> its like loading a db schema twice
[11:10:27] <mszefler> and then having multiple rows
[11:10:31] <boisvert> In Java you don't have this difference, AFAIK
[11:10:34] <mszefler> pretty routine concepts.
[11:10:43] <lance> From a development lifecycle standpoint I think 1 is
the better option
[11:11:18] <assaf> you don't have that different in SQL either
[11:11:22] <Matthieu> I think if you replace the "process" step in
Maciej's diagram with process definition+version that instantly gets
more clear
[11:11:29] <assaf> the table schema will always generate the same table
[11:11:54] <mszefler> I can load the same DB schema twice into different
databases
[11:11:58] <mszefler> its exactly the same
[11:12:04] <assaf> different databases
[11:12:10] <mszefler> different processes
[11:12:13] <boisvert> or difference namespaces
[11:12:18] <boisvert> (different)
[11:13:14] <boisvert> i thought the "version" was supposed to get us
this flexibility
[11:13:16] <Matthieu> so are we talking about reusable process
definitions or versioning here? the first can overlap the second but it
also introduces additional complexity
[11:13:36] <boisvert> process => version => instance
[11:13:51] <Matthieu> yep
[11:13:54] <boisvert> a process would be abstract
[11:14:05] <boisvert> a version would be the instantiation of a process
[11:14:18] <boisvert> and an instance (for lack of a better term) would
be the instantiation of a version
[11:15:16] <boisvert> but the problem here is that people say "version"
to mean different process definitions
[11:15:43] <boisvert> which wouldn't necessarily be the case
[11:15:45] <mszefler> different versions of a process definition
necessarily have different qnames
[11:16:10] <assaf> my problem is not understanding the layers of abstraction
[11:16:29] <assaf> but how many people will use this feature ... vs how
many people will have a problem deploying processes because of this feature
[11:16:37] <mszefler> no one will have a problem
[11:17:18] <Matthieu> they will try to redeploy a different definition
with the same process definition qname
[11:18:20] <lance> I thought is was same PID potentially different
process definition qname
[11:19:21] <mszefler> I think we are creating confusion where there is none
[11:20:05] <Matthieu> ok so use case 1
[11:20:17] <Matthieu> I write an hello world : receive / reply
[11:20:33] <Matthieu> I update my hello world to be receive / assign / reply
[11:20:58] <Matthieu> what do I do to deploy this new version while
still having instances of the first version running?
[11:21:28] <mszefler> thats the versioning problem.
[11:21:40] <mszefler> i would imagine if you are a normal person youd
like to do the following:
[11:22:09] <mszefler> if I had a defiitniton HelloWorld/2006/1/1 I would
create a new definition callled HelloWorld/2006/1/2
[11:22:53] <mszefler> Then I would want to deploy this under PID
"MyHelloWorld" which is already running.
[11:23:47] <assaf> I wouldn't
[11:23:52] <Matthieu> there aren't that many normal person out there
[11:24:03] <assaf> I would just deploy again
[11:24:16] <Matthieu> same here
[11:24:37] <mszefler> well if you are sloppy you could still do this
[11:24:47] <boisvert> same here; it's a new version of the process
because it has the same process qname
[11:25:10] <mszefler> no!
[11:25:18] <mszefler> thats forcing people into bad behavior
[11:25:34] <assaf> on the contrary
[11:25:35] <mszefler> if you change a definition, you give it a new name.
[11:25:55] <assaf> I agree with your definition of "sloppy", but let's
be realistic, it's also "productive"
[11:26:00] <boisvert> a new version number is not sufficient?
[11:26:09] <mszefler> there is nothing in this model that prevents
sloppy behavior
[11:26:22] <boisvert> if i don't give you a version number, you can
create one for me
[11:26:24] <mszefler> however your model precludes non-sloppy behavior
[11:26:30] <boisvert> version = existing version + 1
[11:27:09] <mszefler> sure
[11:27:16] <mszefler> you dont need version numbers
[11:27:25] <mszefler> (you dont need to specify them)
[11:27:32] <mszefler> you just need to deploy to the same PID
[11:27:52] <mszefler> you can be sloppy about it (dont specify a pid,
dont change the definitoin qname)
[11:27:58] <boisvert> so what's the benefit of having a PID if the user
always controls the process QName?
[11:28:03] <Matthieu> none
[11:28:15] <boisvert> I thought PID was an engine artifact
[11:28:15] <mszefler> or you can be proper (define a pid, and then
define new qnames for each version of your procesS)
[11:28:29] <mszefler> pid is not an engine artefact
[11:28:34] <mszefler> it is a user defined name
[11:28:46] <mszefler> if it is not specified the process definition name
is used.
[11:29:29] <boisvert> ok, so we're back to the benefit of having a
meta-model with process definition and process versus simply having
processes
[11:29:42] <mszefler> what meta model?
[11:30:06] <lance> Maciej in the current iapi can you please relate ( if
possible ) PID to the param serviceID in BpelEngine.createMessageExchange()?
[11:30:20] <mszefler> there is no relation
[11:30:31] <mszefler> serviceId is defined in the deployment descriptor
for each partner link
[11:30:44] <mszefler> it is user-defined.
[11:31:23] <lance> and this isn't the PID?
[11:31:32] <mszefler> no
[11:31:46] <lance> okay - thanks
[11:31:54] <mszefler> a single process has a pid and multiple service
ids corresponding to each endpoint
[11:32:27] <Matthieu> I think the pid should be nuked from anything public
[11:32:42] <mszefler> disagree completely
[11:32:46] <Matthieu> it's already confusing people here when it comes
to versioninf
[11:32:51] <Matthieu> (versioning)
[11:33:00] <lance> I'm just confused where the map is and need to spend
some time looking into it
[11:34:10] <boisvert> i agree with Matthieu
[11:34:28] <boisvert> i think it would be simpler to have process qname
and version in the APIs
[11:34:38] <mszefler> you are digging a deep hole
[11:35:09] <boisvert> then I need to better understand what is the
requirement for PID and how it fits into the picture
[11:36:08] <mszefler> if you like you can think of the PID as the
definition QName, and never worry about anything else
[11:36:55] <boisvert> that isn't helping me
[11:37:24] <mszefler> the point is that this approach is much more
flexible and still allows the usage pattern you prefer.
[11:37:45] <mszefler> and doesnt force all other users into what i
consider to be a bad practice.
[11:38:28] <assaf> I think most people will follow the bad practice, so
we might as well optimize for that
[11:39:01] <mszefler> theres a difference between optimizing for and
forcing bad practices
[11:39:06] <assaf> (and I'm stating that while disagreeing the bad
practice is actually bad)
[11:39:26] <mszefler> changing a process definition without changing the
name is a bad practice.
[11:40:05] <boisvert> even if you change the version?
[11:40:14] <assaf> I think spending too much time on naming is bad practice
[11:40:19] <mszefler> BPEL spec does not have a version fields
[11:40:27] <assaf> if you're making insignificant changes, don't bother
naming them
[11:40:36] <boisvert> BPEL doesn't have the notion of PID either
[11:40:40] <assaf> if you're making significant changes, make a new
process (under a new name)
[11:40:43] <mszefler> its out of scope
[11:40:52] <mszefler> as are many things
[11:41:13] <assaf> so you get versions of all the "same process, just
changed" which is how most people think of it
[11:41:24] <assaf> and separate processes side by side
[11:43:43] <boisvert> I think it's fair to say that we haven't reached a
level of concensus yet
[11:44:01] <boisvert> Maybe we could develop a set of use-cases
[11:44:17] <boisvert> and then try to apply the various approaches to
these use-cases
[11:44:42] <mszefler> sounds fantastic to me
[11:44:56] <boisvert> It would certainly help me understand the added
value of PIDs :)
[11:45:41] <boisvert> How are we doing on time?
[11:45:55] <boisvert> Time to break or time for the next subject?
[11:46:17] <lance> since I am working on the deployment spec I will
volunteer to write up the use cases
[11:46:36] <boisvert> thanks Lance
[11:46:43] <Matthieu> perfect
[11:46:43] <boisvert> I think I might be able to contribute some too
[11:46:50] <mszefler> i will send you some use cases
[11:47:01] <lance> great - thanks
[11:47:40] <Matthieu> next subject?
[11:48:02] <boisvert> Personally, I'd prefer to continue another time
[11:48:14] <boisvert> Since I had prior engagements for the rest of the
day ... :)
[11:48:33] <lance> agree - another time would be preferrable
[11:48:48] <Matthieu> what about getting to less controversial subjects
that could be close in 10mn? and scheduling the others for next time?
[11:49:09] <boisvert> I'm fine with that
[11:49:17] <Matthieu> actually I'd just like to hear a bit from dims if
he's till here?
[11:50:15] <boisvert> In the mean time, I'd like to make an
'advertisement' for ApacheCon
[11:50:32] <Matthieu> good point
[11:50:44] <boisvert> and suggest that we have some kind of face-to-face
during that time
[11:51:10] <boisvert> it's Oct 11 – 13
[11:51:20] <boisvert> in austin texas
[11:52:27] <Matthieu> http://www.us.apachecon.com
[11:52:38] <Matthieu> dims?
[11:53:02] <Matthieu> are you with us?
[11:53:18] <boisvert> Maybe move to another subject and ping him separately?
[11:53:23] <Matthieu> ok
[11:54:39] <boisvert> Lance, regarding persistent DAO implementation,
did you want to frame the context?
[11:55:35] <lance> Only in that there was talk of moving away from
Hibernate to something else
[11:55:55] <Matthieu> that will be necessary if we want to exit the
incubator at some point
[11:56:16] <Matthieu> I mean exit by the big door and not the little
dark one
[11:57:00] <lance> are there suggestions?
[11:57:44] <boisvert> Apache OpenJPA
[11:57:49] <boisvert> in the incubator I believe
[11:57:52] <Matthieu> yep
[11:58:17] <boisvert> http://incubator.apache.org/openjpa/index.html
[11:58:28] <boisvert> it's an offspring of BEA Kodo
[11:58:59] <lance> okay - I'll look into that
[11:59:39] <boisvert> no other good suggestion on my side
[12:00:12] <boisvert> beyond manually-coded JDBC or perhaps Spring JDBC
[12:01:03] <boisvert> Ok, then let's break folks
[12:01:12] <boisvert> and try to reconvence next week?
[12:01:12] <Matthieu> for the project website I think we can agree on a
structure (left menu content) offline
[12:01:20] <Matthieu> I'll send a mail about it
[12:01:23] <Matthieu> yep
[12:01:32] <lance> sounds good
[12:02:57] lance [EMAIL PROTECTED] has quit IRC: "CGI:IRC
(EOF)"
### End of existing data buffer.
