[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Q: process category?
Sid, Could that group membership not consist of a set of BPEL process definitions, somehow properly identified? Could we not keep it external to the process definitions themselves? Or is there a use case you have in mind, where the process definitions need to be more "self describing" from the group/categorization standpoint? -Ron Sid Askary wrote: > Folks, > The GUID creates type dependencies that defeat the purpose for > communication of tuples of value. My original question was that the > category can be viewed as an additional tuple for identifying process > group membership (in the global model) for collaboration purposes. It > can also serve as a mechanism to organize (and/or optimize) > computation when dealing with the internal data representation during > process execution. > > Having read some of the responses, I’m inclined to think that the > notion of a category could belong to a top-level element that would > sit above the process. > > --- > Sid. > > On Thu, 4 Sep 2003 13:55:36 -0700, Edwin Khodabakchian > <edwink@collaxa.com> 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. >> >> Edwin >> >> >> _____ >> >> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] Sent: Thursday, >> September 04, 2003 1:35 PM >> To: Satish Thatte >> Cc: Sid Askary; wsbpel@lists.oasis-open.org >> Subject: Re: [wsbpel] Q: process category? >> >> >> Satish Thatte wrote: >> >> >> See below >> >> >> >> >> _____ >> >> >> >> [Ten-Hove] A process category may fall mostly into the "deployment" >> bucket, >> and thus be ultra vires. Alternatively, perhaps it would be useful to >> give >> each process type a globally unique identifier. >> >> >> >> [Satish Thatte] It is easy to manufacture a unique QName from the >> targetNamespace and NCName of the process -- one may claim that this >> is in >> fact implied by the usual semantics of targetNamespaces. >> >> [Ten-Hove] This technique would work, but it is a convention, not a >> guaranteed property of process definitions. Unless one has complete >> control >> of tools, deployment and run-time, a convention cannot be used to >> guarantee >> this uniqueness property. >> >> As an alternative to an explicit uuid attribute, we may try adding >> wording >> requiring the convention you suggest. Something like: >> >> >> The name and targetNamespace of the process must be globally unique. >> If an >> existing process is modified, the name and/or tns must be modified to >> ensure >> that the new version of the process has a unique identity, such that it >> cannot be confused for the old. >> >> >> I don't particularly like this -- it sounds a lot like a hack, and >> makes it >> sound like we never heard of UUIDs! But personal tastes aside, does >> this >> sound reasonable? >> >> Cheers, >> -Ron >> >> >> >> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]