ࡱ > [ @ bjbj | ΐ ΐ 1 i + + A/ A/ A/ $ e/ e/ e/ P / , 4 e/ 8 G d G G G Q |* {
$ - A/ AQ @ Q + + G G + Z G A/ G n F W. G lh]! e/ r N 7 ` n @ k @ A/ @ l Z ߏ @ 4 S * :
Service Component ArchitectureWS-BPEL Client and Implementation Specification Version 1.1
Committee Draft 02 and Public Review Draft 01Revision 2
5 March11 June 2009
Specification URIs (the pdf-version is authoritative):
This Version:
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-02.html" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-02.html
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-02.doc" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-02.doc
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-02.pdf" http://docs.oasis-open.org/opencsa/sca-bpel/sca-bpel-1.1-spec-cd-02.pdf
Previous 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
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, Active Endpoints
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/200903
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 4 .
S t a r t f r o m S C A C o m p o n e n t I m p l e m e n t a n S C A C o n s t r a i n i n g T y p e . I t s h o u l d b e p o s s i b l e t o u s e W S - B P E L t o i m p l e m e n t a n y S C A C o m p o n e n t C o n s t r a i n i n g T y p e t h a t u s e s o n l y W S D L i n t e r f a c e s t o d e f i n e s e r v i c e s a n d r e f e r e n c e s , p o s s i b l y w i t h s o m e S C A s p e c i f i c e x t e n sions 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 OASIS Service Component Architecture / BPEL (SCA-BPEL) TC 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 2005, 2009. 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 "_Toc224098780" 1 Introduction PAGEREF _Toc224098780 \h 5
HYPERLINK \l "_Toc224098781" 1.1 Terminology PAGEREF _Toc224098781 \h 5
HYPERLINK \l "_Toc224098782" 1.2 Normative References PAGEREF _Toc224098782 \h 5
HYPERLINK \l "_Toc224098783" 1.3 Non-Normative References PAGEREF _Toc224098783 \h 6
HYPERLINK \l "_Toc224098784" 1.4 Naming Conventions PAGEREF _Toc224098784 \h 6
HYPERLINK \l "_Toc224098785" 2 Introspected Component Type of a WS-BPEL Process PAGEREF _Toc224098785 \h 7
HYPERLINK \l "_Toc224098787" 2.1 Services and References PAGEREF _Toc224098787 \h 7
HYPERLINK \l "_Toc224098788" 2.1.1 Generating Services and References PAGEREF _Toc224098788 \h 8
HYPERLINK \l "_Toc224098789" 2.1.2 Handling @initializePartnerRole on Services PAGEREF _Toc224098789 \h 9
HYPERLINK \l "_Toc224098790" 2.2 Partner Link Types and SCA Interfaces PAGEREF _Toc224098790 \h 9
HYPERLINK \l "_Toc224098791" 2.3 Handling of Local Partner Links PAGEREF _Toc224098791 \h 10
HYPERLINK \l "_Toc224098812" 3 SCA Extensions to WS-BPEL PAGEREF _Toc224098812 \h 11
HYPERLINK \l "_Toc224098813" 3.1 Properties PAGEREF _Toc224098813 \h 11
HYPERLINK \l "_Toc224098814" 3.2 Multi-Valued References PAGEREF _Toc224098814 \h 12
HYPERLINK \l "_Toc224098815" 3.3 Partner Link Mapping to Services and References PAGEREF _Toc224098815 \h 14
HYPERLINK \l "_Toc224098816" 3.4 Required Intents for Partner Links PAGEREF _Toc224098816 \h 15
HYPERLINK \l "_Toc224098817" 4 Using BPEL4WS 1.1 with SCA (Non-Normative) PAGEREF _Toc224098817 \h 16
HYPERLINK \l "_Toc224098818" 5 Conformance PAGEREF _Toc224098818 \h 17
HYPERLINK \l "_Toc224098819" 5.1 SCA WS-BPEL Document. PAGEREF _Toc224098819 \h 17
HYPERLINK \l "_Toc224098820" 5.2 SCA Runtimes PAGEREF _Toc224098820 \h 17
HYPERLINK \l "_Toc224098821" 5.2.1 SCA WS-BPEL Runtime PAGEREF _Toc224098821 \h 17
HYPERLINK \l "_Toc224098822" 5.2.2 SCA Extended WS-BPEL Runtime PAGEREF _Toc224098822 \h 17
HYPERLINK \l "_Toc224098824" A. XML Schemas PAGEREF _Toc224098824 \h 1819
HYPERLINK \l "_Toc224098933" B. Conformance Items PAGEREF _Toc224098933 \h 2122
HYPERLINK \l "_Toc224098934" C. Acknowledgements PAGEREF _Toc224098934 \h 2526
HYPERLINK \l "_Toc224098942" D. Revision History PAGEREF _Toc224098942 \h 2729
Introduction
This specification describes how a WS-BPEL process definition can be used as the implementation of an SCA component.
For an SCA component to use a WS-BPEL process as an implementation, it uses an element::
...
...
The only aspect of this that is specific to WS-BPEL is the element. [HYPERLINK \l "BPEL1002_T"SBPEL1001] The process attribute of the element MUST be the QName of an 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,
HYPERLINK "http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf" http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf
[SCA-PolicyFramework]
Service Component Architecture Policy Framework Specification Version 1.1, HYPERLINK "http://docs.oasis-open.org/opencsa/sca-policy/sca-policy-1.1-spec-cd-02.pdf" http://docs.oasis-open.org/opencsa/sca-policy/sca-policy-1.1-spec-cd-02.pdf
[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]
Naming Conventions
This specification follows some naming conventions for artifacts defined by the specification,
as follows:
For the names of elements and the names of attributes within XSD files, the names follow the CamelCase convention, with all names starting with a lower case letter.e.g.
For the names of types within XSD files, the names follow the CamelCase convention with all names starting with an upper case letter. e.g.
Introspected Component Type of a WS-BPEL Process
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 SCA Assembly Specification defines an asyncInvocation policy intent for long-running operations. BPEL processes that implement long-running request-response operations are encouraged to use interfaces marked with this intent.
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, is used to determine which role can send the first message.
It is also possible to override the default mapping of partner links to servi c e s o r r e f e r e n c e s a s d e s c r i b e d b y e x p l i c i t l y m a r k i n g t h e p a r t n e r l i n k w i t h a n S C A a t t r i b u t e t h a t d e s c r i b e s t h e s e r v i c e o r r e f e r e n c e ( i . e . s c a - b p e l : s e r v i c e o r s c a - b p e l : r e f e r e n c e ) . T h e s e a t t r i b u t e s a r e d e s c r i b e d i n s e c t i o n R E F _ R e f 1 9 3 7 7 5 1 2 2 \ r \ h 3 . 3 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.
[HYPERLINK \l "BPEL2001_T"SBPEL2001] If a partner link specifies a sca-bpel:service attribute, then a service MUST be generated for the introspected component type. [HYPERLINK \l "BPEL2002_T"SBPEL2002] The name of the service MUST be the value of the sca-bpel:service attribute.
[HYPERLINK \l "BPEL2003_T"SBPEL2003] If a partner link specifies a sca-bpel:reference attribute, then a reference MUST be generated for the introspected component type. [HYPERLINK \l "BPEL2004_T"SBPEL2004] The name of the reference MUST be the value of the sca-bpel:reference attribute.
[HYPERLINK \l "BPEL2005_T"SBPEL2005] If neither sca-bpel:service nor sca-bpel:reference nor the sca-bpel:multiRefFrom is present on the partner link, 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 include an SCA service that corresponds to the partner link in the component type. [HYPERLINK \l "BPEL2006_T"SBPEL2006] If the name of the partner link 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 . 3 2 . 3 .
[ H Y P E R L I N K \ l " B P E L 2 0 0 7 _ T " S B P E L 2 0 0 7 ] I f t h e r u l e s [ H Y P E R L I N K \ l " B P E L 2 0 0 1 " S B P E L 2 0 0 1 ] - [ H Y P E R L I N K \ l " B P E L 2 0 0 6 " S B P E L 2 0 0 6 ] d o n o t d e t e r m i n e t h a t t h e p a r t n e r l i n k m a p s t o a n S C A s e r v i c e o r a n S C A r e f e r e n c e , a n d t h e r e i s n o s c a - b p e l : m u ltiRefFrom attribute present, then the introspected component type MUST include an SCA reference that corresponds to the partner link in the component type. [HYPERLINK \l "BPEL2008_T"SBPEL2008] If the name of the partner link 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 . 3 2 . 3 .
[ H Y P E R L I N K \ l " B P E L 2 0 0 9 _ T " S B P E L 2 0 0 9 ] T h e m u l t i p l i c i t y o f t h e r e f e r e n c e M U S T b e i s d e t e r m i n e d a c c o r d i n g t o t h e a l g o r i t h m d e f i n e d b y r u l e s [ H Y P E R L I N K \ l " B P E L 2 0 1 0 " S B P E L 2 0 1 0 ] - [ H Y P E R L I N K \ l " B P E L 2 0 1 3 " S B P E L 2 0 1 3 ] .
M u l t i - R e f e r e n c e . [ H Y P E RLINK \l "BPEL2010_T"SBPEL2010] If the variable partner link is declared with an sca-bpel:multiRefFrom="aVariableName"multiReference 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 3 . 2 .
R e q u i r e d R e f e r e n c e . [ H Y P E R L I N K \ l " B P E L 2 0 1 1 _ T " S B P E L 2 0 1 1 ] I f [ H Y P E R L I N K \ l " B P E L 2 0 1 0 " S B P E L 2 0 1 0 ] d o e s n o t a p p l y a n d t h e p a r t n e r l i n k h a s i n i t i a l i z e P a r t n e r R o l e = " y e s " , t h e n t h e m u l t i p l i c i t y M U S T b e " 1 . . 1 " ( i . e . i t i s a r e q u i r e d r e f e r e n c e ) .
Stub Reference. [HYPERLINK \l "BPEL2012_T"SBPEL2012] If neither [HYPERLINK \l "BPEL2010"SBPEL2010] nor [HYPERLINK \l "BPEL2011"SBPEL2011] apply and the analysis of the process determines that the first use of the partner link by any activity is in an 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 potentially need to set the endpoint address for callbacks, if the interface is bi-directional.
Optional Reference. [HYPERLINK \l "BPEL2013_T"SBPEL2013] If neither [HYPERLINK \l "BPEL2010"SBPEL2010] nor [HYPERLINK \l "BPEL2011"SBPEL2011] nor [HYPERLINK \l "BPEL2012"SBPEL2012] apply, then the multiplicity MUST be "0..1".
The introspected component type also includes references for variables that have the are annotated with an sca-bpel:multiReference attributechild element. [HYPERLINK \l "BPEL3006_T"SBPEL3006] The introspected component type MUST include a reference with a multiplicity of either "0..n" or "1..n" that corresponds to a variable with the sca-bpel:multiReference element. [HYPERLINK \l "BPEL3007_T"SBPEL3007] The type of the reference MUST be determined by the partner link type and the partner role attributes of the sca-bpel:multiReference extension element. [SBPELXXXX] If the name attribute is present on the sca-bpel:multiReference element, the name of the reference MUST be the value of that name attribute. If the name attribute is not present on the sca-bpel:multiReference element then the name of the reference is determined by the name of the variable (see section 2.3 for the algorithm that ensures that every introspected reference and service name are unique).
Handling @initializePartnerRole on Services
SCA has no concept of multiplicity on services, but partner links that map to services can still be marked with an initializePartnerRole attribute. [HYPERLINK \l "BPEL2014_T"SBPEL2014] If a partner link is marked with initializePartnerRole="yes" then any component that uses this business process as an implementation MUST configure the corresponding service or reference using binding, promotion and wiring configuration that guarantees that the partner link's partner role will be initialized as soon as the partner link becomes active. If the partner link is mapped to a service, the callback binding would be the relevant binding for this requirement. If initializePartnerRole="yes" is specified for a partner link and the partner link 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 the partner role).
Partner Link Types 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. [HYPERLINK \l "BPEL2015_T"SBPEL2015] The WSDL port type in the declaration for the service in the introspected component type MUST be the same as the port type of the myRole of the partner link. [HYPERLINK \l "BPEL2016_T"SBPEL2016] If the partner link type has two roles, then the declaration MUST also have a @callbackInterface attribute whose value points to the same WSDL port type as the partnerRole of the partner link.
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 in the introspected component type, then interface for the reference is also determined by the partner link type, but with the roles reversed. [HYPERLINK \l "BPEL2017_T"SBPEL2017] The WSDL port type in the declaration for the reference MUST be the same as the port type of the partnerRole of the partner link. [HYPERLINK \l "BPEL2018_T"SBPEL2018] If the partner link type has two roles, then the declaration MUST also have a @callbackInterface attribute whose value points to the same WSDL port type as the myRole of the partner link.
Handling of Local Partner Links
It is possible to declare partner links local to a in WS-BPEL, besides declaring partner links at the level. The names of partner link declared in different could potentially share the identical name. [HYPERLINK \l "BPEL2019_T"SBPEL2019] When multiple partner links share the same name, the scheme defined by [HYPERLINK \l "BPEL2020"SBPEL2020]-[HYPERLINK \l "BPEL2022"SBPEL2022] MUST is be used to disambiguate different occurrences of partner link declaration.
Let "originalName" be the original NCName used in multiple partner link declarations.
[HYPERLINK \l "BPEL2020_T"SBPEL2020] The introspected component type MUST include services or references corresponding to these partner links with names: "_orginaloriginalName_1" to "_orginaloriginalName_N". Whether the partner link corresponds to a service or reference does not affect the name used. [HYPERLINK \l "BPEL2021_T"SBPEL2021] The number suffixes for the partner links MUST be based on the lexical order of the corresponding partner link occurrences in the process definition.
[HYPERLINK \l "BPEL2022_T"SBPEL2022] If any "_orginaloriginalName_i" (where 1 <= i <= N) is already the name of a partner link declaration in the process definition, additional underscore characters MAY be added at the beginning of all aliases consistently to avoid collision.
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 the WS-BPEL 2.0 specification REF scaassembly \h [SCA-Assembly].
An example, where the SCA extension is mandatory, is as follows:
...
Properties
A WS-BPEL variable declaration can 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. [HYPERLINK \l "BPEL3001_T"SBPEL3001] The name of a variable used as a property of the component 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.
[HYPERLINK \l "BPEL3002_T"SBPEL3002] If a value is provided for a 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.
[HYPERLINK \l "BPEL3003_T"SBPEL3003] If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" 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 can 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.
[HYPERLINK \l "BPEL3004_T"SBPEL3004] In a WS-BPEL process definition, a variable MAY include an sca-bpel:multiReference extension element that declares that the variable represents a multi-valued reference. [HYPERLINK \l "BPEL3005_T"SBPEL3005] When a variable declaration contains the sca-bpel:multiReference extension, 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. [HYPERLINK \l "BPEL3006_T"SBPEL3006] The introspected component type MUST include a reference with a multiplicity of either "0..n" or "1..n" that corresponds to a variable with the sca-bpel:multiReference element. [HYPERLINK \l "BPEL3007_T"SBPEL3007] The type of the reference MUST be determined by the partner link type and the partner role attributes of the sca-bpel:multiReference extension element. The introspected component type will include a reference with multiplicity of either 0..n or 1..n for this variable, as specified in section 2.1.1. [HYPERLINK \l "BPEL3008_T"SBPEL3008] The sca-bpel:multiRefFrom attribute MUST NOT be specified for a partner link with a myRole attribute referencing a role which is the only role of a partner link type. [HYPERLINK \l "BPEL3009_T"SBPEL3009] The sca-bpel:multiRefFrom attribute MUST NOT be specified for a partner link that has the sca-bpel:service attribute.
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 name attribute value, if present, is used as the name of the SCA reference in the introspected componentType.
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 loc a l p a r t n e r l i n k a n d a s s i g n o n e o f t h e l i s t e l e m e n t s t o t h e l o c a l p a r t n e r l i n k . S u c h a l o c a l p a r t n e r l i n k i s t y p i c a l l y c a t e g o r i z e d a s t h e R e f e r e n c e s c a s e 1 l i s t e d i n s e c t i o n R E F _ R e f 1 3 6 0 2 5 4 2 3 \ r \ h 2 . 1 2 . 1 .
T o a s s i s t a m o r e e f f e c t i v e S C A m o d e l i n g , 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:
[HYPERLINK \l "BPEL3010_T"SBPEL3010] The value of the sca-bpel:multiRefFrom attribute MUST refer to the name of a variable manifesting an SCA multi-valued reference. [HYPERLINK \l "BPEL3011_T"SBPEL3011] For the child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the , both of the following MUST be true:
(1) The partnerLinkType attribute of the is the same as the partnerLinkType attribute of the . (2) The name of the partnerRole for the is the same as the partnerRole attribute of the .The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable MUST be matched.
[HYPERLINK \l "BPEL3012_T"SBPEL3012] There MUST be at least one code-path where the 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 ca t e g o r i z e d a s t h e R e f e r e n c e s c a s e 1 ( a s d e s c r i b e d i n s e c t i o n R E F _ R e f 1 3 6 1 4 6 2 7 4 \ r \ h 2 . 1 2 . 1 ) , t h e p a r t n e r l i n k a n d v a r i a b l e a r e m a n i f e s t e d a s a s i n g l e m u l t i - v a l u e d r e f e r e n c e e n t i t y i n S C A a s s e m b l y m o d e l u s i n g t h e n a m e o f t h e v a r i a b l e . I f t h e i n t e r face 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.
Partner Link Mapping to Services and References
[HYPERLINK \l "BPEL3013_T"SBPEL3013] A WS-BPEL process definition MAY can override the default mapping of partner links to services or references as described in section 2.1 by explicitly marking the partner link with an SCA attribute that describes the service or reference.
[HYPERLINK \l "BPEL3014_T"SBPEL3014] To explicitly map a partner link to a service, the sca-bpel:service attribute MAY can be specified for the partner link. Example:
[HYPERLINK \l "BPEL3015_T"SBPEL3015] The name of the service specified in the sca-bpel:service attribute MUST NOT conflict with any other service name generated in the component type for this process. [HYPERLINK \l "BPEL3016_T"SBPEL3016] The sca-bpel:service attribute MUST NOT be specified for a partner link with a partnerRole attribute referencing a role which is the only role of a partner link type.
[HYPERLINK \l "BPEL3017_T"SBPEL3017] To explicitly map a partner link to a reference, the sca-bpel:reference attribute MAY can be specified for the partner link. Example:
[HYPERLINK \l "BPEL3018_T"SBPEL3018] The name of the reference specified in the sca-bpel:referenceservice attribute MUST NOT conflict with any other reference name generated in the component type for this process. [HYPERLINK \l "BPEL3019_T"SBPEL3019] The sca-bpel:reference attribute MUST NOT be specified for a partner link with a myRole attribute referencing a role which is the only role of a partner link type.
When either of these attributes is used, the componentType will include a service or reference with the given name and no other service or reference will be generated for the partner link. The type of that service or reference is unaffected (it will be as specified in section 2.2).
[HYPERLINK \l "BPEL3020_T"SBPEL3020] A process MUST NOT include more than one of the following attributes on a single partner link:both sca-bpel:service, and sca-bpel:reference, and sca-bpel:multiRefFrom attributes on a single partner link.
Required Intents for Partner Links
[HYPERLINK \l "BPEL3021_T"SBPEL3021] To declare policy intents on a partner link element, the An SCA extension attribute sca-bpel:requires MAY MUST 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 partner link, without limiting the bindings that can be used for the partner link. The form of the attribute is the following:
[HYPERLINK \l "BPEL3022_T"SBPEL3022] The contents of the sca-bpel:requires attribute MUST 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.
[HYPERLINK \l "BPEL3023_T"SBPEL3023] If the sca-bpel:requires attribute is specified, the corresponding service or reference in the introspected component type MUST include an @sca:requires attribute with the same contents.
Using BPEL4WS 1.1 with SCA (Non-Normative)
A BPEL4WS 1.1 process definition can be used as the implementation of an SCA component. The syntax introduced in section REF _Ref179613301 \h \* MERGEFORMAT IntroductionIntroduction 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 can be used to generate an SCA Component Type.
Conformance
There are two categories of artifacts that this specification defines conformance for: SCA Documents and SCA Runtimes.
SCA WS-BPEL Document
A SCA WS-BPEL Document is a document that complies with the requirements defined by WS-BPEL 2.0 [WS-BPEL] and MAY include the SCA WS-BPEL extensions defined in Section 3. Any document using these extensions must comply with the sca-bpel schema and any other constraints defined by this specification.
SCA Runtimes
There are two conformance options defined by this specification:
1. Implementations of an SCA WS-BPEL Runtime
2. Implementations of an SCA Extended WS-BPEL Runtime.
SCA WS-BPEL Runtime
An implementation that claims to conform to an SCA WS-BPEL Runtime MUST meet the following conditions:
The implementation MUST meet all the conformance requirements defined by the SCA Assembly Model Specification [SCA-Assembly] i.e. it MUST be a conforming SCA Runtime.
The implementation MUST be a compliant WS-BPEL Processor as defined in WS-BPEL 2.0. It must accept and process WS-BPEL 2.0 process descriptions in a manner defined by WS-BPEL 2.0.
The SCA BPEL extensions defined in this specification MUST be treated as WS-BPEL 2.0 extensions. WS-BPEL process descriptions containing the SCA BPEL extensions MAY be rejected.
With the exception of the SCA BPEL extensions, the implementation MUST comply with all the normative statements in this specification (Appendix B), notably all the MUST statements have to be implemented.
SCA Extended WS-BPEL Runtime
An implementation that claims to conform to an SCA Extended WS-BPEL Runtime MUST meet the following conditions:
The implementation MUST meet the conditions for an SCA WS-BPEL Runtime above with the exception that SCA BPEL extensions defined in this specification MUST be supported. WS-BPEL process descriptions containing the SCA BPEL extensions MUST NOT be rejected
The implementation MUST support the SCA BPEL extensions defined in Section 3, and MUST implement them as defined.
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.
Conformance Items
This section contains a list of conformance items for the SCA-BPEL specification.
Conformance IDDescription[HYPERLINK \l "BPEL1002"SBPEL1001]The process attribute of the element MUST be the QName of an executable WS-BPEL process.[HYPERLINK \l "BPEL2001"SBPEL2001]If a partner link specifies a sca-bpel:service attribute, then a service MUST be generated for the introspected component type.[HYPERLINK \l "BPEL2002"SBPEL2002]The name of the service MUST be the value of the sca-bpel:service attribute[HYPERLINK \l "BPEL2003"SBPEL2003]If a partner link specifies a sca-bpel:reference attribute, then a reference MUST be generated for the introspected component type.[HYPERLINK \l "BPEL2004"SBPEL2004]The name of the reference MUST be the value of the sca-bpel:reference attribute.[HYPERLINK \l "BPEL2005"SBPEL2005]If neither sca-bpel:service nor sca-bpel:reference is present on the partner link, 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 include an SCA service that corresponds to the partner link in the component type.[HYPERLINK \l "BPEL2006"SBPEL2006]If the name of the partner link is unique within the process, then it MUST be used as the name of the service.[HYPERLINK \l "BPEL2007"SBPEL2007]If the rules [HYPERLINK \l "BPEL2001"SBPEL2001]-[HYPERLINK \l "BPEL2006"SBPEL2006] 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.[HYPERLINK \l "BPEL2008"SBPEL2008]If the name of the partner link is unique within the process, then it MUST be used as the name of the reference.[HYPERLINK \l "BPEL2009"SBPEL2009]The multiplicity of the reference MUST be determined according to the algorithm defined by rules [HYPERLINK \l "BPEL2010"SBPEL2010]-[HYPERLINK \l "BPEL2013"SBPEL2013].deleted[HYPERLINK \l "BPEL2010"SBPEL2010]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.[HYPERLINK \l "BPEL2011"SBPEL2011]If [HYPERLINK \l "BPEL2010"SBPEL2010] does not apply and the partner link has initializePartnerRole="yes", then the multiplicity MUST be "1..1".[HYPERLINK \l "BPEL2012"SBPEL2012]If neither [HYPERLINK \l "BPEL2010"SBPEL2010] nor [HYPERLINK \l "BPEL2011"SBPEL2011] apply and the analysis of the process determines that the first use of the partner link by any activity is in an activity that sets the partner role, then the multiplicity MUST be "0..1" and the attribute wiredByImpl MUST be set to "true".[HYPERLINK \l "BPEL2013"SBPEL2013]If neither [HYPERLINK \l "BPEL2010"SBPEL2010] nor [HYPERLINK \l "BPEL2011"SBPEL2011] nor [HYPERLINK \l "BPEL2012"SBPEL2012] apply, then the multiplicity MUST be "0..1".[HYPERLINK \l "BPEL2014"SBPEL2014]If a partner link is marked with initializePartnerRole="yes" then any component that uses this business process as an implementation MUST configure the corresponding service or reference using binding, promotion and wiring configuration that guarantees that the partner link's partner role will be initialized as soon as the partner link becomes active. If the partner link is mapped to a service, the callback binding would be the relevant binding for this requirement.If initializePartnerRole="yes" is specified for a partner link and the partner link 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 the partner role).[HYPERLINK \l "BPEL2015"SBPEL2015]The WSDL port type in the declaration for the service in the introspected component type MUST be the same as the port type of the myRole of the partner link.[HYPERLINK \l "BPEL2016"SBPEL2016]If the partner link type has two roles, then the declaration MUST also have a @callbackInterface attribute whose value points to the same WSDL port type as the partnerRole of the partner link.[HYPERLINK \l "BPEL2017"SBPEL2017]The WSDL port type in the declaration for the reference MUST be the same as the port type of the partnerRole of the partner link.[HYPERLINK \l "BPEL2018"SBPEL2018]If the partner link type has two roles, then the declaration MUST also have a @callbackInterface attribute whose value points to the same WSDL port type as the myRole of the partner link.[HYPERLINK \l "BPEL2019"SBPEL2019]When multiple partner links share the same name, the scheme defined by [HYPERLINK \l "BPEL2020"SBPEL2020]-[HYPERLINK \l "BPEL2022"SBPEL2022] MUST be used to disambiguate different occurrences of partner link declaration.deleted[HYPERLINK \l "BPEL2020"SBPEL2020]The introspected component type MUST include services or references corresponding to these partner links with names: "_orginaloriginalName_1" to "_orginaloriginalName_N".[HYPERLINK \l "BPEL2021"SBPEL2021]The number suffixes for the partner links MUST be based on the lexical order of the corresponding partner link occurrences in the process definition.[HYPERLINK \l "BPEL2022"SBPEL2022]If any "_orginaloriginalName_i" (where 1 <= i <= N) is already the name of a partner link declaration in the process definition, additional underscore characters MAY be added at the beginning of all aliases consistently to avoid collision.[HYPERLINK \l "BPEL3001"SBPEL3001]The name of a variable used as a property of the component MUST be unique within the process.[HYPERLINK \l "BPEL3002"SBPEL3002]If a value is provided for a 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.[HYPERLINK \l "BPEL3003"SBPEL3003]If a BPEL variable that is used as a property has an initialization from-spec then mustSupply="false" 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.[HYPERLINK \l "BPEL3004"SBPEL3004]In a WS-BPEL process definition, a variable MAY include an sca-bpel:multiReference extension element that declares that the variable represents a multi-valued reference.[HYPERLINK \l "BPEL3005"SBPEL3005]When a variable declaration contains the sca-bpel:multiReference extension, the type of the variable MUST be an element of sca-bpel:serviceReferenceList.[HYPERLINK \l "BPEL3006"SBPEL3006]The introspected component type MUST include a reference with a multiplicity of either "0..n" or "1..n" that corresponds to a variable with the sca-bpel:multiReference element.[HYPERLINK \l "BPEL3007"SBPEL3007]The type of the reference MUST be determined by the partner link type and the partner role attributes of the sca-bpel:multiReference extension element.[HYPERLINK \l "BPEL3008"SBPEL3008]The sca-bpel:multiRefFrom attribute MUST NOT be specified for a partner link with a myRole attribute referencing a role which is the only role of a partner link type.[HYPERLINK \l "BPEL3009"SBPEL3009]The sca-bpel:multiRefFrom attribute MUST NOT be specified for a partner link that has the sca-bpel:service attribute.[HYPERLINK \l "BPEL3010"SBPEL3010]The value of the sca-bpel:multiRefFrom attribute MUST refer to the name of a variable manifesting an SCA multi-valued reference.[HYPERLINK \l "BPEL3011"SBPEL3011]For the child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the , both of the following MUST be true:
(1) The partnerLinkType attribute of the is the same as the partnerLinkType attribute of the . (2) The name of the partnerRole for the is the same as the partnerRole attribute of the .The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable MUST be matched.[HYPERLINK \l "BPEL3012"SBPEL3012]There MUST be at least one code-path where the values from the multi-valued reference variable are copied to the partnerRole of the partner link.[SBPEL3013]A WS-BPEL process definition MAY override the default mapping of partner links to services or references as described in section 2.1 by explicitly marking the partner link with an SCA attribute that describes the service or reference.deleted[HYPERLINK \l "BPEL3014"SBPEL3014]To explicitly map a partner link to a service, the sca-bpel:service attribute MAY be specified for the partner link.deleted[HYPERLINK \l "BPEL3015"SBPEL3015]The name of the service specified in the sca-bpel:service attribute MUST NOT conflict with any other service name generated in the component type for this process.[HYPERLINK \l "BPEL3016"SBPEL3016]The sca-bpel:service attribute MUST NOT be specified for a partner link with a partnerRole attribute referencing a role which is the only role of a partner link type.[HYPERLINK \l "BPEL3017"SBPEL3017]To explicitly map a partner link to a reference, the sca-bpel:reference attribute MAY be specified for the partner link.deleted[HYPERLINK \l "BPEL3018"SBPEL3018]The name of the reference specified in the sca-bpel:service reference attribute MUST NOT conflict with any other reference name generated in the component type for this process.[HYPERLINK \l "BPEL3019"SBPEL3019]The sca-bpel:reference attribute MUST NOT be specified for a partner link with a myRole attribute referencing a role which is the only role of a partner link type.[HYPERLINK \l "BPEL3020"SBPEL3020]A process MUST NOT include both sca-bpel:service and sca-bpel:reference attributes on a single partner link.[HYPERLINK \l "BPEL3021"SBPEL3021]To declare policy intents on a partner link element, the An SCA extension attribute sca-bpel:requires MAY MUST be used to declare required policy intents on a partner link.[HYPERLINK \l "BPEL3022"SBPEL3022]The contents of the sca-bpel:requires attribute MUST 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.[HYPERLINK \l "BPEL3023"SBPEL3023]If the sca-bpel:requires attribute is specified, the corresponding service or reference in the introspected component type MUST include an @sca:requires attribute with the same contents.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 Booz, IBM
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, Active Endpoints, Inc.
Paul Tazbaz, Wells Fargo
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
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 attribute, 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-3 ] n o p t ƧoYG( <