Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

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