Alex, see inline ...
Lance On 8/9/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Lance, Sorry for the late email, we had an email outage last night. If not sure if this is still relevant now given your earlier email exchanges with Assaf, but see my comments below to further clarify what I meant. Lance Waterman wrote: > 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 )? Not really. I simply want to be able to deploy and activate P(v1) and P(v2) simultaneously if they have no conflicting operation+endpoint tuples.
If I understand you here this does not seem to follow the conclusions from the other thread ( see Assaf's reply ). So perhaps we need more input from you on that thread. This is a development convenience and also leaves the
flexibility and responsibility to the author of the processes to define what a "version" means. The only real requirement that I see is for the engine to be able to detect conflicts during activation to prevent non-deterministic routing cases (see below). > > 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? My apologies, Lance, I did not mean to offend.
No need, it was a silly comment on my part ( I would like to chalk it up to time of day, work load and poor choice of inferences on my part ) To answer your questions, I do not see a need to deprecate/retire
individual initiating operations within a process. I think a process should either be completely activated or completely retired, meaning that all of its initiating operations should be either enabled or disabled. And if one or more operation+endpoint conflicts with any other activated process (across all versions), the engine should prevent the activation of the process.
I'm not sure if this follows the current thread? regards,
alex
