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


Ron,

 

The idea for option 2 is to declare the reference scheme, which could be at the process level.  In addition it can be declared by any activity (which would then change the default for its children) similar to the suppress join failure and query language attributes.  This way one can declare a reference scheme at the process level or a scope or an assign, etc.  In this scenario, a BPEL4WS 1.1 process would not change unless it used an assign to/from a partner link.  In that case the process would simply declare a <process reference-scheme=” http://schemas.xmlsoap.org/ws/2004/08/addressing” attribute.  Also this seems more consistent with bpel’s query language support, which also declares an external language dependency.  Although in the reference-scheme case we won’t have a default.

 

You are right about EPR sources.  Although in addition I could for see your option number 1 being extended.  For example the process itself could be dealing with a “purchase order” and the vendor’s EPR is looked up in a database via an invoke activity, so it may not be exactly hard-coded.

 

Also the scenario where one wants to look at the EPR data in the process is easily accomplished.  The reference-scheme declaration would allow one to copy data from a partner link to a compatible message part or element thereby allowing the policy use-case you described.  In the service-ref case (the current one we are debating) you never know as an implementer what you have under the service-ref element.

 

- Chris

 


From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Tuesday, September 07, 2004 8:53 PM
To: Chris Keller
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 152 - New Proposal to Vote

 

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

 


 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]