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] Re: Issue 34 - Proposal for vote


John,

If WS-MD becomes a standards (modulo whatever renaming) and is  
available and meets the requirements for WS-BPEL then do you think it  
makes sense to use it?

If not then why not?

Cheers

Steve T

On 19 May 2004, at 21:31, Ron Ten-Hove wrote:

> John,
>
>    WS-MD is what used to be called a W3C Note, but what is now called  
> a W3C Member Submission. The W3C is now free to form a Working Group,  
> if it so wishes, to turn it into a W3C recommendation.
>
> Cheers,
> -Ron
>
> John Evdemon wrote:
>
>> Is WS-MD a standard?
>> John
>>
>> ________________________________
>>
>> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
>> Sent: Wed 5/19/2004 12:23 PM
>> To: Francisco Curbera
>> Cc: wsbpel@lists.oasis-open.org; ygoland@bea.com
>> Subject: Re: [wsbpel] Re: Issue 34 - Proposal for vote
>>
>>
>> Paco,
>>
>>    I do not understand what delaying a couple of months will  
>> accomplish.
>>
>>    Supposing that in the next couple of months WS-Addressing is  
>> submitted to a standards-setting organisation, it will still take  
>> many months before it emerges as a standard [1]. It will be of no use  
>> to this TC, which cannot take dependencies on works-in-progress,  
>> unless we are willing to delay our work accordingly.
>>
>>    As you point out, flexibility and compatibility are important. The  
>> current direct incorporation of WSA for endpoint references certainly  
>> restricts flexibility, and provides only compatibility with a  
>> proprietary, closed, non-standard specification. It certainly cannot  
>> accomodate anything like WS-MD.
>>
>>    Yaron's URI proposal minimizes the coupling between the endpoint  
>> reference type employed by the binding and the BPE language.  
>> Design-wise, this is a Good Thing. It also addresses a very common  
>> use case, where endpoint references are embedded in messages.
>>
>>    To promote flexibility and compatibility, implementations should  
>> be free to support various endpoint reference types. At least four  
>> different endpoint references types are on the table:
>>
>>
>> *	WS-Addressing *	WS-Message Delivery *	Binding protocol-supplied  
>> endpoint reference info
>> 	
>> *	Message-supplied URI
>>    How should we support these? And how does delaying two months  
>> change these requirements? I sincerely doubt there will be an  
>> "industry convergence" in the that period.
>>
>> Best regards,
>> -Ron
>>
>> [1] This will likely take years, unless WS-A is decoupled from  
>> WS-Policy and all the other specifications involved, many of which  
>> are non-standard.
>>
>> Francisco Curbera wrote:
>>
>>
>> 	
>> 	My vote is with Dieter's position, which he stated t the last call:  
>> there
>> 	is no compelling reason that I can think of to close issue 34 now as
>> 	opposed to, say, a couple months from now; but if we rush this issue  
>> now we
>> 	are potentially (likely) creating a new conflict between BPEL and  
>> whatever
>> 	referencing mechanism that eventually emerges as the industry  
>> consensus.
>> 	Recent submissions to W3C have made many of us hopeful that some
>> 	clarification of this space may be on the horizon.
>> 	
>> 	Regarding the proposal below: we need to insist on flexibility and
>> 	compatibility with established service referencing mechanisms used  
>> by the
>> 	industry. This TC seems to have come to the realization that,  
>> lacking an
>> 	industry-wide consensus, real implementations may have to address
>> 	service/process instances in different ways (of which URI hackery is  
>> one
>> 	possibility); this means that defining a reference to be a URI is  
>> not good
>> 	enough. Flexibility, extensibility and openness are critical  
>> requirements
>> 	missing from the URI-only proposal.
>> 	
>> 	Of course, we will not need to define any ad-hoc BPEL solution if we  
>> give
>> 	the industry a chance to converge on an interoperable mechanism.  
>> Since we
>> 	have time to revisit this issue later, this seems to me the wisest  
>> thing to
>> 	do by far.
>> 	
>> 	Paco
>> 	
>> 	
>> 	
>> 	                                                                      
>>                                                                    	   
>>                     Ron Ten-Hove                                       
>>                                                                 	      
>>                  <Ronald.Ten-Hove@        To:       ygoland@bea.com    
>>                                                              	         
>>               Sun.COM>                 cc:        
>> wsbpel@lists.oasis-open.org                                            
>>          	                                               Subject:   
>> [wsbpel] Re: Issue 34 - Proposal for vote                              
>>          	                      05/18/2004 04:33                       
>>                                                                        
>>       	                      PM                                        
>>                                                                        
>>    	                                                                   
>>                                                                        
>> 	
>> 	
>> 	
>> 	
>> 	Yaron,
>> 	
>> 	    A +1 from me, and my thanks.
>> 	
>> 	    To be clear: these are separate issues, but the solutions could
>> 	overlap in that they both depend on the type used to represent  
>> endpoint
>> 	references:
>> 	
>> 	    34: Change endpoint references to be type xsd:uri.
>> 	    124:  Remove <assign>ment of endpoint references to/from partner
>> 	links. Add functions to accomplish the same in a direct fashion.
>> 	
>> 	    As you say, overloading <assign> to manipulate the partner links  
>> is
>> 	poor design. It is confusing, quirky, and inconsistent with the other
>> 	uses of <assign>. Activities like <setPartnerEndpoint> and
>> 	<getPartnerEndpoint> are much clearer.
>> 	
>> 	-Ron
>> 	
>> 	Yaron Y. Goland wrote:
>> 	
>> 	
>> 		Ron has asked me to open a new issue on the URI function and I have
>> 		done  so.
>> 		
>> 		But this still leaves open his proposal. My official counter  
>> proposal
>> 		to Ron's proposal is that we remove the ability to use assign with
>> 		partnerLinks.
>> 		
>> 		As previously described it is bad design to rely on side effects. As
>> 		such I believe it to be bad design to rely on a side effective of
>> 		assign as a way of changing partnerLinks bindings. Regardless of how
>> 		the endpoint reference debate turns out we shouldn't be using side
>> 		effects to manipulate endpoint references.
>> 		
>> 		    Yaron
>> 		
>> 		Yaron Goland wrote:
>> 		
>> 		
>> 			I think that depending on side effects usually causes more trouble  
>> than
>> 			its worth. If we define the syntax for a partnerLink document and  
>> then
>> 			as a consequence of changing that document we change the behavior  
>> of the
>> 			partnerLink we will be relying on very messy side effects. We will  
>> be
>> 			conflating two different actions - editing a XML document and  
>> changing
>> 			partnerLink behavior.
>> 			
>> 			I would propose that instead we introduce two dedicated functions,  
>> one
>> 			to set the URI and one to retrieve the URI for a partnerRole on a
>> 			partnerLink. That way we aren't rely on side effects.
>> 			
>> 			        Yaron
>> 			
>> 			
>> 			Ron Ten-Hove wrote:
>> 			
>> 			 >   Yaron,
>> 			 >
>> 			 >     You bring up an excellent point. The ability to copy a URI  
>> from a
>> 			 > variable into a partner link is important. It is certainly the  
>> most
>> 			 > direct, easily understood and portable form of endpoint  
>> reference
>> 			available.
>> 			 >
>> 			 >     It should be possible to assign variables of type xsd:uri to
>> 			partner
>> 			 > links (and /vice versa/), and require that the implementation  
>> resolve
>> 			 > the URI correctly (or complain the prescribed manner). I regard
>> 			this as
>> 			 > an enhancement (and a valuable one) to BPEL, not necessarily an
>> 			 > alternative solution to issue 34.
>> 			 >
>> 			 >     However, the idea of combining the two ideas has merit.  
>> Rather
>> 			than
>> 			 > using xsd:any for the endpoint reference type, xsd:uri could
>> 			serve. We
>> 			 > could make sure that <assign> explicitly allows assignment of  
>> xsd:uri
>> 			 > variables to/from partner links. Implementations must be able to
>> 			resolve
>> 			 > the URIs involved to binding-specific endpoint references, as
>> 			needed by
>> 			 > the binding.
>> 			 >
>> 			 >     This would have the added benefit of restoring static type
>> 			checking
>> 			 > to partner link <assign>ments, which is otherwise lost if  
>> xsd:any
>> 			is used.
>> 			 >
>> 			 >     What does the rest of the TC think?
>> 			 >
>> 			 > Best regards,
>> 			 > -Ron
>> 			 >
>> 			 > Yaron Y. Goland wrote:
>> 			 >
>> 			 >> One of the more common activities, I suspect, in BPEL  
>> processes will
>> 			 >> be receiving the URI of a service in a message and then  
>> sending a
>> 			 >> message to that service. If such a basic example cannot be  
>> supported
>> 			 >> by BPEL in an interoperable way then BPEL is broken.
>> 			 >>
>> 			 >> In order to support this example there needs to be a way to  
>> set the
>> 			 >> URI of a partnerRole. The original specification envisioned  
>> that a
>> 			 >> role would be described as an endpoint reference using the
>> 			definition
>> 			 >> in WSA and then one could manipulate that endpoint reference by
>> 			 >> changing information such as the URI.
>> 			 >>
>> 			 >> I understand the group's desire to stay away from the WSA arena
>> 			but I
>> 			 >> don't think gives us permission to ignore this critical use  
>> case.
>> 			 >>
>> 			 >> However, I think it's worth taking a second to look at endpoint
>> 			 >> references. They contain five types of data - address,  
>> reference
>> 			 >> properties, portType, service-port and policy.
>> 			 >>
>> 			 >> Reference properties can be implemented today using a WSDL  
>> message
>> 			 >> part and correlation sets. So you can get there from here.
>> 			 >>
>> 			 >> portType is already defined by the partnerLink the role  
>> belongs to.
>> 			 >>
>> 			 >> service-port is about dynamic discovery of the kind of  
>> information
>> 			 >> that had to already be defined by the partnerLink. In a sense  
>> the
>> 			 >> functionality represented by service-port is an improvement on
>> 			what is
>> 			 >> possibly today but I think BPEL only needs to equal, not  
>> necessarily
>> 			 >> exceed, what can be done over the wire in Web Services today.
>> 			 >>
>> 			 >> policy - If service-port represents the technology of tomorrow  
>> then
>> 			 >> policy represents the technology of Buck Rodgers. It's going to
>> 			take a
>> 			 >> while before this one gets fully baked and we shouldn't let
>> 			ourselves
>> 			 >> get held up in the meantime. I think we can ignore this one  
>> for the
>> 			 >> same reasons as service-port.
>> 			 >>
>> 			 >> So near as I can tell the only thing in endpoint references  
>> that we
>> 			 >> really need is the address, e.g. the URI, e.g. the thing you  
>> need
>> 			for
>> 			 >> the example I gave above.
>> 			 >>
>> 			 >> So why don't we come up with some command that lets a BPEL
>> 			program set
>> 			 >> the URI on a partnerRole and call it a day? When setting the  
>> URI
>> 			 >> either the deployment system (e.g. the thing that is out of  
>> scope)
>> 			 >> will have a configuration that will work with the URI or it  
>> will
>> 			 >> reject it. In other words the BPEL process says "I want to  
>> talk to
>> 			 >> 'ftp://foo.com/bar'" and either the system through some  
>> undefined
>> 			 >> means has a configuration it likes for ftp://foo.com/bar  
>> including
>> 			 >> bindings, policies, etc. and so says 'sure, no problem' or it
>> 			doesn't
>> 			 >> in which case a fault is thrown.
>> 			 >>
>> 			 >>         Yaron
>> 			 >>
>> 			 >> Ron Ten-Hove wrote:
>> 			 >>
>> 			 >>>       [resend; the  proposal is unchanged . This is just to  
>> move
>> 			the
>> 			 >>> issue state forward according to protocol]
>> 			 >>>
>> 			 >>> *Summary*
>> 			 >>>
>> 			 >>> WS-BPEL Issue 34 concerns the inappropriate dependency of the
>> 			WS-BPEL
>> 			 >>> specification on a proprietary specification, namely  
>> WS-Addressing
>> 			 >>> (henceforth WSA). WS-BPEL uses WSA to provide a vocabulary for
>> 			 >>> describing endpoint references.
>> 			 >>>
>> 			 >>> It is proposed that the use of WSA-defined variables be  
>> replaced
>> 			with
>> 			 >>> opaque variables. Variables of this opaque type will provide
>> 			 >>> specified data to provide endpoint reference information, but  
>> the
>> 			 >>> specifics are left to implementations.
>> 			 >>>
>> 			 >>> *Problem*
>> 			 >>>
>> 			 >>> The use of WSA is inappropriate; it is a proprietary  
>> specification,
>> 			 >>> closed (therefore unstable), difficult if not impossible to  
>> license
>> 			 >>> (given its dependencies on other proprietary specifications).
>> 			WSA is
>> 			 >>> also only defined for SOAP, making it binding specific, which  
>> is
>> 			 >>> inappropriate given that the TC has consistently avoided  
>> including
>> 			 >>> binding-specific requirements (e.g., the decision to not
>> 			incorporate
>> 			 >>> WS-I Basic Profile 1.0).
>> 			 >>>
>> 			 >>> WSA is used within WS-BPEL to provide an XML vocabulary for
>> 			providing
>> 			 >>> endpoint references. This is required mainly to provide a  
>> mechanism
>> 			 >>> for dynamic partner link resolution. There are no open  
>> standards
>> 			 >>> available that provide such a vocabulary (although the W3C has
>> 			 >>> published the WS-Message Delivery specification as a submitted
>> 			note.)
>> 			 >>>
>> 			 >>> *Proposal*
>> 			 >>>
>> 			 >>> The incorporation of WSA by WS-BPEL should be eliminated.  
>> Endpoint
>> 			 >>> references should be made opaque (i.e., anyType from XML  
>> Schema
>> 			1.0):
>> 			 >>> the XML type of abstract message parts that provide endpoint  
>> should
>> 			 >>> be opaque to WS-BPEL, and undefined by WS-BPEL other than some
>> 			 >>> general requirements (listed below).
>> 			 >>>
>> 			 >>> Implementations of WS-BPEL will need to provide support for  
>> one (or
>> 			 >>> more) endpoint description vocabularies. Provision for
>> 			 >>> interoperability of separate implementations is important,  
>> but is
>> 			 >>> outside the scope of the WS-BPEL TC in this issue.
>> 			 >>>
>> 			 >>> It is anticipated that standards setting organizations will
>> 			 >>> eventually provide standard endpoint description  
>> vocabularies, and
>> 			 >>> that future versions of WS-BPEL will incorporate them while
>> 			 >>> preserving backwards compatibility with this initial version  
>> of the
>> 			 >>> WS-BPEL.
>> 			 >>>
>> 			 >>> *Endpoint Reference Requirements*
>> 			 >>>
>> 			 >>> The opaque endpoint reference type MUST provide the following:
>> 			 >>>
>> 			 >>>     *
>> 			 >>>
>> 			 >>>       A representation of addressing information needed by
>> 			transport
>> 			 >>>       protocols that can be used by implementation-specific
>> 			bindings to
>> 			 >>>       resolve to a communications endpoint.
>> 			 >>>
>> 			 >>>     *
>> 			 >>>
>> 			 >>>       Support for two distinct address types, mappable to the
>> 			"myRole"
>> 			 >>>       and "partnerRole" values of the partnerLink attribute  
>> of the
>> 			 >>>       <assign> <to> element.
>> 			 >>>
>> 			 >
>> 			
>> 			To unsubscribe from this mailing list (and be removed from the  
>> roster
>> 			of the OASIS TC), go to
>> 			
>> 			
>> 	http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/ 
>> leave_workgroup.php
>> 	.
>> 	
>> 			
>> 	To unsubscribe from this mailing list (and be removed from the  
>> roster of
>> 	the OASIS TC), go to
>> 	http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/ 
>> leave_workgroup.php
>> 	.
>> 	
>> 	
>>
>>
>
>
> To unsubscribe from this mailing list (and be removed from the roster  
> of the OASIS TC), go to  
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/ 
> leave_workgroup.php.



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