RE: [wsbpel] Issue - 152 - New Proposal to Vote

Hi Alex,

 

Yes what you said makes sense, however I
think you misinterpreted my second proposal.  Our emails must have crossed in the
ether, as I had just finished responding to Ron’s email when yours
arrived.  In my response to Ron’s
email I stated my proposal for a new attribute in BPEL was not a default, but a
declaration and can be used at an activity level as well as the process.  IMO the invention of a service-ref wrapper
is a mistake and will lead to other issues like it has to 152.  Instead I would prefer we handle this along
the query language support lines by creating a declaration of the reference-scheme
in cases where it is necessary (i.e. when an external EPR is used in an assign
to a partner link), in all other cases the engine created it and should be able
to deal with it.  This declaration will
make it easier for users as well as for process engines to figure out if they can
run the process before it becomes a runtime issue/fault.

 

- Chris

 

 

From: Alex Yiu [mailto:] 

Sent: Tuesday, September 07, 2004
9:55 PM

To: Ron Ten-Hove

Cc: Chris Keller;
; Alex Yiu

Subject: Re: [wsbpel] Issue - 152
- New Proposal to Vote

 

Hi, 

Just want to mention a few points:

 
There is a fault
     called "bpws:UnsupportedReference" in the first proposal similar
     to  "bpws:invalidReferenceScheme" in Chris'
     suggestion.  [http://lists.oasis-open.org/archives/wsbpel/200408/msg00067.html]

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

(1) The process itself ("hard-coded" using
assign operations).

(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 endpoint
reference.

(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 http://lists.oasis-open.org/archives/wsbpel/200409/msg00026.html)
     

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

Thanks!

Regards,

Alex Yiu

Ron Ten-Hove wrote:

Chris,

    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 end-point references:

 
The process itself
     ("hard-coded" using assign operations).

 
A received message.
     The contents of a message can include an endpoint reference.

 
Binding-specific
     data (eg, SOAP message headers). 

 
Deployment-time
     settings of "static" Partner Link addresses (both inbound and
     outbound).

    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
practice!

Cheers,

-Ron

Chris Keller wrote:

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