I am making assumptions, I happen to think that's a good thing.
My bias is to focus on addressing the common use case, and I accept that common may relate to a small user base right now, and that may change in the future. But it's the best place to start. If someone feels compelled to deploy processes under different names, the code is open source, the API is well documented, they can build that feature on top of it. If enough people find it useful, let's take that contribution and roll it into the code base. But until then, my bias is to keep it simple and cater to what is necessary<http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It> . Assaf On 8/24/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
Assaf, see comments inline. > Use Case: Unique Version Naming > > A process repository contains a collection of process definitions > > retrievable by their QName. Each version of a process has a distinct > > QName. > > A process is deployed on ODE from the repository using definition > > "FooProcess/2006/11/1". A new version of the process becomes available > > called "FooProcess/2006/12/23", the new version of the process is to be > > deployed in ODE and take over processing for the older version. > > > Versions are commonly used for three different reasons: > 1. You broke it, so you fix it. In the non-ideal world we live in, most > redeployments of a new version are intent to fix and improve, not change > functionality. > 2. Something better comes along. The new process is radically different > from > the old one. > 3. There is more than one way to do the same thing (e.g. domestic and > international shipping). > > In use cases #2 and #3 you should clearly separate and intentionally > communicate that by having different definitions distinguished by name. In > the first use case, there's no benefit, in fact, loss in renaming. > > Consider a client that's developed based on a process definition. If > /2006/11/1 and /2006/12/23 both indicate the same process (from > perspective > of the client), then why are those distinct names? And if you happen to > release early, release often, you get enough of those names that > developers > stop paying attention when a change of name implies a change in > functionality. /2007/1/5 comes along that operates in a totally different > ways, and clients get surprised because they learned to tune out version > changes. > > Name change only when things could break. You are making all sorts of assumptions as to how people like to name their versions, how their development process works, and how they integrate ODE . You are suggesting that we lock them into your assumptions. All I am stating is that the use case is valid and should be supported. There are other ones, like editing a version without changing anything at all, and redeploying it. I'm not suggesting we disallow this practice, only that we allow for the valid use case that I describe. Use Case: Process Reuse > > An enterprise creates a process to describe the interaction with its > > suppliers. The process definition is named "SupplierProcess". The > > enterprise deals with multiple suppliers all communicating over > distinct > > dedicated communication channel. The "SupplierProcess" is to be > deployed > > for each supplier. Each time a new supplier is signed up, the process is > > deployed again on the new channel. Each time a supplier quits, the > process > > for that supplier is undeployed. > > > The parallel would be deploying the same servlet three times so you can > access it on 80, 8080 and 443. And then reploying all three instances when > the code changes. > > Wouldn't it be easier if a process is only deployed once, regardless of > how > many ways you have to access it? You can update the process and reflect > that > across all access points, or just add/remove access points without > crowding > the server with too many process definitions? Again, you are presupposing that they want to do this and would like to force them into the practice you describe. I claim that if they want to deploy a process for each supplier then they should be able to. Use Case: Third Party Process Definitions > > A third-party prepares a process definition that is named according to > > third-party's naming scheme (i.e. "thirdParty:ProcessFoo"). Process is > to > > be > > deployed into an ODE instance employing a different naming scheme ( i.e. > > "myScheme:MyProcess"). > > I'm not convienced this use case is common enough to be on a feature list > until all other problems have been solved. Very few people use ODE or BPEL for anything at the moment, so the notion that this is not common does not say much. By way of ananlogy, very few people write their own software. Use Case: Unique Versoin Naming x Process Reuse x Third Part Process > > Definitions > > Any combination of the above use cases. > > > > Also, I have several axioms that I think are very reasonable and limit > the > > solution space: > > > > * System must be able to deploy any valid definition without needing the > > user to edit the definition (NOEDIT) > > > Changing the process name at every deployment breaks this rule. Unless I > can > predict when deployment will happen, I need to edit the definition prior > to > deployment. You presume too much again. Did I say that the process name has to change? > I think that's a burden on the developer, which is why I don't > like the version-in-name proposal. You clearly misunderstand. There is no version-in-name proposal. This is a use case. I do not suggest that you have to follow this scheme, only that it should be permitted. > Rename when it's distinctly different, > which happens to be when you're seriously considering side-by-side > deployments. Huh? And taken to the extreme, we could easily propose a better mechanism for > reuse by naming all processes "bpws:process". That way you can reuse the > top > element of each process definition (the one hidden by a forest of > namespace > declaration). But it would break a rule I hold in high regard: Huh? Principle of least surprise. > > If the process I have on my development machine is known by one name, the > one that's bugging the system is known by another (which name will the bug > report use?), then I'm going to be surprised. And not in a nice way > because > the time it takes to resolve such a little simple mismatch between > engineering and help desk could mount to hours, sometimes days. I consider > name changes at deployment to be a bad idea. ERROR: the "AcmeSupplier" process failed. See line 55 in BPEL definition "foo:Supplier". * Subject to endpoint restrictions, deployer must be able to designate any > > valid definition as the replacement version of any perviously deployed > > definition (REPLACEMENT) > > * Subject to endpoint restrictions, system must be able to deploy a > valid > > definition regardless of any other definitions already deployed in the > > system (NONINTERFERENCE). > > > If you mean what you say, and say what you mean then neither of the three > would be a problem. Intentional deployment. When I deploy FooBar I intend > it > to replace any previous version of FooBar. and be managed as any other > instance (old or new) of FooBar. And if I don't intend it to replace > FooBar, > I will express that by calling it FooBaz. You are very confused about the difference between what the user CAN do versus what the user MUST do. If the user wants to do what you do, he can, but he should not be forced to. If you force the user to name the BPEL process according to some scheme in order to get his deployment to work, you are violating NOEDIT. So: > * noedit > * replacement > * noninterference > * intentional > * principle of least surprise > > And when I sum up all five, I end up concluding that a process definition > should always be known by exactly one name. > This above statement is false. Assaf > > > -Maciej > > > > > > > -- > CTO, Intalio > http://www.intalio.com > >
-- CTO, Intalio http://www.intalio.com
