RE: [wsbpel-abstract] Potential requirements and use case

["Satish Thatte" <satisht@microsoft.com>]

I see.  I have very serious reservations about the use of <opaque> activities.  I think they would be misleading to use in most scenarios.  I explained my thoughts in the original posting.
 
Having said that, I thought the idea of <opaque> was that anything without <opaque> was as ready for execution as anyone could tell.  What additional checks would one do?

________________________________

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Fri 7/23/2004 9:00 AM
To: Satish Thatte
Cc: Monica J. Martin; wsbpel-abstract@lists.oasis-open.org
Subject: Re: [wsbpel-abstract] Potential requirements and use case


Satish Thatte wrote:


	Monica,
	
	Regarding your suggestion to maintain an explicit abstract/executable
	distinction, probably using the current process-level attribute, I agree
	with you.
	
	I don't quite understand what you mean by "statically verifiable set of
	conditions to specify when a process model is ready to execute".  I
	would hope that abstractProcess="no" and the schema for executable
	processes plus simple static checks that we already have in the text
	which we should gather in a list (issue 84) should be sufficient.  Did
	you have something else in mind?
	  

This comes from a different line of thought that we were kicking around internally. The idea was that abstract processes are simply executable processes that are missing some details needed for execution, or that contain placeholders for concrete activities (opaque activities). A set of statically verifiable conditions could be specified to allow this condition to be checked mechanically. The conditions would include things like "no opaque activity nodes" and "all expressions filled in." This is what Monica alluded to.

The thought was that this model would allow abstract processes to be more flexible -- the amount of detail in the process could run along a continuum, from minimal to virtually complete, rather than the current model that defines one point along that continuum.

We thought this approach had some merit. It avoids the "two schema" headache, and is flexible enough to accomodate a wide range of use cases. It does add complexity to any tools that would exploit the static definition of abstract process that we have today.

Cheers,
-Ron


	Satish
	
	-----Original Message-----
	From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
	Sent: Thursday, July 22, 2004 3:35 PM
	To: Satish Thatte
	Cc: wsbpel-abstract@lists.oasis-open.org; Ron Ten-Hove
	Subject: Re: [wsbpel-abstract] Potential requirements and use case
	
	Satish: We'd provide some additional suggestions:
	
	    * If an abstract process contains opaque elements or activities,
	      they must be elaborated.
	          o Make explicit the semantics surrounding opaque if accepted.
	[1]
	    * Ensure we can specify a process is abstract or executable
	      irrespective of whether opaque is used. [2]
	    * Suggest we define a statically verifiable set of conditions to
	      specify when a process model is ready to execute.
	    * Ban extensions from affecting 'ready to execute.' [3] This is
	      inline with current specification that bans extensions affecting
	      BPEL semantics.
	
	[1] In order to provide a guide for developers and allow other 
	computational or conformance capabilities to be used on top of the 
	abstract process.
	[2] The condition may occur that opaque activities may have not been 
	explicitly added yet, but you wish to ensure that someone doesn't try to
	
	execute an incomplete process.  We currently have 
	abstractProcess="yes|no"? under Process. Is this sufficient?
	
	Thanks.
	
	  

		Thatte: I think we are agreeing on a few things
		
		1. abstract BPEL allows partial specification of executable processes.
		
		2. we need a precise definition of conformance between a partial
		    

	process and any executable process that claims to be its completion
	  

		3. We do not want to preclude any use case for abstract processes,
		    

	including 
	  

		a. A notation for specifying the externally visible behavior of a web
		    

	service or a collection of web services where the notation may be used
	with various degrees of austerity as appropriate for the needs of the
	specifier,
	  

		b. A notation for exchange of process requirements across autonomous
		    

	entities where the abstract and the executable process are NOT "owned"
	by the same entity, and
	  

		c. A notation for partial specification in a modeling context where the
		    

	abstract and the executable process ARE "owned" by the same entity.
	  

		4.  <opaque> activities and expressions are primarily intended as a
		    

	proposal for allowing the designer of an abstract process to express
	his/her intentions regarding mandatory points of extension.  The purpose
	of <opaque> is NOT to specify all allowable points of extension,
	prohibiting all other potential points of extension in the completion of
	an abstract process.  Secondarily, <opaque> activities and expressions
	serve as a convenience for technical specification and validation using
	a single schema.
	  

		I would argue that the technical convenience argument for <opaque> is a
		    

	weak one because the syntactically mandated completion points can be
	easily found by tools and forcing an abstract process designer to
	explicitly design them in helps tools and BPEL specification writers at
	the expense of the users of abstract BPEL, i.e., those who read and
	write instances of abstract BPEL.  This is especially the case for use
	case (a) above where brevity and readability are likely to be very
	important.
	  

		I believe the primary intention of the <opaque> proposal as a mechanism
		    

	for expressing the intention for mandatory extension applies primarily
	to use case (c) and as such I would argue that it belongs more in the
	realm of a tools oriented extension rather than an essential aspect of
	abstract BPEL.  
	  

		Satish