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


Francisco Curbera wrote:
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.

  
    After reflecting on the above quotation, I think I may better understand your statements. Perhaps the problem lies in a misunderstanding of the proposal at hand.

    I don't think the URI proposal implies that all endpoint references are solely URIs. Rather, URIs are the only aspect of endpoint references that are exposed at the BPEL level. URIs can be associated by implementations with more elaborate endpoint reference types, as needed by the implementation's bindings.

    It is certainly not the intent of the proposal to ban things like WS-MD and WS-A, replacing them with bare URIs; rather, it is the intent to allow use of one or more such endpoint reference types within an implementation, and to ensure that process definitions are not directly tied to a particular endpoint reference type. This decoupling promotes the qualities that you mention, as well as making the BPEL spec more resilient.

-Ron


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