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] Issue - 152 - New Proposal to Vote

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,



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



    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.


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.
                      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                                                                                                  
    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:
       <wsdl:port name="MyNotificationPort" ...
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,
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:any namespace="##other" processContents="lax" minOccurs="1"
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
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]