Appendix B. Static Analysis requirement summary (Non-Normative)
The purpose of static analysis is to detect any undefined semantics or invalid semantics within a process definition that was not detected during the schema validation against the XSD found in Appendix E. XML Schemas Any process definition that fails one or more of these checks must be rejected by the WS-BPEL processor.
This appendix summarizes the requirements for static analysis specified in the main body of the specification and is provided for convenience.
Static Analysis Fault Code
Static analysis Description
Section Reference
SA00001
A WS-BPEL processor MUST reject a WS-BPEL that refers to solicit-response or notification operations portTypes.
Section 3
SA00002
A WS-BPEL processor MUST reject any WSDL portType definition that includes overloaded operation names.
Section 3
SA00003
If the value of exitOnStandardFault of a or
is set to “yes”, then a fault handler that explicitly targets the WS-BPEL standard faults MUST NOT be used in that scope.
Section 5.2
SA00004
If any referenced queryLanguage or expressionLanguage is unsupported by the WS-BPEL processor then the processor MUST reject the submitted WS-BPEL process definition.
Section 5.2
SA00005
If the portType attribute is included for readability, in a , , , or element, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity.
Section 5.2
SA00006
The activity MUST only be used within a faultHandler (i.e. and elements).
Section 5.2
SA00007
The activity MUST only be used from within a faultHandler, another compensationHandler, or a terminationHandler.
Section 5.2
SA00008
The activity MUST only be used from within a faultHandler, another compensationHandler, or a terminationHandler.
Section 5.2
SA00009
In the case of mandatory extensions declared in the element not supported by a WS-BPEL implementation, the process definition MUST be rejected.
Section 5.3
SA00010
A WS-BPEL process definition MUST import all XML Schema and WSDL definitions it uses. This includes all XML Schema type and element definitions, all WSDL port types and message types as well as property and property alias definitions used by the process.
Section 5.4
SA00011
If a namespace attribute is specified on an then the imported definitions MUST be in that namespace.
Section 5.4
SA00012
If no namespace is specified then the imported definitions MUST NOT contain a targetNamespace specification.
Section 5.4
SA00013
The value of the importType attribute of element MUST be set to http://www.w3.org/2001/XMLSchema when importing XML Schema 1.0 documents, and to http://schemas.xmlsoap.org/wsdl/ when importing WSDL 1.1 documents.
Section 5.4
SA00014
A WS-BPEL process definition MUST be rejected if the imported documents contain conflicting definitions of a component used by the importing process definition (as could be caused, for example, when the XSD redefinition mechanism is used).
Section 5.4
SA00015
To be instantiated, an executable business process MUST contain at least one or activity annotated with a createInstance="yes" attribute.
Section 5.5
SA00016
A partnerLink MUST specify the myRole or the partnerRole, or both.
Section 6.2
SA00017
The initializePartnerRole attribute MUST NOT be used on a partnerLink that does not have a partner role.
Section 6.2
SA00018
The name of a partnerLink MUST be unique among the names of all partnerLinks defined within the same immediately enclosing scope.
A element MUST use one of the three following combinations of attributes:
messageType and part,
type or
element
Section 7.3
SA00021
Static analysis MUST detect property usages where propertyAliases for the associated variable's type are not found in any WSDL definitions directly imported by the WS-BPEL process.
Section 7.3
SA00022
A WS-BPEL process definition MUST NOT be accepted for processing if it defines two or more propertyAliases for the same property name and WS-BPEL variable type.
Section 7.3
SA00023
The name of a variable MUST be unique among the names of all variables defined within the same immediately enclosing scope.
Section 8.1
SA00024
Variable names are BPELVariableNames, that is, NCNames (as defined in XML Schema specification) but in addition they MUST NOT contain the “.” character.
Section 8.1
SA00025
The messageType, type or element attributes are used to specify the type of a variable. Exactly one of these attributes MUST be used.
Section 8.1
SA00026
Variable initialization logic contained in scopes that contain or whose children contain a start activity MUST only use idempotent functions in the from-spec.
Section 8.1
SA00027
When XPath 1.0 is used as an expression language in WS-BPEL there is no context node available. Therefore the legal values of the XPath Expr (http://www.w3.org/TR/xpath#NT-Expr) production must be restricted in order to prevent access to the context node.
Specifically, the "LocationPath" (http://www.w3.org/TR/xpath#NT-LocationPath) production rule of "PathExpr" (http://www.w3.org/TR/xpath#NT-PathExpr) production rule MUST NOT be used when XPath is used as an expression language.
Section 8.2.4
SA00028
WS-BPEL functions MUST NOT be used in joinConditions.
Section 8.2.5
SA00029
WS-BPEL variables and WS-BPEL functions MUST NOT be used in query expressions of propertyAlias definitions.
Section 8.2.6
SA00030
The arguments to bpel:getVariableProperty MUST be given as quoted strings. It is therefore illegal to pass into a WS-BPEL XPath function any XPath variables, the output of XPath functions, a XPath location path or any other value that is not a quoted string.
Section 8.3
SA00031
The second argument of the XPath 1.0 extension function bpel:getVariableProperty(string, string) MUST be a string literal conforming to the definition of QName in [XML Namespaces] section 3.
Section 8.3
SA00032
For , the and element MUST be one of the specified variants.
The activity copies a type-compatible value from the source ("from-spec") to the destination ("to-spec"), using the element. Except in Abstract Processes, the from-spec MUST be one of the following variants:
?
queryContent
endpointReference="myRole|partnerRole" />
property="QName" />
expression
literal value
In Abstract Processes, the from-spec MUST be either one of the above or the opaque variant described in section 13.1.3. Hiding Syntactic Elements
The to-spec MUST be one of the following variants:
?
queryContent
property="QName" />
expression
Section 8.4
SA00033
The XPath expression in MUST begin with an XPath VariableReference.
Section 8.4
SA00034
When the variable used in or is defined using XML Schema types (simple or complex) or element, the part attribute MUST NOT be used.
Section 8.4
SA00035
In the from-spec of the partnerLink variant of the value "myRole" for attribute endpointReference is only permitted when the partnerLink specifies the attribute myRole.
Section 8.4
SA00036
In the from-spec of the partnerLink variant of the value "partnerRole" for attribute endpointReference is only permitted when the partnerLink specifies the attribute partnerRole.
Section 8.4
SA00037
In the to-spec of the partnerLink variant of assign only partnerLinks are permitted which specify the attribute partnerRole.
Section 8.4
SA00038
The literal from-spec variant returns values as if it were a from-spec that selects the children of the element in the WS-BPEL source code. The return value MUST be a single EII or Text Information Item (TII) only.
Section 8.4
SA00039
The first parameter of the XPath 1.0 extension function bpel:doXslTransform(string, node-set, (string, object)*) is an XPath string providing a URI naming the style sheet to be used by the WS-BPEL processor. This MUST take the form of a string literal.
Section 8.4
SA00040
In the XPath 1.0 extension function bpel:doXslTransform(string, node-set, (string, object)*) the optional parameters after the second parameter MUST appear in pairs. An odd number of parameters is not valid.
Section 8.4
SA00041
For the third and subsequent parameters of the XPath 1.0 extension function bpel:doXslTransform(string, node-set, (string, object)*) the global parameter names MUST be string literals conforming to the definition of QName in section 3 of [Namespaces in XML].
Section 8.4
SA00042
For the optional keepSrcElementName attribute is provided to further refine the behavior. It is only applicable when the results of both from-spec and to-spec are EIIs, and MUST NOT be explicitly set in other cases.
Section 8.4.2
SA00043
For a copy operation to be valid, the data referred to by the from-spec and the to-spec MUST be of compatible types.
The following situations are considered type incompatible:
the selection results of both the from-spec and the to-spec are variables of a WSDL message type, and the two variables are not of the same WSDL message type (two WSDL message types are the same if their QNames are equal).
the selection result of the from-spec is a variable of a WSDL message type and that of the to-spec is not, or vice versa (parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly).
Section 8.4.3
SA00044
The name of a MUST be unique among the names of all defined within the same immediately enclosing scope.
Section 9.1
SA00045
Properties used in a MUST be defined using XML Schema simple types.
Section 9.2
SA00046
The pattern attribute used in within is required for request-response operations, and disallowed when a one-way operation is invoked.
Section 9.2
SA00047
One-way invocation requires only the inputVariable (or its equivalent elements) since a response is not expected as part of the operation (see section 10.4. Providing Web Service Operations – Receive and Reply ). Request-response invocation requires both an inputVariable (or its equivalent elements) and an outputVariable (or its equivalent elements). If a WSDL message definition does not contain any parts, then the associated attributes variable, inputVariable or outputVariable, MAY be omitted,and the or construct MUST be omitted.
Section 10.3
Section 10.4
Section 10.4
Section 11.5
Section 12.7
SA00048
When the optional inputVariable and outputVariable attributes are being used in an activity, the variables referenced by inputVariable and outputVariable MUST be messageType variables whose QName matches the QName of the input and output message type used in the operation, respectively, except as follows: if the WSDL operation used in an activity uses a message containing exactly one part which itself is defined using an element, then a variable of the same element type as used to define the part MAY be referenced by the inputVariable and outputVariable attributes respectively.
Section 10.3
SA00050
When is present in an , it is not required to have a for every part in the WSDL message definition, nor is the order in which parts are specified relevant. Parts not explicitly represented by elements would result in uninitialized parts in the target anonymous WSDL variable used by the or activity. Such processes with missing elements MUST be rejected during static analysis.
The outputVariable attribute MUST NOT be used on an activity that contains a element.
Section 10.3.1
SA00053
For all elements the part attribute MUST reference a valid message part in the WSDL message for the operation.
Section 5.4
SA00054
For all elements the part attribute MUST reference a valid message part in the WSDL message for the operation.
Section 5.4
SA00055
For , if elements are used on a activity then the variable attribute MUST NOT be used on the same activity.
Section 10.4
SA00056
A "start activity" is a or
activity that is annotated with a createInstance="yes" attribute. Activities other than the following: start activities, , and MUST NOT be performed prior to or simultaneously with start activities.
Section 10.4
SA00057
If a process has multiple start activities with correlation sets then all such activities MUST share at least one common correlationSet and all common correlationSets defined on all the activities MUST have the value of the initiate attribute be set to "join".
Section 10.4
SA00058
In a or activity, the variable referenced by the variable attribute MUST be a messageType variable whose QName matches the QName of the input (for ) or output (for ) message type used in the operation, except as follows: if the WSDL operation uses a message containing exactly one part which itself is defined using an element, then a WS-BPEL variable of the same element type as used to define the part MAY be referenced by the variable attribute of the or activity.
Section 10.4
SA00059
For , if elements are used on a activity then the variable attribute MUST NOT be used on the same activity.
Section 10.4
SA00060
The explicit use of messageExchange is needed only where the execution can result in multiple IMA- pairs (e.g. - pair) on the same partnerLink and operation being executed simultaneously. In these cases, the process definition MUST explicitly mark the pairing-up relationship.
Section 10.4.1
SA00061
The name used in the optional messageExchange attribute MUST resolve to a messageExchange declared in a scope (where the process is considered the root scope) which encloses the activity and its corresponding IMA.
Section 10.4.1
SA00062
If
has a createInstance attribute with a value of yes, the events in the
MUST all be events.
Section 11.5
SA00063
The semantics of the event are identical to a activity regarding the optional nature of the variable attribute or elements, if elements on an activity then the variable attribute MUST NOT be used on the same activity (see SA00055).
Section 11.5
SA00064
For , a declared link’s name MUST be unique among all names defined within the same immediately enclosing .
Every link declared within a activity MUST have exactly one activity within the as its source and exactly one activity within the as its target.
Section 11.6.1
SA00067
Two different links MUST NOT share the same source and target activities; that is, at most one link may be used to connect two activities.
Section 11.6.1
SA00068
An activity MAY declare itself to be the source of one or more links by including one or more elements. Each element MUST use a distinct link name.
Section 11.6.1
SA00069
An activity MAY declare itself to be the target of one or more links by including one or more elements. Each element associated with a given activity MUST use a link name distinct from all other elements at that activity.
Section 11.6.1
SA00070
A link MUST NOT cross the boundary of a repeatable construct or the element. This means, a link used within a repeatable construct (, , , ) or a MUST be declared in a that is itself nested inside the repeatable construct or .
Section 11.6.1
SA00071
A link that crosses a , or element boundary MUST be outbound only, that is, it MUST have its source activity within the or , and its target activity outside of the scope associated with the handler.
Section 11.6.1
SA00072
A declared in a MUST NOT create a control cycle, that is, the source activity must not have the target activity as a logically preceding activity.
Section 11.6.1
SA00073
The expression for a join condition MUST be constructed using only Boolean operators and the activity's incoming links' status values.
Section 11.6.2
SA00074
The expressions in and MUST return a TII (meaning they contain at least one character) that can be validated as a xsd:unsignedInt. Static analysis MAY be used to detect this erroneous situation at design time when possible (for example, when the expression is a constant).
Section 11.7
SA00075
For the activity, is an integer value expression. Static analysis MAY be used to detect if the integer value is larger than the number of directly enclosed activities of at design time when possible (for example, when the branches expression is a constant).
Section 11.7
SA00076
For the enclosed scope MUST NOT declare a variable with the same name as specified in the counterName attribute of .
Section 11.7
SA00077
The value of the target attribute on a activity MUST refer to the name of an immediately enclosed scope of the scope containing the FCT-handler with the activity. This includes immediately enclosed scopes of an event handler ( or ) associated with the same scope.
Section 12.4.3.1
SA00078
The target attribute of a activity MUST refer to a scope or an invoke activity with a fault handler or compensation handler.
Section 12.4.3.1
SA00079
The root scope inside a FCT-handler MUST not have a compensation handler.
Section 12.4.4.3
SA00080
There MUST be at least one or element within a element.
Section 12.5
SA00081
For the construct; to have a defined type associated with the fault variable, the faultVariable attribute MUST only be used if either the faultMessageType or faultElement attributes, but not both, accompany it. The faultMessageType and faultElement attributes MUST NOT be used unless accompanied by faultVariable attribute.
Section 12.5
SA00082
The peer-scope dependency relation MUST NOT include cycles. In other words, WS-BPEL forbids a process in which there are peer scopes S1 and S2 such that S1 has a peer-scope dependency on S2 and S2 has a peer-scope dependency on S1.
Section 12.5.2
SA00083
An event handler MUST contain at least one or element.
Section 12.7
SA00084
The partnerLink reference of MUST resolve to a partner link declared in the process in the following order: the associated scope first and then the ancestor scopes.
Section 12.7.1
SA00085
The syntax and semantics of the elements as used on the element are the same as specified for the receive activity. This includes the restriction that if elements are used on an onEvent element then the variable, element and messageType attributes MUST NOT be used on the same element.
Section 12.7.1
SA00086
For , variables referenced by the variable attribute of elements or the variable attribute of an element are implicitly declared in the associated scope of the event handler. Variables of the same names MUST NOT be explicitly declared in the associated scope..
Section 12.7.1
SA00087
For , the type of the variable (as specified by the messageType attribute) MUST be the same as the type of the input message defined by operation referenced by the operation attribute. Optionally the messageType attribute may be omitted and instead the element attribute substituted if the message to be received has a single part and that part is defined with an element type. That element type MUST be an exact match of the element type referenced by the element attribute.
Section 12.7.1
SA00088
For , the resolution order of the correlation set(s) referenced by MUST be first the associated scope and then the ancestor scopes.
Section 12.7.1
SA00089
For , when the messageExchange attribute is explicitly specified, the resolution order of the message exchange referenced by messageExchange attribute MUST be first the associated scope and then the ancestor scopes.
Section 12.7.1
SA00090
If the variable attribute is used in the element, either the messageType or the element attribute MUST be provided in the element.
Section 12.7.1
SA00091
A scope with the isolated attribute set to "yes" is called an isolated scope. Isolated scopes MUST NOT contain other isolated scopes.
Section 12.8
SA00092
Within a scope, the name of all named immediately enclosed scopes MUST be unique.
Section 12.4.3
SA00093
Identical constructs MUST NOT exist within a element.
Section 12.5
SA00094
For , when the keepSrcElementName attribute is set to “yes” and the destination element is the Document EII of an element-based variable or an element-based part of a WSDL message-type-based variable, the name of the source element MUST belong to the substitutionGroup of the destination element. This checking MAY be enforced through static analysis of the expression/query language.
Section 8.4.2
SA00095
For , the variable references are resolved to the associated scope only and MUST NOT be resolved to the ancestor scopes.
Yüklə 2.65 Mb.