Alex, inline ...
On 8/8/06, Alex Boisvert <[EMAIL PROTECTED] > wrote:
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.
I think what I hear you saying is that you want to be able to aggregate several versions of a BPEL process into a single service interface. Such that this aggregated service interface can serve as the interface for several BPEL process versions. I understand this however, what do you propose when the operation+endpoint are identical between process versions? How does the engine know which one to route to ( and I don't want to require a change to the client )? Say I change the signature of a Java class, do I need to change its name? Alex, I think using Java as an analogy is a good way to convey patterns/concepts however, when it's posted as a rhetorical question like this I think it comes across a bit condescending. I'm sure that wasn't your intent but none the less it doesn't work for me. Now, to move forward with your analogy, if I were able to deprecate ( i.e. retire ) specific operations - is that where you are going? Is this something that shows up in the service interface? Does the operation just stop working for deprecated operations? 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 >> >> >
