[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
> * 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, if they had to be, could be implemented currently by a BPEL script, or the services which it <invoke>s. dealing with an out of order message is not, since it will never arrive at a BPEL process. danny ----- Original Message ----- From: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM> To: "Satish Thatte" <satisht@microsoft.com> Cc: <wsbpel@lists.oasis-open.org> Sent: Wednesday, September 24, 2003 11:49 AM Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set > 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]