OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Q: process category?


Edwin,

Edwin Khodabakchian wrote:
Ron,
 
Assigning a UUID to a process opens the door to the problems related to change management, versioning and life cycle management. Unless we decide to get down to the level of what a BPEL deployment unit looks like, I am not sure that adding UUID brings any value.
I think adding a UUID [1] imposes a much weaker set of requirements on BPEL design tools. Versioning in particular is not mandated. Supporting a UUID could be as simple as updating the UUID every time the process definition is committed to whatever repository is in use. I don't think this introduces any new requirements for change management, or life cycle models to be followed. Tools can be free to impose their own models of these things.

Design and deployment tools must maintain complex contexts, involving many entities (BPEL, WDSL, deployment descriptions, environment information, higher-level design information, etc). The UUID will make tying BPEL definitions to such contexts simple and unambiguous, without us (the BPEL TC) having to anticipate how that context will crafted or behave. It will also facilitate portability across different design environments, since implementation-specific context management should not then depend on proprietary extensions to BPEL to accomplish the same goals.

This makes it simple to trap a condition that today's BPM systems must handle, using a wide range of change management techniques and tricks: what if someone changes the process definition that I've carefully deployed? The answer to this varies, but the need to detect the situation in the first place is universal.

Finally, the UUID addresses a problem that has plagued XML users for years: the lack of a unique serialization of the same XML info-set[2]. This makes comparing two XML documents (say BPEL process definitions) a non-trivial exercise, and text-based revision control starts to become useless. This is especially true when working in heterogeneous environments, where a variety of XML manipulation tools may be in use. (Imagine two trading partners working out an pair of abstract BPEL definitions to automate their electronic interactions.)
 
Cheers,
-Ron

[1]
Or adding equivalent uniqueness requirements to existing process attributes. See my response to Satish Thatte, Sep 4, 2003 13:35, for some discussion of this.
[2] Yes, I know, this is a bit of low-level consideration, but this problem has annoyed me in various guises for years, and I'm sure I'm not alone!



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]