[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Re: Issue 34 - Proposal for vote
Ron,
I was pointing out that things seem to be moving, after the recent w3c
submission. Waiting for standards is clearly not a requirements, as our
position wrt WSDL 2.0 shows. on the other hand, if a submitted document
were to become the seed of a working group we would have a clear reference
point to build upon. Since a delay of this decision comes at essentially no
price, it seems unnecessary to rush to close it.
Paco
Ron Ten-Hove
<Ronald.Ten-Hove@ To: Francisco Curbera/Watson/IBM@IBMUS
Sun.COM> cc: wsbpel@lists.oasis-open.org, ygoland@bea.com
Subject: Re: [wsbpel] Re: Issue 34 - Proposal for vote
05/19/2004 03:23
PM
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]