The QoS features you
mention below sound like something that could also be described at the WSDL
level (see for example the WS-Policy framework). If that kind of policy
framework gets established in the Web services industry, wouldn't BPEL
unnecessarily duplicate information if it addressed it at the process
level?
Ugo
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
|