On 8/23/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
Lance, Alex, As promissed in IRC, some use cases: 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. 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? 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. 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. I think that's a burden on the developer, which is why I don't like the version-in-name proposal. Rename when it's distinctly different, which happens to be when you're seriously considering side-by-side deployments. 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: 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. * 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. 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. Assaf -Maciej
-- CTO, Intalio http://www.intalio.com
