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

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

Ron,

I was evidently trying to focus on function, not individual specs (as Diane
and Monica asked us to do), so I said WS-Policy "is an example".  Referring
to concrete examples usually improves the clarity of the argument. I
certainly am not as fond of this kind of "spec wars" discussions as you
seem to be.

The point I am making is that by separating concerns we're better off. I
don't think you are arguing with that point, just with my example. Good to
see you also have your favorite examples.

Paco





                                                                                                                                  
                      Ron Ten-Hove                                                                                                
                      <Ronald.Ten-Hove@        To:       Francisco Curbera/Watson/IBM@IBMUS                                       
                      Sun.COM>                 cc:       wsbpel@lists.oasis-open.org                                              
                                               Subject:  Re: [wsbpel] Issue - 66 - Zero or multiple matches of  correlation set   
                      09/24/2003 06:31                                                                                            
                      PM                                                                                                          
                                                                                                                                  




Francisco Curbera wrote (in part):
      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.
   The choice of  WS-Policy is an unfortunate one, however. It is a
proprietary spec, and the licensing terms ban implementations (you are only
permitted to read and copy the spec.) Thus we must omit WS-Policy from
consideration.

   Rather than latching onto a likely looking spec (encumbered or not) to
completely separate the concerns, can't we try to find a neutral way to
express such QoS requirements in a business process model? Our needs are
modest, and certainly don't need the full weight of the WS-Policy framework
or CPP/A. Why become coupled to a particular specification if we can avoid
it?

   A good example of this "neutural" approach is BPSS. It expresses the
messaging QoS needs of a collaborative business process in high-level
business terms. It has a few simple attributes for its Document and
Envelope types that align well with ebMS and CPP/A QoS concepts, but
doesn't require that the other ebXML specs be used. By using high-level,
business-oriented requirements to declare what QoS properties are needed,
BPSS avoids that trap of needing to specify how such needs are to be met.

-Ron