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

[Francisco Curbera <curbera@us.ibm.com>]

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