OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] policy annotations and BPEL (was RE: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set)


Ron,
 
I was asking very simple questions.  Regardless of the level, would the analyst not need to express these requirements both for BPEL processes and for WSDL services under various circumstances?  Would s/he want to use the same notation for expressing them in all cases or not?  If yes, do we feel we can dictate that notation?
 
I do worry about fuzzy statements of requirements especially when they may have legal implications.  How does one prove that these high level requirements are actually satisfied?
 
Satish

________________________________

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Fri 10/3/2003 9:51 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] policy annotations and BPEL (was RE: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set)


Satish,

    The main utility of using WSDL and/or BPEL extension mechanisms is in addressing issues that are not in the direct domain of the particular language. In a business process language, business security concerns are part of the business process domain. Pushing such concerns into unstandardized extensions will have the undesirable effect of creating several potentially incompatible solutions, as vendors and users work to address such a shortcoming in the language.

    Such a feature can always be added in a future version, but this should be considered carefully. Assuming good uptake of our first version of WS-BPEL, we will need to worry about compatibility issues. If business-level security becomes effectively buried in low-level deployment information, or in various vendor-specific extensions to BPEL, we would make adoption of future version of WS-BPEL with business-level security support  more difficult.

    As for the QoS issue itself: I believe we are confusing apples for oranges, perhaps due to different uses of terminology, different preconceptions, assumptions, or expectations.

    When I speak of business-focused QoS annotations, I do not mean anything equivalent to policy annotations or references to WS-Policy/WS-SecurityPolicy. Rather, I mean the security requirements that an analyst would place on parts of a process to express business security needs. For example, the analyst might deem that any quotations sent out need to be confidential, while any billing or payment information need to be both confidential and tamper-proof.  How that is done is not of concern to the analyst.

    These are high-level requirements, expressed by the analyst, who isn't equipped to deal with the arcane details that policy annotations and WS-SecurityPolicy demands. The point being that there is a need for the analyst to express QoS attributes for the process, and that those attributes are different from what we term "policy annotations." Further, these attributes are unique to the business process, but will help drive selection of  policy annotations in a deployment. Policy annotations are lower-level details, but security is not simply an implementation detail!

-Ron

Satish Thatte wrote:


	Ron,
	
	 
	
	Clearly, the disagreement is not about the need for QoS and other policy annotation. There are two separate issues we are talking about.
	
	 
	
	A.	Does such annotation belong within BPEL?
	B.	Whether it does or not, how should it be expressed?
	
	 
	
	The following are my personal opinions.  I won't qualify them as such at every step.
	
	 
	
	I believe such annotation is not within the scope of the TC's work.  BPEL is not attempting to provide a complete business process modeling solution.  What it is attempting to standardize is the description of long-running patterns of service-level messaging interactions both for multi-party business protocol definition and multi-service composition.  If we attempt to go beyond this, we will either do an incomplete and half-baked job of policy annotation or we will not finish for a very long time.
	
	 
	
	Regardless of this, we have two options for expressing annotations.  Use BPEL's extensibility mechanisms and express them as BPEL extensions.  Or follow a separate policy annotation model that is used not only in the context of BPEL but in most other contexts.  Let us take the example of security annotations for messaging interactions.  We may sometimes need to annotate a specific receive action in a BPEL process, sometimes an input action within a WSDL operation, or sometimes an entire WSDL portType.  The annotation may be essentially the same: e.g., message(s) must be signed.  If we have BPEL specific extensions for this and WSDL has WSDL specific extensions for the same sort of annotation, we now have two ways of saying the same thing, which will inevitably start diverging at least in subtle ways simply because there are many ways to express this sort of constraint and reasonable groups of people will come up with different styles of annotation which are not isomorphic.  
	
	
	 
	
	This is why I favor the idea of a separate policy annotation model that is used not only in the context of BPEL but in most other contexts.  We then have a chance to provide uniform annotation at all the levels we need to, without having to anticipate every combination of possibilities.  Yes, WS-Policy is such a model but the point I am making is that we need something of that sort.  I am not asking us to take a dependency on WS-Policy specifically.
	
	 
	
	Satish
	
	
	________________________________
	
	From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
	Sent: Fri 9/26/2003 1:03 PM
	To: Satish Thatte
	Cc: wsbpel@lists.oasis-open.org
	Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set
	
	
	
	Satish Thatte wrote:
	
	  

		Ron,
		
		Would it not be unfortunate for the real people building real systems
		with web services standards if they had to learn 5 different ways to
		express QoS and other policy assertions regarding service interfaces,
		just because 5 standards committees found it convenient to avoid a
		dependency on anything outside their control? 
		
		    

	    Do you have a proposal for such a dependency?
	
	    It would be even more unfortunate if those real people had to build
	real systems using a standard that was completely silent on important
	issues like QoS from a process perspective. This just makes the
	situation worse -- vendor-specific extensions, pseudo-standards, etc. It
	is an invitation to Balkanize the BPEL implementation landscape. This is
	not what OASIS wants from us, wouldn't you agree?
	
	    A few simple, business-level assertions about QoS that are supported
	by the standard will serve to reduce (but, as you observe, not
	eliminate) this source of incompatibility. (The effort to fully address
	such an issue would rapidly run into diminishing returns; I am not
	advocating that we walk such a path! I think the TC has a (rightly) well
	developed allergy to scope enlargement.)
	
	    Further, the approach for loosely coupling specifications has been
	used successfully by OASIS in the past. Is is more a question of
	alignment than dependency avoidance.
	
	  

		The other alternative of
		using "metamodels" that need mappings and bindings to actual
		realizations is a level of complexity that I also think it would be best
		to avoid.
		
		    

	    In general, I agree. However, I would add that (meta-) models based
	on business processing modelling domain concepts should not be so
	excluded, precisely because this is the domain the TC is working in.
	
	  

		I believe we should focus only on our core concerns which have to do
		with process models.  We all recognize that these models don't live in a
		vacuum and will have to work well with WSDL, WS-Security, and whatever
		other specifications in the areas of reliability, transactions and
		coordination, policy, etc., that people end up using.  I would much
		rather defer the solution than create a burden of legacy that people
		would have to deal with for a long time to come.
		
		    

	    We have conflicting requirements here. One is to make BPEL an
	expressive process modelling language; the other to make it a simple
	execution language. Business level QoS concerns are doubtless important
	for the former BPEL requirement, but undesirable from the latter. We
	have had, in the past, rather vigorous support for promoting BPEL as a
	modelling language; do you disagree with the notion of BPEL as an
	expressive BP modelling language?
	
	    Our legacy will also include the things we refuse to address, which
	may result in diminished utility, interoperability or portability: all
	things that will reduce the value of this specification. Sins of
	omission have as many consequences as those of commission :-)
	
	-Ron
	  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]