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


+1

We see a lot of benefit in being able to support an addressing 
mechanism. These mechanism provides more flexibility and take care of 
the details, and for many cases are preferrable over the use of 
correlation sets. That's a capability we would not like to lose by 
limiting BPEL to URIs. If we see convergence around a future 
availability of an open specification, we would like to adopt it, even 
if initially we will have to base the implementation around an input to 
such a working group.

Assaf


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
>.
>
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

S/MIME Cryptographic Signature



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