|
Hi Ron,
You are assuming that the deployment descriptor and the
BPEL artifact are always committed together to their repository. It that case
why wouldn't you use a more local addressing scheme to create a link between
those 2 assets (see web.xml, ejb.xml etc...).
You are also assuming that the versioning scheme that each
vendor will support will be able to impose nicely on this auto-increment UUID
scheme. I think that it will create more confusion. In a real life
scenario, the developer will be exposed to his CVS revision, deployment unit
version and UUID revision....each have their own rules of
change.
Edwin
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!
|