What is the benefit of forcing the service signature to be the same for
a given process name? Is there a complexity aspect that I am
missing? It seems like the engine is trying to enforce a specific
policy instead of providing a flexible deployment mechanism.
Say I change the signature of a Java class, do I need to change its name?
alex
Lance Waterman wrote:
I think if P(v1) and P(v2) have different operation+endpoint then P(v2)
should be a new process definition ( name/namespace ) and not a new
version.
It seems like P(v2) is trying to define a new interface for P(v1). What
happens if P(v1) and P(v2) do have the same operations and both are
active?
I think in the typical use case we are trying to solve ( i.e. the
client app
is not required to change )..
Lance
On 8/8/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Maciej Szefler wrote:
> I think that clarifies it, and also suggests that our terminology
is not
> the best. The things that is confusing is that the retired
processes are
> not "inactive". Lance's 'current' is better in this respect, but
has no
> good opposite (perhaps "legacy").
>
Retired only means that you cannot create new instances -- existing
instances remain active and are allowed to complete normally. This
terminology is already used in other widely available process engines
and that's why I've been using it.
Again, I don't understand why we need the concept of "current" since you
only need to define which process is logically hooked to a given
operation+endpoint for routing purposes.
Or said another way, I don't understand why you could not have P (v1)
and P (v2) both activated at the same time if they do not share the same
operation+endpoints.
alex
