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?


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]