Hi All,
My feeling is that a reference-scheme
attribute is a good idea, although maybe not in a service-ref. For the majority of cases it doesn’t
affect the actual BPEL at all. The
reference scheme is typically between the engine and its receiving/invoking
layer(s). It never even shows up in
your BPEL file unless you hard code a literal to map to a partner link, which
in my opinion is unlikely to be used much.
If a partner link is truly associated with a dynamic address then the
reference will be returned as the result of a service invocation (which may
call a database for instance). Also
the idea that a scheme must have a uniform root element to encapsulate it seems
unnecessarily restrictive. I can
easily imagine a scheme where the content of the reference is a directory
location for looking up the service provider. In that example my scheme would be reference-scheme=”http://.../ldap-reference”.
In my opinion the content model should not be forced to have one element
with a unique namespace.
I actually have 2 alternative proposals,
but prefer option number 2.
1 – Make the reference-scheme a required
attribute. I use the same argument as
was used for including an import type in the bpel import, so one did not have
to open up the import in order to know how to handle it (or not for that
matter). Suppose I execute a
service to lookup a service reference the bpel engine has to know how to
deserialize it and when an activity using it is called then there may be more
than one receiving/invoking layer which it may route it to. My preference in an implementation would
be to look at the root of the element to know how to unpack it rather than peek
in. We also need a runtime fault like bpws:invalidReferenceScheme when an
engine figures out that it can’t handle a reference which has been moved
into a partner.
2 - If a bpel process uses assigns to
partner links then we should require a reference-scheme attribute at the root
of the bpel process (or in an activity level) like query-language. Unless this attribute is set assigns to
Partner Links will not be allowed. This
eliminates the need for a reference-scheme attribute in the service-ref itself. This way an engine won’t try to
run a bpel process, which utilizes a scheme it doesn’t handle. Then we don’t need a bpws:invalidReferenceScheme, which
is thrown after the poor user has already done a lot of work and then realizes
it isn’t any good. In this
case we don’t need to describe a service-ref at all since the bpel
process and static analysis can figure out if it is an improper assignment.
Hope this helps,
Chris
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Tuesday, September 07, 2004
2:42 PM
To: Francisco Curbera
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 152
- New Proposal to Vote
Paco,
The reference-scheme attribute is a general-purpose
mechanism to address a class of EPRs. It doesn't fit my definition of creating
a dependency on WS-MD, stealth or otherwise. WS-MD happens to serve as a good
example of this class of EPRs. By refusing to accomodate such EPRs, we
needlessly restrict the applicability of WS-BPEL.
-Ron
Francisco Curbera wrote:
Hi Ron,
I think I understand the argument: WS-MD has an issue with how it reflects
(or doesn't reflect) spec version information in the epr. There are many
different ways to solve that problem; what is not fair, I think, is to ask
BPEL to patch over these problems and burden every BPEL engine with this
sirt of of ad-hoc patches. This in my view would be nothing but a (stealth)
dependency on an external spec, and one of a particularly unfortunate kind
since it results in nothing but clutter and inefficiency for every
compliant implementation.
Paco
Ron Ten-Hove
<Ronald.Ten-Hove@ To: Francisco Curbera/Watson/IBM@IBMUS
Sun.COM> cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 152 - New Proposal to Vote
09/02/2004 04:49
PM
Paco,
I'm not sure if you've seen the main argument for having the
reference-scheme attribute (optional or not). Suppose we had a service
reference like the following:
<ServiceRefType>
<wsdl:port name="MyNotificationPort" ...
</ServiceRefType>
The addressing schema to apply is less than clear. If my BPEL run-time
is clever, it might guess that WS-Message Delivery is implied, but it
will be at a loss to figure out which version of WS-MD to use. Also, it
is reasonable to assume that other specifications, trodding the same
ground as WS-MD, will take a similar approach, using wsdl 1.1 ports and
wsdl 2.0 endpoints.
It is for these cases, where the QName of the element enclosed by
the <ServiceRefType> is not sufficient to resolve the endpoint reference
scheme in use, that the reference-scheme attribute is needed.
If we adopt the proposed resolution to the issue 152 (below), how
are we to address the above problem?
Best regards,
-Ron
Francisco Curbera wrote:
Following up on yesterday's discussion I am proposing an alternative
resolution to issue 152. The aim, as it was discussed, is to eliminate
unnecessary and redundant syntax:
The "reference-scheme" attribute will be removed from the
"bpws:service-ref" element wrapper. The schema definition for the wrapper
will thus be changed to the following:
<xs:element name="service-ref" type= tns:ServiceRefType />
<xs:complexType name="ServiceRefType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
Paco
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.