ࡱ > #` ~ bjbj z u < < < < < < < $ ` (k (k (k P xk |l ` D m V rr | r r r "t x \ (z 8 h < Y{ "t "t Y{ Y{ < < r r 4 ͉ ͉ ͉ Y{ < r < r ͉ Y{ ͉ ͉ j ] < < ] r m " (k E 2 0 D w ه d ] ] < z z ͉ z { S z z z u X z z z D Y{ Y{ Y{ Y{ ` ` ` $* A ) ` ` ` A ` ` ` < < < < < <
Service Component Architecture Client and Implementation Model Specification for WS-BPEL Version 2.0
Working Draft
20 September, 2007
Specification URIs:
This Version:
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.pdf" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.pdf
Previous Version:
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.pdf" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.pdf
Latest Version:
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.pdf" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.pdf
Latest Approved Version:
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.html
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.doc
HYPERLINK "http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.pdf" http://docs.oasis-open.org/sca-bpel/sca-bpel-draft-20-09-07.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 Koenig, IBM
Michael Rowley, BEA Systems
Ivana Trickovic, SAP
Alex Yiu, Oracle
Related work:
This specification is related to:
Web Services Business Process Execution Language Version 2.0
Declared XML Namespace(s):
MACROBUTTON NoMacro [list namespaces here]
MACROBUTTON NoMacro [list namespaces here]
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 1.5.
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. 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 \u HYPERLINK \l "_Toc178058147" 1 Introduction PAGEREF _Toc178058147 \h 4
HYPERLINK \l "_Toc178058148" 1.1 Terminology PAGEREF _Toc178058148 \h 4
HYPERLINK \l "_Toc178058149" 1.2 Normative References PAGEREF _Toc178058149 \h 4
HYPERLINK \l "_Toc178058150" 1.3 Non-Normative References PAGEREF _Toc178058150 \h 4
HYPERLINK \l "_Toc178058151" 2 WS-BPEL Processes as Component Implementations PAGEREF _Toc178058151 \h 4
HYPERLINK \l "_Toc178058152" 3 Component Types defined by WS-BPEL Processes PAGEREF _Toc178058152 \h 4
HYPERLINK \l "_Toc178058153" 3.1 Services and References PAGEREF _Toc178058153 \h 5
HYPERLINK \l "_Toc178058154" 3.2 PartnerLinkTypes and SCA Interfaces PAGEREF _Toc178058154 \h 6
HYPERLINK \l "_Toc178058155" 3.3 Specifying an SCA interface with a partnerLinkType PAGEREF _Toc178058155 \h 7
HYPERLINK \l "_Toc178058156" 3.4 Handling of Local PartnerLinks PAGEREF _Toc178058156 \h 7
HYPERLINK \l "_Toc178058157" 3.5 Support for conversational interfaces PAGEREF _Toc178058157 \h 8
HYPERLINK \l "_Toc178058158" 4 SCA Extensions to WS-BPEL PAGEREF _Toc178058158 \h 8
HYPERLINK \l "_Toc178058159" 4.1 Properties PAGEREF _Toc178058159 \h 8
HYPERLINK \l "_Toc178058160" 4.2 Multi-Valued References PAGEREF _Toc178058160 \h 9
HYPERLINK \l "_Toc178058161" 5 Using BPEL4WS 1.1 with SCA PAGEREF _Toc178058161 \h 11
HYPERLINK \l "_Toc178058162" A. Acknowledgements PAGEREF _Toc178058162 \h 11
HYPERLINK \l "_Toc178058163" B. Non-Normative Text PAGEREF _Toc178058163 \h 11
HYPERLINK \l "_Toc178058164" C. Revision History PAGEREF _Toc178058164 \h 11
Introduction
A WS-BPEL process definition may be used as the implementation of an SCA component.
Such a component definition has the following form:
*
*
property-value?
*
wire-target-URI
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.
MACROBUTTON NoMacro [Reference] MACROBUTTON NoMacro [Full reference citation]
Non-Normative References
MACROBUTTON NoMacro [Reference] MACROBUTTON NoMacro [Full reference citation]
Component Types defined by 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 ComponentType of any SCA component that uses that implementation. The 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 _Ref157843611 \r \h [1] as follows:
*
*
*
default-property-value?
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 be used to determine which role can send the first message.
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 has a corresponding SCA service in the component type. If the partner link declaration has initializePartnerRole="yes", then the service must be wired 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:multiRefFrom="aVariableName" extension, the multiplicity of the SCA reference will be determined by the multiplicity attribute of sca: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 1.4.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)
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 the aliases 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 _Ref157843611 \r \h [1] 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 _Ref158100455 \r \h [1], section 1.5.3 for a description of this fault.
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.
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, 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: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.
At runtime, the variable will be initialized with the value provided by the component definition that uses the WS-BPEL process.
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:multiReference extension element that declares that the variable represents a multi-valued reference. The type of the variable must be an element of sca:serviceRefList. However, since that type only specifies that the variable holds a list of endpoint references, the sca: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: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 1.3.1.
To assist a more effective SCA modeling, another SCA extension is introduced to associate a multi-valued reference, manifested as a "sca:serviceReferenceList" variable with a partner link. This extension is in an attribute form attached to the partner link declaration. Syntax of this extension is:
sca:multiRefFrom="xs:NCName"
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: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 1.3.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/bpel:service-ref)
...
...
...
$vendors/bpel: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: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.
Using BPEL4WS 1.1 with SCA
A BPEL4WS 1.1 process definition may be used as the implementation of an SCA component. The syntax introduced in section REF _Ref158191285 \r \h 1.2 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.
Acknowledgements
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Participants: MACROBUTTON
MACROBUTTON NoMacro [Participant Name, Affiliation | Individual Member]
MACROBUTTON NoMacro [Participant Name, Affiliation | Individual Member]
Non-Normative Text
Revision History
MACROBUTTON NoMacro [optional; should not be included in OASIS Standards]
RevisionDateEditorChanges Made MACROBUTTON NoMacro [Rev number] MACROBUTTON NoMacro [Rev Date] MACROBUTTON NoMacro [Modified By] MACROBUTTON NoMacro [Summary of Changes]
MACROBUTTON NoMacro [Document Identifier] MACROBUTTON NoMacro [DD Month YYYY]
Copyright OASIS 2007. All Rights Reserved. Page PAGE 19 of NUMPAGES 9
MACROBUTTON NoMacro [document identifier] MACROBUTTON NoMacro [specification date]
Copyright OASIS Open 2004.All Rights Reserved. Page PAGE 1 of NUMPAGES 9
Z c f g t u ; < = > J
ƛƒƛvc $j hy h B*Uph hk h 0J $ja hy h B*Uph hk h1D 0J hy h 0J $j hy h B*Uph h h 0J
h 0J j h 0J Uh1D h7; h) h) h} hn( h) h# hk hI j hI U &