Just want to mention a few points:
- There is a fault called "bpws:UnsupportedReference" in the first
proposal similar to "bpws:invalidReferenceScheme" in Chris'
- Since the reference-scheme attribute is intended to disambiguate
the child content element, I would not consider Chris's suggested
process-level attribute as a "defaulting" mechanism. I would rather
consider that is a cross-checking mechanism. I also think that
process-level attribute fits better with the BPEL deployment
descriptor, which likely contains a bunch of endpoint references, if
such an attribute exists.
- I agree with Ron's analysis on 4 sources of endpoint references
(1) The process itself ("hard-coded" using assign
(2) Deployment-time settings of "static" Partner Link addresses (both
inbound and outbound).
(3) A received message. The contents of a message can include an
(4) Binding-specific data (eg, SOAP message headers).
- For case (1), since we have the service-ref wrapper element, BPEL
compiler can verify the content of epr at the earliest possibility.
- For case (2), BPEL deployment tool can verify the content of epr
at the earliest possibility.
- For case (3), a better epr content checking can be done by
leveraging a restricted type in the message design. (See
- For case (4), if I understand correctly, I consider that is a
Web-Service container issue, not a BPEL language issue. The checking
and interpretation of SOAP message headers will occur no matter how we
design our epr pattern in BPEL language.
Chris ... I hope what I said make sense to you. :-)
Ron Ten-Hove wrote:
Very interesting points. If I understand proposal #2 correctly, we
would be assuming that only one type of reference scheme could be used
across all Partner Links in the process. Is this understanding correct,
or is this a way of "defaulting" the reference-scheme attribute?
Your point about the actual use of reference-scheme from within a
process is well taken. There are, as far as I can tell, four sources of
As you say, EPRs should hardly affect the process logic itself. It
would be a very odd process indeed that needed to query the reference
scheme as part of the business process. That being said, one could
imagine some scenarios in which certain aspects of the EPR affect the
logic of a business process, in an attempt to build some sort of basic
policy mechanism (eg, no sending sensitive messages to endpoints via
insecure transports). I should hope that this would be a very uncommon
- The process itself ("hard-coded" using assign operations).
- A received message. The contents of a message can include an
- Binding-specific data (eg, SOAP message headers).
- Deployment-time settings of "static" Partner Link addresses
inbound and outbound).
Chris Keller wrote:
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
layer(s). It never even shows up in
your BPEL file unless you hard code a literal to map to a partner link,
in my opinion is unlikely to be used much. If a
partner link is truly associated with a dynamic address
reference will be returned as the result of a service invocation (which
call a database for instance). Also
the idea that a scheme must have a uniform root element to encapsulate
unnecessarily restrictive. I can
easily imagine a scheme where the content of the reference is a
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
with a unique namespace.
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
to open up the import in order to know how to handle it (or not for
matter). Suppose I execute a
service to lookup a service reference the bpel engine has to know how
deserialize it and when an activity using it is called then there may
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
in. We also need a
runtime fault like bpws:invalidReferenceScheme
engine figures out that it can’t handle a reference which has been
into a partner.
2 - If a
bpel process uses assigns to
partner links then we should require a reference-scheme attribute at
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
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