[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set
Ron, I agree with the scenario in which certain "policies" are required by a process model. It is no clear to me, though, that we should define a BPEL native mechanism to deal with it. I'd rather prefer to see a good separation of concerns in which BPEL focuses on the business logic and another "composable" spec provides a general purpose mechanism to attach QoS requirements to processes, interfaces etc. WS-Policy is an example of that spec. WS-Policy lets you attach policies to either the process, its interfaces or its deployed artifacts (services, ports, urls.) One nice thing about this is that policy can be applied at multiple points (business process definition, deployment, dynamically at runtime) using a single mechanism. Paco Ron Ten-Hove <Ronald.Ten-Hove@ To: Satish Thatte <satisht@microsoft.com> Sun.COM> cc: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set 09/24/2003 02:49 PM Satish Thatte wrote: As for the RosettaNet example, I agree that there are cases where additional policies regarding unexpected messages may apply when the message is properly authenticated and validated. There are also policies that have to do with SLAs and signatures/non-repudiation, etc. I believe these policies should not be expressed within BPEL. I may be guilty of revisiting ground we have already covered, but I would like to point out that there are very good business reasons that a business process should specify some requirements that will affect messaging QoS features. For business reasons I may require: Privacy "over the wire" due to the sensitive nature of the contents of the message. Tamper-proofness for certain messages due to trust issues. Non-repudiation of receipt. Authorization of the requestor (i.e., purchasing agent or similar authority). These are all things that the business analyst may require, yet our business modelling language has no place for them. They are not complete expressions of policies, but a set of requirements / restrictions needed when such policies are implemented. It has been suggested elsewhere on this list that the use CPP/A could address this issue, but this fails to capture the business-level requirements in the process model itself. Shouldn't our business process modelling language have some business-oriented features? Features that could guide (but not fully define) the QoS supplied by the messaging and security infrastructure? -Ron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]