Lance, I'm pointing out that any restrictions we place on naming the process will bear no affect on the client. It doesn't make the client life easier, ror protect the client from breakage, but it could make development harder.
Assaf On 8/8/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
Assaf, I'm not following all of this. My main goal here is not to break the client when a process is redeployed. Lance On 8/8/06, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > The client breaks when the endpoint changes, or the messages/operations > accepted by the endpoint change. > > Whenever you deploy a new version -- same or different name, version > number, > tagged or not -- that accepts the same messages on the same endpoints, the > client does not perceive any difference. It still invokes the process the > same way, regardless of how the server chooses to refer to that process > definition. > > However, changing the signature and changing the process name, breaks the > client. Because the client does not talk to the process, the client talks > to > the service, and so changing the signature breaks the client. Changing the > process name is immaterial. > > A restriction that "if you change the signature you must change the > process > name" does not in any way protect the client from breaking, but makes life > incredibly hard for developers. It's like asking you to change the Java > class name every time you change its signature. When you're writing code, > how often do you change signatures? > > Assaf > > On 8/8/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > > > > Assaf, > > > > From a client application's perspective which of the three options > > requires > > a change in the way I send a message into the BPEL engine? > > > > Lance > > > > > > On 8/8/06, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > > > > Reading through the BPEL spec, I get the impression that however you > > > decide > > > to name a process is meaningless. If you send a message to its > > initiating > > > activity it will start. If you send a message to the wrong endpoint, > it > > > won't. > > > > > > So clearly people who want to version processes need to take into > > account > > > that Bar replacing Foo on same instantiating activity, means Bar is > the > > > version you now use, not Foo. Which means you can get really creative > > with > > > process names, like Order, OrderV1, Order_V2_With_25%_More_Activities. > > > > > > > > > But there are two requirements you can't solve with overriding and > > naming. > > > > > > One, only very few people can actual design, deploy and forget. Most > > > people > > > go through some iterative process, so you end up deploying different > > > iterations of the same process as you're working to get it to done. > And > > > naming each deployment, that's like saving every draft you write under > a > > > different name. > > > > > > The source control approach is much better, it gives each version a > > serial > > > number and datetime stamp, so you can easily track changes and > rollback. > > > If > > > you have some instance running, you know which process definition it > > > belongs > > > to: not the name, but the actual definition you pushed to the server > > > before > > > it was instantiated. > > > > > > (In some other development environments, deployment happens strictly > > > through > > > SVN and people in fact use the SVN version number to mark each > release) > > > > > > Two, numbers and timestamps are fine but a burden when you do want to > > > track > > > milestone releases, especially in production. So you want to associate > > > some > > > meaningful name, usually related to that milestone, like "Release 1", > > > "Release 1.1", whatever. A tagging mechanism separate from the process > > > name > > > has the benefit that you can clearly see its timeline, searching by > > name, > > > ordering by sequential version number, and displaying those tags. > > > > > > If tags sound familiar, source control does that as well. > > > > > > > > > So I personally prefer a system whereby: > > > 1. I can replace Foo with Bar because I decide Foo is a better name, > and > > > it's taking over Bar's role (same instantiation). > > > 2. Or replace Foo with another Foo, and be able to see sequence of > > > deployment using serial number/datetime I don't have to worry about. > > > 3. Or affix a specific version label/tag. > > > > > > #1, I don't see that happening often, and you can always retire Foo > and > > > activate Bar. > > > > > > #2 is something the server already has to do in order to maintain > > > instances > > > using the old version, so just give me access to the sequence > > > number/deployment timestamp. > > > > > > #3 is a really nice feature to have. > > > > > > Assaf > > > > > > > > > On 8/8/06, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > > > > > > > Lance Waterman wrote: > > > > > On 8/8/06, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >> Lance, > > > > >> > > > > >> For consideration, I would like to briefly review the design that > I > > > had > > > > >> in mind for versioning in PXE. I think it's similar in spirit to > > > what > > > > >> you describe in your deployment spec. > > > > >> > > > > >> First, each process definition would be identified by its fully > > > > >> qualified name (/name/ and /namespace/ attributes) and a version > > > > >> number. The process engine would manage the version number in a > > > > >> monotonically increasing fashion, meaning that each time a > process > > is > > > > >> redeployed, the version number increases. > > > > > > > > > > > > > > > I don't understand the need for a version number that is managed > by > > > the > > > > > engine. I think a client may use whatever version scheme they use. > > We > > > > > just > > > > > need to validate that the version identifier is unique at > deployment > > > > > time. > > > > There is no strict need for a version number managed by the > engine. I > > > > think this idea came up when we wanted to simplify the management > > > > interfaces and wanted to avoid the need for an extra user-provided > > > > identifier if you already encoded version information in the > > > > name+namespace. It made it easier to define and communicate the > > > > "latest" process version. > > > > > > > > > I agree with Maciej's comments on this and would like to add from > > the > > > > > deployment spec under sec 1.2.5: > > > > > > > > > > *CONSTRAINT: Any change in the service interface ( i.e. a new > > > <receive> > > > > > element ) for a process definition will require a new identifier ( > > i.e > > > . > > > > > name/namespace ) within the definition repository. Versioning is > not > > > > > supported across changes in the service interface and shall be > > > > > enforced by > > > > > the deployment component.* > > > > > > > > > > I would like to make sure folks are okay with this as well. > > > > Personally, I would be against this because it would mean that I > > cannot > > > > deploy a new process definition that implements additional > interfaces > > > > (among other things). > > > > > > > > I don't see the reason to bind together the notions of service > > interface > > > > and versioning. > > > > > > > > > > > > > In general I would like to define the concept of a "current" > process > > > > > definition. The "current" process definition is the definition > used > > by > > > > > the > > > > > engine on an instantiating event. There could be instances running > > in > > > > the > > > > > engine that are using other versions of a process definition, > > however > > > > its > > > > > not possible to have multiple versions that are used for > > instantiating > > > > > new > > > > > processes ( see Maciej's reply on endpoints ). Through management > > > > > tooling a > > > > > client will identify the "current" process. > > > > I don't think we need to define the notion of a "current" > process. I > > > > think we only need to define which (unique) process provides an > > > > instantiating (non-correlated) operation on a specific endpoint. > > > > > > > > alex > > > > > > > > > > > > > > > > > -- > > > CTO, Intalio > > > http://www.intalio.com > > > > > > > > > > > > > -- > CTO, Intalio > http://www.intalio.com > >
-- CTO, Intalio http://www.intalio.com
