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


I have no problem with using additional specs, so long as they are relevant and (hopefully) make BPEL easier to use.  
 
I knew WS-MD had been submitted to the W3C but was unaware of any additional activity.
 
Thanks for the clarification Ron!
 
John
 
 

________________________________

From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
Sent: Wed 5/19/2004 1:46 PM
To: Ron Ten-Hove
Cc: Francisco Curbera; John Evdemon; ygoland@bea.com; wsbpel@lists.oasis-open.org
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]