ࡱ > 7 R bjbjUU d4 7| 7| l J J J J $ XP XP XP P P |R $ = T J Y d ZZ ZZ ZZ \d k < 2n $ 1 Q Ro d @ \d Ro Ro J J ZZ ZZ / T Ro J Z ZZ ZZ Ro ̆ . d ZZ T 2')%/ 8 XP bu @ = , C C J J J J
Service Component ArchitectureWS-BPEL Client and Implementation Specification Version 1.1
Committee Draft 01, Revision 1098
10 July 20085 September 2008
Specification URIs (the pdf-version is authoritative):
This Version:
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-01.html" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-01.html
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-01.doc" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-01.doc
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-01.pdf" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-01.pdf
Previous Version:
N/A
Latest Version:
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1.html" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1.html
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1.doc" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1.doc
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1.pdf" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1.pdf
Technical Committee:
HYPERLINK "http://www.oasis-open.org/committees/" OASIS SCA-BPEL TC
Chair(s):
Anish Karmarkar, Oracle
Sanjay Patil, SAP
Editor(s):
Najeeb Andrabi, TIBCO Software
Martin Chapman, Oracle
Dieter Knig, IBM
Michael Rowley, BEA Systems
Ivana Trickovic, SAP
Related work:
This specification is related to:
Service Component Architecture Assembly Model Specification Version 1.1
Service Component Architecture Policy Framework Specification Version 1.1
Web Services Business Process Execution Language Version 2.0 HYPERLINK "http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html" http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
Declared XML Namespace(s):
sca http://docs.oasis-open.org/ns/opencsa/sca/200712
sca-bpel (defined here) http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801
bpel http://docs.oasis-open.org/wsbpel/2.0/process/executable
plnk http://docs.oasis-open.org/wsbpel/2.0/plnktype
sref http://docs.oasis-open.org/wsbpel/2.0/serviceref
wsdl http://schemas.xmlsoap.org/wsdl/
xsd http://www.w3.org/2001/XMLSchema
Abstract:
The Service Component Architecture (SCA) WS-BPEL Client and Implementation model specifies how WS-BPEL 2.0 can be used with SCA. The goal of the specification is to address the following scenarios.
Start from WS-BPEL process. It should be possible to use any valid WS-BPEL process definition as the implementation of a component within SCA. In particular, it should be possible to generate an SCA Component Type from any WS-BPEL process definition and use that type within an SCA assembly. Most BPEL4WS 1.1 process definitions may also be used with SCA by using the backward compatibility approach described in section REF _Ref135103434 \r \h 4.
Start from SCA Component Type. It should be possible to use WS-BPEL to implement any SCA Component Type that uses only WSDL interfaces to define services and references, possibly with some SCA specific extensions used in process definition.
Start from WS-BPEL with SCA extensions. It should be possible to create a WS-BPEL process definition that uses SCA extensions and generate an SCA Component Type and use that type within an SCA assembly. Some SCA capabilities (such as properties and multi-party references) can only be used by WS-BPEL process definitions that use SCA extensions.
Status:
This document was last revised or approved by the MACROBUTTON NoMacro [TC name | membership of OASIS] on the above date. The level of approval is also listed above. Check the Latest Version or Latest Approved Version location noted above for possible later revisions of this document.
Technical Committee members should send comments on this specification to the Technical Committees email list. Others should send comments to the Technical Committee by using the Send A Comment button on the Technical Committees web page at HYPERLINK "http://www.oasis-open.org/committees/%5bTC%20short%20name%5d%20/" http://www.oasis-open.org/committees/sca-bpel/.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page ( HYPERLINK "http://www.oasis-open.org/committees/sca-bpel/ipr.php" http://www.oasis-open.org/committees/sca-bpel/ipr.php.
The non-normative errata page for this specification is located at HYPERLINK "http://www.oasis-open.org/committees/%5bTC%20short%20name%5d%20/" http://www.oasis-open.org/committees/sca-bpel/.
Notices
Copyright OASIS 2007, 2008. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The names "OASIS", MACROBUTTON NoMacro [insert specific trademarked names and abbreviations here] are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see HYPERLINK "http://www.oasis-open.org/who/trademark.php" http://www.oasis-open.org/who/trademark.php for above guidance.
Table of Contents
TOC \o "1-3" \h \z HYPERLINK \l "_Toc193257781" 1 Introduction PAGEREF _Toc193257781 \h 5
HYPERLINK \l "_Toc193257782" 1.1 Terminology PAGEREF _Toc193257782 \h 5
HYPERLINK \l "_Toc193257783" 1.2 Normative References PAGEREF _Toc193257783 \h 5
HYPERLINK \l "_Toc193257784" 1.3 Non-Normative References PAGEREF _Toc193257784 \h 6
HYPERLINK \l "_Toc193257785" 2 Component Types defined by WS-BPEL Processes PAGEREF _Toc193257785 \h 7
HYPERLINK \l "_Toc193257786" 2.1 Services and References PAGEREF _Toc193257786 \h 7
HYPERLINK \l "_Toc193257787" 2.2 PartnerLinkTypes and SCA Interfaces PAGEREF _Toc193257787 \h 89
HYPERLINK \l "_Toc193257788" 2.3 Specifying an SCA interface with a partnerLinkType PAGEREF _Toc193257788 \h 910
HYPERLINK \l "_Toc193257789" 2.4 Handling of Local PartnerLinks PAGEREF _Toc193257789 \h 10
HYPERLINK \l "_Toc193257790" 2.5 Support for conversational interfaces PAGEREF _Toc193257790 \h 1011
HYPERLINK \l "_Toc193257791" 3 SCA Extensions to WS-BPEL PAGEREF _Toc193257791 \h 1312
HYPERLINK \l "_Toc193257792" 3.1 Properties PAGEREF _Toc193257792 \h 1312
HYPERLINK \l "_Toc193257793" 3.2 Multi-Valued References PAGEREF _Toc193257793 \h 1413
HYPERLINK \l "_Toc193257794" 4 Using BPEL4WS 1.1 with SCA PAGEREF _Toc193257794 \h 1817
HYPERLINK \l "_Toc193257795" 5 Conformance PAGEREF _Toc193257795 \h 1918
HYPERLINK \l "_Toc193257796" A. XML Schemas PAGEREF _Toc193257796 \h 2019
HYPERLINK \l "_Toc193257797" B. Acknowledgements PAGEREF _Toc193257797 \h 2422
HYPERLINK \l "_Toc193257798" C. Non-Normative Text PAGEREF _Toc193257798 \h 2624
HYPERLINK \l "_Toc193257799" D. Revision History PAGEREF _Toc193257799 \h 2725
Introduction
A WS-BPEL process definition may be used as the implementation of an SCA component.
Such a component definition has the following form:
...
...
The only aspect of this that is specific to WS-BPEL is the element. The process attribute of that element specifies the target QName of some executable WS-BPEL process.
Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in REF rfc2119 \h [RFC2119].
Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, HYPERLINK "http://www.ietf.org/rfc/rfc2119.txt" http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[SCA-Assembly] Service Component Architecture Assembly Model Specification Version 1.1,
(insert link here)
[WS-BPEL] Web Services Business Process Execution Language Version 2.0, HYPERLINK "http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html" http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
MACROBUTTON NoMacro [Reference] MACROBUTTON NoMacro [Full reference citation]
Non-Normative References
MACROBUTTON NoMacro [Reference] MACROBUTTON NoMacro [Full reference citation]
Introspected Component Types defined byof a WS-BPEL Processes
While a WS-BPEL process definition provides an implementation that can be used by a component, the process definition also determines the introspected ComponentType of any SCA component that uses that implementation. The introspected component type represents the aspects of the implementation that SCA needs to be aware of in order to support assembly and deployment of components that use that implementation. The generic form of a component type is defined in the SCA Assembly Specification REF scaassembly \h [SCA-Assembly].
...
...
...
The component type MAY be generated from a WS-BPEL process definition by introspection.
Services and References
In SCA, both services and references correspond to WS-BPELs concept of partner link. In SCA, the difference between a service and a reference is determined by which party sends the first message in a conversation. No matter of how many messages a bi-directional conversation involves or how long it takes, there is always a first message. The sender of the first message is considered to be the client and the receiver is the service provider. Messages that go from the service provider to the client are called callback messages.
WS-BPELs partner links are not differentiated based on who sends the first message. So, in order to map a WS-BPEL process to an SCA Component Type, it is necessary to determine which role sends the first message. A simple static analysis of the control flow, which does not involve determining the values of any expressions, will beis used to determine which role can send the first message.
It is also possible to override the default mapping of partnerLinks to services or references as described by explicitly marking the partnerLink with an SCA attribute that describes the service or reference (i.e. sca-bpel:service or sca-bpel:reference). These attributes are described in section REF _Ref193775122 \r \h 3.3.
Generating Services and References
The following sections describe the rules that determine the contents of the introspected component type for a WS-BPEL process.
If a partnerLink specifies has an sca-bpel:service attribute, then a service MUST be generated for the introspected component type. The name of the service MUST be the value of the attribute.
If a partnerLink specifies has an sca-bpel:reference attribute, then a reference MUST be generated for the introspected component type. The name of the reference MUST be the value of the attribute.
If neither sca-bpel:service nor sca-bpel:reference is present on the partnerLink, then if a static analysis of the process determines that it is possible that the first message for a partner link will be received in a activity, the element of a activity or the element of an event handler then the introspected component type MUST must include an SCA service that corresponds to the partner link in the component type. If the name of the partnerLink is unique within the process, then it MUST be used as the name of the service. Otherwise, the name is determined according to the rules of section REF _Ref75497065 \w \h 2.4.
If the rules above do not determine that the partner link should map to an SCA service, then the introspected component type MUST include an SCA reference that corresponds to the partner link in the component type. If the name of the partnerLink is unique within the process, then it MUST be used as the name of the reference. Otherwise, the name is determined according to the rules of section REF _Ref75497065 \w \h 2.4.
The multiplicity of the reference MUST be determined according to the following algorithm:
Multi-Reference. If the partner link is declared with an sca-bpel:multiRefFrom="aVariableName" extension, the multiplicity of the SCA reference MUST be determined by the multiplicity attribute of sca-bpel:multiReference extension used in the corresponding variable. Details of these extensions are described in section REF _Ref132690776 \r \h 3.2.
Required Reference. If (1) is not true and the partner link has initializePartnerRole="yes", then the multiplicity MUST be 1..1 (i.e. its a required reference).
Stub Reference. If neither (1) nor (2) are true and the analysis of the process determines that the first use of the partner link by any activity is in an assign activity that sets the partner role, then the multiplicity MUST be 0..1 and the attribute wiredByImpl MUST be set to true. A reference with wiredByImpl=true is referred to as a stub reference. Although the target cant be set for such a reference, SCA can still apply bindings and policies to it and may need to set the endpoint address for callbacks, if the interface is bi-directional.
Optional Reference. If (1), (2) and (3) are all false, then the multiplicity MUST be 0..1.
Handling @initializePartnerRole on Services
SCA has no concept of multiplicity on services, but partnerLinks that map to services can still be marked with an initializePartnerRole attribute. If initializePartnerRole="yes" and the partnerLink maps to a service in the component type, then any component that uses this business process as an implementation MUST configure the corresponding service to use a binding that knows the identity of the partner as soon as the partner link becomes active (e.g. the binding cannot depend on using a reply-to field as the mechanism to initialize partner role.).
Services: If a static analysis of the process determines that it is possible that the first message for a partner link will be received in a activity, the element of a activity or the element of an event handler then the partner link MUST be associated with a corresponding SCA service in the component type. If the partner link declaration has initializePartnerRole="yes", then the service MUST be configured using a binding that knows the identity of the partner as soon as the partner link becomes active (e.g. the binding cannot depend on using a reply-to field as the mechanism to initialize partner role.).
References: If a static analysis of the process does not determine that the partner link should map to an SCA service, then the partner link is mapped to an SCA reference in the component type.
The multiplicity of the reference is determined by the following algorithm:
Multi-Reference. If the partner link is declared with sca-bpel:multiRefFrom="aVariableName" extension, the multiplicity of the SCA reference will be determined by the multiplicity attribute of sca-bpel:multiReference extension used in the corresponding variable. The multiplicity declaration of the variable which is either 0..n or 1..n. Details of these extensions are described in section REF _Ref132690776 \r \h 3.2.
Required Reference. If not (1) and the partner link has initializePartnerRole="yes", then the multiplicity is 1..1 (i.e. its a required reference).
Stub Reference. If not (1) or (2) and if the analysis of the process determines that the first use of the partner link by any activity is in an assign activity that sets the partner role, then the multiplicity is 0..1 and the attribute wiredByImpl is set to true. A reference with wiredByImpl=true is referred to as a stub reference. Although the target cant be set for such a reference, SCA can still apply bindings and policies to it and may need to set the endpoint address for callbacks, if the interface is bi-directional.
Optional Reference. If not (1) or (2) or (3) then the multiplicity=0..1.
For both services and references, the name of the service or reference is the name partner link, when that name is unique (see the Handling Local Partner Links section below, for how to handle ambiguous cases).
PartnerLinkTypes and SCA Interfaces
When a partner link is determined to correspond to an SCA service, the type of the service is determined by the partner link type of the partner link. The role that the partner link specified as myRole provides the WSDL port type of the service. If the partner link type has two roles, then the partnerRole provides the WSDL port type of the callback interface.
Consider an example that uses one of the partner link types used as an example in the WS-BPEL specification. The partner link type definition is:
The invoiceProcess, which provides invoice services, would define a partner link that uses that type with a declaration that would look like:
Somewhere in the process, a start activity would use that partner link, which might look like:
Because the partner link is used in a start activity, SCA maps that partner link to a service for on the component type. In this case, the service element of the component type would be:
Conversely, when a partner link is determined to correspond to an SCA reference, the role that the partner link specified as partnerRole provides the WSDL port type of the reference. If the partner link type has two roles, then the myRole provides the WSDL port type of the callback interface.
Specifying an SCA interface with a partnerLinkType
In the approach described above, the SCA definition of service and reference uses the which restates the association between the interface and the callback interface that is already present in the WS-BPEL partnerLinkType. A partnerLinkType defines the relationship between two services by specifying roles the services play in the conversation. A partnerLinkType specifies at least one role.
For users that prefer this WS-BPEL element, it is also possible to define interfaces with an alternative partnerLinkType form of an interface type. This form does not provide any more information than is present in the element. The example above would look like the following:
The generic form of this interface type definition is as follows:
The type attribute is mandatory and references a partner link type. In case the partner link type has two roles, the optional attribute serviceRole MUST be used to specify which of the two roles is used as the interface. The other role is used as the callback. If the partnerLinkType has only one role, it cannot be a callback. Moreover, the serviceRole attribute MAY be omitted.
This form has a couple advantages over the interface.wsdl form. It is more concise. It also doesnt restate the link between the interface and the callbackInterface, so with this form, the partnerLinkType could change the portType used to define one of the roles and all of the SCA componentTypes that use that partnerLinkType would remain accurate without having to also change the interface definitions for those componentTypes. This form also may be more familiar to some users.
Handling of Local PartnerLinks
It is possible to declare partnerLinks local to a in WS-BPEL, besides declaring partnerLinks at the level. The names of partnerLink declared in different may potentially share the identical name. In case of this name sharing situation, the following scheme is used to disambiguate different occurrences of partnerLink declaration:
Suppose "originalName" is the original NCName used in multiple partnerLink declarations
When these partnerLinks are exposed to SCA assembly, these partnerLinks will given aliases from "_orginalName_1" to "_orginalName_N" regardless of how partnerLink participate in SCA assembly (i.e. services vs. references) and the number suffixes are based on the lexical order of the corresponding partnerLink occurrences in the process definition.
If any "_orginalName_i" (where 1 <= i <= N) is already taken by existing partnerLink declaration in the process definition, additional underscore characters may be added at the beginning of all aliases consistently to avoid collision.
Support for conversational interfaces
WS-BPEL can be used to implement an SCA Component with conversational services. See the SCA Assembly Specification REF scaassembly \h [SCA-Assembly] for a description of conversational interfaces. When an interface that has been marked as conversational is used for a role of a partner link, no other mechanism (such as the WS-BPEL correlation mechanism) is needed to correlate messages on that partner link, although it is still allowed. This means the SCA conversational interface is used as an implicit correlation mechanism to associate all messages exchanged (in either direction) on that partner link to a single conversation. When the EPR of the partnerRole is initialized a new conversation MUST be used for an operation of the conversational service.
Any process which, through static analysis, can be proved to use an operation on a conversational interface after an endsConversation operation has completed SHOULD be rejected. In cases where the static analysis cannot determine that such a situation could occur, then at runtime a sca:ConversationViolation fault would be generated when using a conversational partner link after the conversation has ended. See the SCA Assembly Specification REF scaassembly \h [SCA-Assembly], section 1.5.3 for a description of this fault.
If the SCA or BPEL infrastructure is able to determine that a message, that has been sent to an endpoint address of a business process, will never be matched with a corresponding inbound message activity (IMA) (i.e. receive, onMessage or onEvent), then:
If the message is sent through a request-response operation, "sca:DeadLetterMessageError" fault SHOULD be replied to the message sender
If the message is sent through a one-way operation and additional system-level protocol is used between the message sender and receiver, this error situation MAY be notified to the message sender, according to the protocol used.
If the message endpoint address of a business process leverages or participates a (transport or above transport level) protocol that has a timeout or expiration duration value specified, and if no IMA can be matched with the inbound message within the timeout / expiration duration, then:
If the message is sent through a request-response operation, "sca:DeadLetterMessageError" fault MAY be replied to the message sender
If the message is sent through a one-way operation and additional system-level protocol is used between the message sender and receiver, this error situation MAY be notified to the message sender, according to the protocol used.
For example, if a message is sent through a request-response operation and HTTP is used as a transport protocol with the timeout duration set as 60 seconds, and if SCA/BPEL infrastructure can determine if IMA can be matched within 60 seconds, a SCA+BPEL infrastructure might reply "sca:DeadLetterMessageError" fault as the response to pre-empt the transport level timeout error.
It is important to point out that the WS-BPEL correlation mechanism is not restricted to a single partner link. It can be used to associate messages exchanged on different partner links to a particular WS-BPEL process instance.
Hand-Generated Component Type Files
It is possible to augment and override some aspects of the way that an WS-BPEL process definition is represented as a component types by explicitly specifying a component type file for the process (as defined in section 4.1 of the SCA Assembly Specification).
A component type side file may contain service and reference definitions in order to override the default choice of whether a partner link is represented as a service or a reference, or to override the name for the service or reference. Each such definition MUST correspond to exactly one partner link within the corresponding process definition. The corresponding partner link is determined by either the value of the sca-bpel:implementationRef attribute or the value of the name attribute, if no sca-bpel:implementationRef attribute is present.
The @sca-bpel:implementationRef attribute MUST contain a valid XPath 1.0 expression, which when executed on a BPEL process returns exactly one element. The partnerLink thus identified will be considered to correspond to the service or reference that contained the @sca-bpel:implementationRef attribute. If a service or reference does not have an @sca-bpel:implementationRef attribute, then it will act as if it had @sca-bpel:implementationRef=//partnerLink[@name={name}], where {name} is the value of the @name attribute of that service or reference.
Component Type Files
A BPEL process (which is identified by a QName) can be matched with any ComponentType document that has an refers to the same process QName, wherever it might be within the contribution. For example, if a componentType document has an , it will be considered a match for a BPEL process identified by "foo:bar" QName (where the prefix "foo" in both documents are resolved to the same namespace.).
While the assembly specification allows to be absent, for SCA BPEL, the component type MUST include an element.
There MUST be only one CT file corresponding to a BPEL QName within a contribution
[ HYPERLINK "http://www.osoa.org/jira/browse/BPEL-17" Show ]
HYPERLINK "http://www.osoa.org/jira/secure/ViewProfile.jspa?name=mrowley" Michael Rowley [10/Jul/08 02:37 PM] Resolution accepted on 2008-07-10: An @sca-bpel:implementationRef attribute on a component type's service or reference MUST contain a valid XPath 1.0 expression, which when executed on a BPEL process returns exactly one element. The partnerLink thus identified will be considered to correspond to the service or reference that contained the @sca-bpel:implementationRef attribute. If a service or reference does not have an @sca-bpel:implementationRef attribute, then it will act as if it had @sca-bpel:implementationRef=//partnerLink[@name=$name], where $name is the value of the @name attribute of that service or reference.
SCA Extensions to WS-BPEL
It is possible to use WS-BPEL processes in conjunction with SCA, while the processes have no knowledge of SCA. A few SCA concepts are only available to WS-BPEL processors that support SCA specific extensions. The capabilities that require knowledge of SCA are provided by an SCA extension, whose namespace is " HYPERLINK "http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801" http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801". Whether this extension is mandatory or optional is specified by the mustUnderstand attribute as described in [section 14 of bpel spec]. An example, where the SCA extension is mandatory, is as follows:The capabilities that require knowledge of SCA are provided by an SCA extension, which must be declared in any process definition as follows:
...
Properties
A WS-BPEL variable declaration may include an SCA extension that says that the variable represents an SCA property for the component represented by the WS-BPEL process.
The declaration looks like the following:
When sca-bpel:property=yes is used on a variable declaration, the name of the variable is used as the name of a property of the component type represented by the WS-BPEL process. The name of the variable must be unique within the process.
If the variable has an initialization from-spec, then that becomes the default value for the variable in cases where the SCA component does not provide a value for that property.
If the from-spec is a literal value, where it has the following form:
literal value
then the literal value will be represented as the default value in the component type for the process. Any other kind of initialization from-spec will not be represented in the component type. However, even though the other kinds of initialization from-spec are not represented in the component type, they would still be computed and used as the default value for the property when the component does not provide a value for that property.
If a value is provided for the property, any initialization from-spec MUST still be evaluated, but the value of the variable will be changed to the provided property value immediately after the initialization is evaluated, and specifically, before any following variable initialization from-spec is evaluated. Thus, any side effects that result from the execution of the initialization from-spec will occur irrespective of whether the property is set.
If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" must MUST be specified on the component type property declaration, even if the default value is not literal and therefore not represented in the component type.
Multi-Valued References
Component types may declare references with a multiplicity that allows a single reference to be wired to multiple targets. An example use of this capability is a purchasing component wired to a list of accepted vendors. SCA assumes that each programming language binding will provide its own approach for making the list of targets available within that programming language.
In WS-BPEL, a variable may include an sca-bpel:multiReference extension element that declares that the variable represents a multi-valued reference. The type of the variable must be an element of sca-bpel:serviceReferenceList. However, since that type only specifies that the variable holds a list of endpoint references, the sca-bpel:multiReference element also has attributes to specify the partner link type and partner role of the target of the reference. An example of a variable that represents a list of references to vendors would look like:
Syntax of this extension:
The default value of multiplicity is "1..n".
The sca-bpel:serviceReferenceList element declaration is the following:
A typical use of a variable that holds a multi-valued reference would be to have a activity with an iteration for each element in the list. The body of the activity would declare a local partner link and assign one of the list elements to the local partner link. Such a local partner link is typically categorized as the References case 1 listed in section REF _Ref136025423 \r \h 2.1.
To assist a more effective SCA modeling, another SCA extension is introduced to associate a multi-valued reference, manifested as a "sca-bpel:serviceReferenceList" variable with a partner link. This extension is in an attribute form attached to the partner link declaration. Syntax of this extension is:
The attribute value must refer to the name of a variable manifesting an SCA multi-valued reference. The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable must be matched. Also, there must be at least one code-path that values from the multi-valued reference variable are copied to the partnerRole of the partner link.
If any above constraints are violated, it will be considered an error during static analysis.
When this sca-bpel:multiRefFrom extension is applied to pair up a multi-valued reference variable and a partner link which is categorized as the References case 1 (as described in section REF _Ref136146274 \r \h 2.1), the partner link and variable are manifested as a single multi-valued reference entity in SCA assembly model using the name of the variable. If the interface involved is bi-directional, this implies the wiring of the bi-directional interface as a single reference in SCA.
For example:
...
...
1
count($vendors/sref:service-ref)
...
...
...
$vendors/sref:service-ref[$idx]
...
...
A multi-valued reference named "vendors" is declared in the example above. The partner link named "vendorLink", which is categorized as the References case 1, is not manifested directly into the SCA Assembly Model. The extra sca-bpel:multiRefFrom="vendors" extension associates the "vendorLink" partner link with multi-valued reference variable "vendors". Consequently, the partner link and variable are manifested as a single multi-valued reference named "vendors" in SCA. This makes the SCA Assembly modeling easier to follow.
PartnerLink mapping to Services and References
It is possible to override the default mapping of partnerLinks to services or references as described in section 2.1 by explicitly marking the partnerLink with an SCA attribute that describes the service or reference.
To explicitly map a partnerLink to a service, the sca-bpel:service attribute should be used, as follows:
The name used MUST NOT conflict with any other service name generated in the component type for this process.
To explicitly map a partnerLink to a reference, the sca-bpel:reference attribute should be used, as follows:
The name used MUST NOT conflict with any other reference name generated in the component type for this process.
When either of these attributes are used, the componentType will include a service or reference with the given name and no other service or reference will be generated for the partnerLink. The type of that service or reference is unaffected (it will be as specified in section 2.2).
A process MUST NOT include both attributes on a single partnerLink.
Required Intents for PartnerLinks
An SCA extension attribute can also be used to declare required policy intents on a partner link. This can be used by WS-BPEL process designers to require specific abstract policies to be associated with the partnerlink, without limiting the bindings that may be used for the partner link.
The form of the attribute is the following:
The contents of this attribute should be a space separated list of SCA intent QNames, exactly as specified in the SCA Policy Framework Specification for the contents of the @sca:requires attribute.
If the attribute is specified, the service or reference that is generated in the component type MUST also include an @sca:requires attribute with the same contents.
Using BPEL4WS 1.1 with SCA (Non-Normative)
A BPEL4WS 1.1 process definition may be used as the implementation of an SCA component. The syntax introduced in section REF _Ref179613301 \h \* MERGEFORMAT Introduction is used to define a component having a BPEL4WS 1.1 process as the implementation. In this case, the process attribute specifies the target QName of a BPEL4WS 1.1 executable process.
A BPEL4WS 1.1 process definition may be used to generate an SCA Component Type.
Conformance
(tbd.)
XML Schemas
XML Schema for SCA-BPEL Extensions of SCA Elements
The definitions contributed by the SCA-BPEL specifications to the common SCA namespace are also provided in a separate XML Schema artifact.
XML Schema for SCA-BPEL Extensions of WS-BPEL 2.0
The definitions of SCA-BPEL extensions to WS-BPEL 2.0 are also provided in a separate XML Schema artifact.
Acknowledgements
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Members of the SCA-BPEL Technical Committee: MACROBUTTON
Najeeb Andrabi, TIBCO Software Inc.
Graham Barber, IBM
William Barnhill, Booz Allen Hamilton
Charlton Barreto, Adobe Systems
Hanane Becha, Nortel
Michael Beisiegel, IBM
Jeffrey Bik, Active Endpoints, Inc.
David Burke, TIBCO Software Inc.
Fred Carter, AmberPoint
Martin Chapman, Oracle Corporation
Eric Clairambault, IBM
James Bryce Clark, OASIS
Mark Combellack, Avaya, Inc.
Kevin Conner, Red Hat
Robin Cover, OASIS
Jean-Sebastien Delfino, IBM
Jacques Durand, Fujitsu Limited
Mike Edwards, IBM
Raymond Feng, IBM
Mark Ford, Active Endpoints, Inc.
Genadi Genov, SAP AG
Alejandro Guizar, Red Hat
Uday Joshi, Oracle Corporation
Khanderao Kand, Oracle Corporation
Anish Karmarkar, Oracle Corporation
Jason Kinner, Oracle Corporation
Dieter Koenig, IBM
Rich Levinson, Oracle Corporation
Mark Little, Red Hat
Ole Madsen, OIOXML eBusiness Standardization Group
Ashok Malhotra, Oracle Corporation
Keith McFarlane, Avaya, Inc.
Mary McRae, OASIS
Jeff Mischkinsky, Oracle Corporation
Simon Moser, IBM
Sanjay Patil, SAP AG
Michael Pellegrini, Active Endpoints, Inc.
Luciano Resende, IBM
Michael Rowley, BEA Systems, Inc.
Clifford Thompson, Individual
Ivana Trickovic, SAP AG
Danny van der Rijn, TIBCO Software Inc.
Mark Walker, Avaya, Inc.
Prasad Yendluri, Software AG, Inc.
Alex Yiu, Oracle Corporation
OSOA Contributors: MACROBUTTON
Martin Chapman, Oracle
Sabin Ielceanu, TIBCO Software Inc.
Dieter Koenig, IBM
Michael Rowley, BEA Systems, Inc.
Ivana Trickovic, SAP AG
Alex Yiu, Oracle
Non-Normative Text
Background about Dead Letter Messages in BPEL
When an inbound message comes into the SCA and BPEL infrastructure, such a message is normally consumed by a matching inbound message activity (IMA)(e.g. a activity). However, due to process model error or runtime message data error, there is no matching IMA at all or a matching IMA is not enabled within the expected time limit of the (system/business level) protocol between the message sender and receiver. This kind of messages, which do not have a matching IMA, are termed as "dead message messages" Examples of process model error are:
matching IMAs are skipped by faults
matching IMAs blocked by other activities within a sequence or an impossible-to-fulfill control link transition condition.
IMAs cannot receive message due to incorrect usage of message correlation mechanism, including BPEL correlation set and SCA conversational interface
Examples of runtime message data error are similar to above, as the above error are not inside the process definition itself but caused by incorrect data values. There might not be a universal way to determine a message is truly a "dead letter message" without any additional protocol between message senders and receivers. Consider the following example, an message is dispatched to a BPEL process instance by SCA conversational mechanism. At the moment when the message is matched with the BPEL process instance, there might be no activity enabled for the matching partnerLink and operation at all, or there is a activity enabled for the matching partnerLink and operation but with a mismatched correlation set. Some users might think this is certainly a dead letter message situation. However, a matching IMA may be enabled minutes, hours, or days later, as the matching IMA might be blocked in the process model. On the other hand, there might be some cases that the BPEL infrastructure can determine there will never be a matching IMA enable in future. And, some advanced features in BPEL infrastructure (e.g. process instance repair or process definition repair) might make the detection of "dead letter message" cases more difficult. However, with some additional system-level protocol coordination between the message sender and receiver, it might make detection easier.
Revision History
MACROBUTTON NoMacro [optional; should not be included in OASIS Standards]
RevisionDateEditorChanges Made22007-10-10Dieter KnigIssue resolutions BPEL-4, BPEL-7
New section 5. Conformance
List of XML namespaces
Table of Contents formatting
References formatting
Syntax and Examples formatting32007-10-10Dieter KnigReduced component/composite syntax in sections 1 and 242007-12-05Dieter KnigIssue resolutions BPEL-5, BPEL-6, BPEL-9, BPEL-13
Document title according to OASIS rules52008-01-11Michael RowleyIssue resolution for BPEL-1162008-01-17Dieter KnigApproved Committee Draft72008-03-17Dieter KnigRevised Approved Committee Draft
Applied resolution to BPEL-19: Added XML Schema definitions as Appendix A82008-03-27Michael RowleyApplied resolution to BPEL-1492008-04-10Michael RowleyAdded @sca-bpel:requires attibribute, also as part of resolving BPEL-14.CD01-rev52008-06-19Michael RowleyReworked 2.1 to use 2119 language.
Removed Alex Yiu from editor list.CD01-rev72008-07-07Najeeb AndrabiReverted 2.1 to CD01-rev2
Issue resolutions BPEL-3CD01-rev82008-07-10Dieter KnigNamespace prefix "xsd" used consistently in all XML Schema snippets
Fixed definition of sca-bpel:requires attribute in section 3.4 and XML Schema
Added import for sca-core.xsd to the XML schema defining WS-BPEL extension attributesCD01-rev92008-07-10Michael RowleyMarked Chapter 4 Non-Normative (issue 1)
Reapplied changes from rev5.
Added section 2.6 (issue 17) and added
sca-bpel:implementatRef to XML SchemaCD01-rev102008-09-5Martin ChapmanBacked out changes for section 2.1, which was a partial proposal for Issue 18.
Added new section 2.7 (issue 2).
Change Section 3 Intro. (issue 20).
sca-bpel-1.1-spec-cd-01 revision 810 10 July 20085 September 2008
Copyright OASIS 2007, 2008. All Rights Reserved. Page PAGE 8 of NUMPAGES 29282825
MACROBUTTON NoMacro [document identifier] MACROBUTTON NoMacro [specification date]
Copyright OASIS Open 2004.All Rights Reserved. Page PAGE 1 of NUMPAGES 128
] z | } ~ : ; < % & ' ( } ~ : ¯}pc j B*Uph j B*Uph j B*Uph 0J
j 0J U5B*\ph; o $ 5B*CJ$ \aJ$ cH dh+ɦph; o $ 5B*CJ$ \aJ$ cH dhSdžph; o 1 H hSdž5B*CJ$ \aJ$ cH dh+ɦph; o $H h+ɦ5B*CJ$ \aJ$ ph; o 5B*CJ$ \aJ$ ph; o j U % ] ' { % & 1 P g ^ ) : Q : ; < y z { | Q R S % & 1 P y
6 7 9 U X Ǯ ǔ 5\mHsH 5\ mHsH 5\mHsH j UmHsH mHsH 5B*\mHph; o sHj@
U j U5B*\ph; o j= B*Uph j: B*Uph 0J
j 0J Uj5
B*Uph 3g y '
u
o C= Eƀ Sdž C= Eƀ Sdž ^ u
9 : U w 4 C= Eƀ Sdž C= Eƀ Sdž C= Eƀ Sdž R y 6 C= Eƀ Sdž C= Eƀ Sdž C= Eƀ Sdž Q R W
Q R k l m n o q b / 0 / 0 1 _ ` b _ ` ! o p q j} B*Uph j B*Uph j B*Uph 0J
j 0J U6j U j U55B*\ph; o mHsH 5\mHsH mHsH 5\mHsH mHsH 5\ mHsH8
q b b y w w u u u u w w s s s > 9 C= Eƀ Sdž
C= Eƀ Sdž
D L & _$ y&