Dear
Colleagues,
Picking up on the mention of CPP/A - possibly a new issue or thread? -
while I half agree with what Ron says, I feel there maybe several reasons to
consider CPP/A or a variant thereof as a mechanism for sharing configuration
information between 'partners'. The CPP/A can be digitally signed to give
integrity and authenticity. It can be used to set 'company wide' policies
with regard to business process, communication mechanisms and security.
Currently it is the case that the business process description is the more long
term, or static description, where as different CPP/As can be used to vary
certain characteristics at run time. I guess you could also turn this
around and use the CPP/A to set the long term policies, but permit certain
variation within the business process description (within boundaries prescribed
by the CPP/A).
In
conclusion I feel it would be worth while considering the use of CPP/A, or a
variant thereof, with BPEL instances. Is this an issue for the main group
or the new implementation sub-group?
Best
Regards,
Tony
|
|
Tony
Fletcher Technical
Advisor
| |
|
Phone:
|
+44 (0) 870 7390076 | |
|
Mobile:
|
+44
(0) 7801 948219 | |
|
Fax:
|
+44 (0) 870 7390077 | |
|
Web: |
||
|
Cohesions™ | ||
|
Business
transaction management software for application
coordination | ||
|
Work: tony.fletcher@choreology.com | ||
|
Home: amfletcher@iee.org | ||
-----Original Message-----Satish Thatte wrote:
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: 24 September 2003 19:50
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set
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:
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.
- 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).
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