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 priority?


Sid,

Sid Askary wrote:
Ron,
The latter can be viewed as a subset of the former.  A Business priority may use Technical resources to achieve its goal.  The relationship between the two is what I see as implementation specific.
    Business priority may also be reflected in the business process logic itself, if this information is available as state data. If the priority is a static attribute of the process definition, then perhaps this is a moot point, otherwise it could map to some process variable or otherwise accessible data item.


IMHO, The notion of a "priority" can be extended to the level of an activity (read workflow task) but it would make for quite an elaborate definition (not to mention implementation).  I'm inclined to think that priority" can be viewed as an attribute of the process.  This "process priority" attribute can then provide an abstraction for a combination of both intentions - and I see that in line with multiple intentions as far as BPEL is concerned.
    We should not confuse BPEL with a workflow language; the available activities cannot model workflow except in the most abstract way. Given the primative notion of work items, it makes no sense to impose priority at the activity level.

What do you think?
I    t is certainly true that BPEL is a bit schizophrenic, attempting to combine both technical/execution aspects with business modelling concerns. In that light perhaps process priority is more of a hint, that may cause implementation-dependent changes in the process execution, and may cause design-time tools to behave differently, in a manner consistent with the tool's notion of process priority. Or have you some more certain effects of this attribute in mind?

    I think there is a good argument for standardizing non-executable attributes of a process, if these are common and useful in modelling. This may be particularly true of abstract processes. Anticipating a little, I can think of two ways we could handle this: incorporation into the specification, or an optional (or even non-normative) extension in an appendix, akin to Java's javax namespace. I'm sure the process modelling crowd out there would have lots of suggestions for items to place in such a category, for both executable and abstract processes.

Cheers,
-Ron


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