Use Cases for PIDs

[Maciej Szefler <mb...@intalio.com>]

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.

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.

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").

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)
* 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).

-Maciej

Re: Use Cases for PIDs

[Assaf Arkin <ar...@intalio.com>]

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 <mb...@intalio.com> 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

Re: Use Cases for PIDs

[Maciej Szefler <mb...@intalio.com>]

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
>
>

Re: Use Cases for PIDs

[Assaf Arkin <ar...@intalio.com>]

On 8/23/06, Maciej Szefler <mb...@intalio.com> 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