This chapter describes how to handle errors with Oracle Mediator (Mediator).
This chapter includes the following sections:
Oracle Mediator provides sophisticated error handling capabilities that enable you to configure a Mediator service component for error occurrences and corresponding corrective actions. Error handling enables a Mediator to handle errors that occur during the processing of messages and also the exceptions returned by outside Web services. You can handle both business faults and system faults with Mediator.
Business faults are application-specific and are explicitly defined in the service WSDL file. You can handle business faults by defining the fault handlers in Oracle JDeveloper at design time. System faults occur because of some problem in the underlying system such as network not being available. Mediator provides fault policy-based error handling for system faults.
Fault policies enable you to handle errors automatically or through human intervention. Mediator fault policy-based error handling consists of the following three components:
A fault policy defines error conditions and corresponding actions. Fault policies are defined in the fault-policies.xml file. The fault-policies.xml file should be created based on the XML schema defined in Section 20.4.1, "Schema Definition File for Fault-policies.xml".
Note:
Fault policies are applicable to parallel routing rules only. For sequential routing rules, the fault goes back to the caller and it is the responsibility of the caller to handle the fault. If the caller is an adapter, then you can define rejection handlers on the inbound adapter to take care of the errored out messages, that is, the rejected messages. For more information about Rejection Handlers, refer to Oracle Fusion Middleware User's Guide for Technology Adapters.A sample fault policy file is shown in the following example:
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies>
<faultPolicy version="2.0.1" id="CRM_ServiceFaults">
<Conditions>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test>
<action ref="ora-retry"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="ora-java"/>
<retrySuccessAction ref="ora-terminate"/>
</retry>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>
The two components of the fault policy are described in the following sections:
Conditions identify error or fault conditions along with reference to the actions to be taken. You can use conditions to identify the action to be taken when a particular error or fault condition occurs. For example, for a particular error occurring because of a service not being available, you can perform an action such as retry. Similarly, for another error occurring because of failure of Schematron validation, you can perform the action human intervention. This fault can be recovered manually by editing the payload and then resubmitting through Oracle Enterprise Manager.
Conditions are defined in the fault-policies.xml file, as shown in the following example:
<Conditions>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode,"TYPE_DATA_TRANSFORMATION")</test>
<action ref="ora-java"/>
</condition>
</faultName>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test>
<action ref="ora-retry"/>
</condition>
</faultName>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode,"TYPE_DATA_ASSIGN")</test>
<action ref="ora-retry-crm-endpoint"/>
</condition>
</faultName>
</Conditions>
Identifying Fault Types Using Conditions
You can categorize the faults that can be captured using conditions in the following types:
Mediator-specific faults
For all Mediator-specific faults, Mediator engine throws only one fault, namely {http://schemas.oracle.com/mediator/faults}mediatorFault. Every Mediator fault is wrapped into this fault. The errors or faults generated by a Mediator composite can be captured by using the following format:
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
<!-- mediatorFault is a bucket for all the mediator faults -->
<condition>
<test>
contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")
</test>
<!-- Captures TYPE_FATAL_MESH errors -->
<action ref="ora-retry"/>
</condition>
</faultName>
Business faults and SOAP faults
The errors or faults that can be captured by defining an XPath condition, which is based on the fault payload. For example:
<faultName xmlns:ns1="http://xmlns.oracle.com/Customer"
name="ns1:InvalidCustomer"> <!-- Qname of Business/SOAP fault -->
<condition>
<test>
contains($fault.<PART_NAME>/custid, 1011)
</test>
<!-- xpath condition based on fault payload -->
<action ref="ora-retry"/>
</condition>
</faultName>
When a reference service returns a business fault, the fault can be handled in the Mediator component. The returned fault can be forwarded to another component, redirected to an adapter service like File adapter, or an event can be raised. But, if both fault policy and fault handler are defined for a business fault, then fault policy takes precedence over fault handler. In such a case, the fault handlers in the Mediator component are ignored, if the fault policy is successfully executed.
Adapter-specific fault
The errors or faults generated by an Adapter can be captured by using the following format:
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
<condition>
<test>$fault.faultCode = "1"</test> <!-- unique constraint violation in DB adapter-->
<action ref="ora-retry"/>
</condition>
</faultName>
Actions specify the tasks that should be performed when an error occurs. Mediator provides a list of actions that you can use in a fault policy. These predefined actions are described in the following list:
Retry: Retry actions like enqueueing a message to a JMS queue that is stopped, or inserting a record with unique key constraint error and so on, enable you to retry a task that caused the error. A new thread is started with every retry action. So, with every retry action, a new transaction starts. The options available with retry action are:
| Option | Description |
|---|---|
| Retry Count | Retry N times |
| Retry Interval | Delay in seconds for retry |
| Exponential Backoff | Retry interval increase with exponential backoff |
| Retry Failure Action | Chain to this action if retry N times fails |
| Retry Success Action | Chain to this action if retry succeeds |
Note:
Exponential backoff indicates that the next retry attempt is scheduled at 2 x the delay, where delay is the current retry interval. For example, if the current retry interval is 2 seconds, the next retry attempt is scheduled at 4, the next at 8, and the next at 16 seconds until theretryCount value is reached.The following code snippet shows how to specify the Retry action:
<Action id="ora-retry"> <retry> <retryCount>3</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> <retryFailureAction ref="ora-java"/> <retrySuccessAction ref="ora-java"/> </retry> </Action>
If you set the Retry Interval in the fault policy to a duration less than 30 seconds, then the retry may not happen within the specified intervals. This is because the default value of the org.quartz.scheduler.idleWaitTime property is 30 seconds, and the scheduler waits for 30 seconds before retrying for available triggers, when the scheduler is otherwise idle. If the Retry Interval is set to a value less than 30 seconds, then latency is expected.
If you want the system to use a retry interval that is less than 30 seconds, then add the following property under the section <property name="quartzProperties"> in the fabric-config-core.xml file:
org.quartz.scheduler.idleWaitTime=<value>
Human intervention: You can specify this action in the following way:
<Action id="ora-human-intervention"><humanIntervention/></Action>
Abort: This action enables you to abort the flow. You can specify this action in the following way:
<Action id="ora-terminate"><abort/></Action>
Java code: This action enables you to call a customized Java class that implements the oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass interface. You can specify this action in the following way:
Note:
The implemented Java class must implement a method that returns a String. The policy can be chained to a new action based on the returned String.
<Action id="ora-java">
<javaAction className="mypackage.myClass" defaultAction="ora-terminate">
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>
For more information about oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass interface and oracle.integration.platform.faultpolicy.IFaultRecoveryContext interface, see the SOA Javadoc.
Fault bindings associate fault policies with composites or components, and are defined in the fault-bindings.xml file. The fault-bindings.xml file should be created based on the XML schema defined in Section 20.4.2, "Schema Definition File for Fault-bindings.xml".
Fault policies can be created at the following levels:
Composite: You can define one fault policy for all Mediator components in a composite. You can specify this level in the following way:
<composite faultPolicy="ConnectionFaults"/>
Component: You can define a fault policy for a Mediator component exclusively. A component-level fault policy overrides the composite-level fault policy. You can specify this level in the following way:
<component faultPolicy="ConnectionFaults">
<name>Component1</name>
<name>Component2</name>
</component>
Reference: You can define a fault policy for the references of a Mediator component. You can specify this level in the following way:
<reference faultPolicy="policy1"> <name>DBAdapter3</name> </reference>
Note:
Human intervention is the default action for errors that do not have a fault policy defined.A sample fault binding file is shown in the following example:
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="ConnectionFaults"/>
</faultPolicyBindings>
You can specify an action for an error type or error group while defining the conditions in a fault policy. In the previous examples, medns:mediatorFault refers that the error is a Mediator error, whereas medns:TYPE_FATAL_MESH refers to an error group. An error group consists of one or more child error types. TYPE_ALL is an error group that contains all Mediator errors.
The following list describes various error groups contained in the TYPE_ALL error group:
TYPE_DATA: Contains errors related to data handling.
TYPE_DATA_ASSIGN: Contains errors related to data assignment.
TYPE_DATA_FILTERING: Contains errors related to data filtering.
TYPE_DATA_TRANSFORMATION: Contains errors that occur during transformation.
TYPE_DATA_VALIDATION: Contains errors that occur during payload validation.
TYPE_METADATA: Contains errors related to Mediator metadata.
TYPE_METADATA_FILTERING: Contains errors that occur while processing the filtering conditions.
TYPE_METADATA_TRANSFORMATION: Contains errors that occur during getting the metadata for transformation.
TYPE_METADATA_VALIDATION: Contains errors that occur during validation of metadata for Mediator (.mplan file).
TYPE_METADATA_COMMON: Contains other errors that occur during the handling of metadata.
TYPE_FATAL: Contains fatal errors that are not easily recoverable.
TYPE_FATAL_DB: Contains database related fatal errors, such as Datasource not found error.
TYPE_FATAL_CACHE: Contains Mediator cache-related fatal errors.
TYPE_FATAL_ERRORHANDLING: Contains fatal errors that occur during error handling such as Resubmission queues not available.
TYPE_FATAL_MESH: Contains fatal errors from the Service Infrastructure such as Invoke service not available.
TYPE_FATAL_MESSAGING: Contains fatal messaging errors arising from the Service Infrastructure.
TYPE_FATAL_TRANSACTION: Contains fatal errors related to transactions such as Commit can't be called on a transaction which is marked for rollback.
TYPE_FATAL_TRANSFORMATION: Contains fatal transformation errors such as error occurring because of the XPath functions used in a transformation.
TYPE_TRANSIENT: Contains transient errors that can be recovered on retrying.
TYPE_TRANSIENT_MESH: Contains errors related to the Service Infrastructure.
TYPE_TRANSIENT_MESSAGING: Contains errors related to JMS such as enqueue, dequeue.
TYPE_INTERNAL: Contains internal errors.
You can enable error handling for a Mediator by using the fault-policies.xml and fault-bindings.xml files.
To enable error handling for a Mediator:
Create a fault-policies.xml file based on the schema defined in the Section 20.4.1, "Schema Definition File for Fault-policies.xml".
Create a fault-bindings.xml file based on the schema defined in the Section 20.4.2, "Schema Definition File for Fault-bindings.xml".
Copy the fault-policies.xml and the fault-bindings.xml file to your SOA Composite project directory.
Deploy the SOA Composite project.
All the fault policies for a composite are loaded when the first error occurs. At runtime, Mediator checks whether there is any policy defined for the current error. If a fault policy is defined, then Mediator performs the action according to the configuration done in the fault policies file. If there is no fault policy defined, then the default action of human intervention is performed.
Apart from policy-based recovery using the fault policy file, you can also perform fault recovery actions on Mediator faults identified as recoverable in Oracle Enterprise Manager Fusion Middleware Control Console. This can be performed in the following ways:
Manual recovery by modifying the payload using Enterprise Manager
Bulk recovery without modifying the payload using Enterprise Manager
Aborting a faulted instance using Enterprise Manager, if the user does not want to do any more processing on the instance.
For more information about fault recovery using Enterprise Manager, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
This section describes the schema files for the fault-policies.xml and fault-bindings.xml files and consists of the following sections:
Section 20.4.1, "Schema Definition File for Fault-policies.xml"
Section 20.4.2, "Schema Definition File for Fault-bindings.xml"
The fault-policies.xml file should be based on the following XSD file:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<!-- Conditions contain a list of fault names -->
<xs:element name="Conditions">
<xs:complexType>
<xs:sequence>
<xs:element name="faultName" type="tns:faultNameType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- action Ref must exist in the same file -->
<xs:complexType name="actionRefType">
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<!-- one condition has a test and action, if test is missing, this is the
catch all condition -->
<xs:complexType name="conditionType">
<xs:all>
<xs:element name="test" type="tns:idType" minOccurs="0"/>
<xs:element name="action" type="tns:actionRefType"/>
</xs:all>
</xs:complexType>
<!-- One fault name match contains several conditions -->
<xs:complexType name="faultNameType">
<xs:sequence>
<xs:element name="condition" type="tns:conditionType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:QName"/>
</xs:complexType>
<xs:complexType name="ActionType">
<xs:choice>
<xs:element name="retry" type="tns:RetryType"/>
<xs:element ref="tns:rethrowFault"/>
<xs:element ref="tns:humanIntervention"/>
<xs:element ref="tns:abort"/>
<xs:element ref="tns:replayScope"/>
<xs:element name="javaAction" type="tns:JavaActionType">
<xs:key name="UniqueReturnValue">
<xs:selector xpath="tns:returnValue"/>
<xs:field xpath="@value"/>
</xs:key>
</xs:element>
</xs:choice>
<xs:attribute name="id" type="tns:idType" use="required"/>
</xs:complexType>
<xs:element name="Actions">
<xs:annotation>
<xs:documentation>Fault Recovery Actions</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="Action" type="tns:ActionType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="JavaActionType">
<xs:annotation>
<xs:documentation>This action invokes java code
provided</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="returnValue" type="tns:ReturnValueType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="className" type="tns:idType" use="required"/>
<xs:attribute name="defaultAction" type="tns:idType" use="required"/>
<xs:attribute name="propertySet" type="tns:idType"/>
</xs:complexType>
<xs:complexType name="RetryType">
<xs:annotation>
<xs:documentation>This action attempts retry of activity
execution</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element ref="tns:retryCount"/>
<xs:element ref="tns:retryInterval"/>
<xs:element ref="tns:exponentialBackoff" minOccurs="0"/>
<xs:element name="retryFailureAction"
type="tns:retryFailureActionType" minOccurs="0"/>
<xs:element name="retrySuccessAction"
type="tns:retrySuccessActionType" minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:simpleType name="idType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="ReturnValueType">
<xs:annotation>
<xs:documentation>Return value from java code can chain another action
using
return values</xs:documentation>
</xs:annotation>
<xs:attribute name="value" type="tns:idType" use="required"/>
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="exponentialBackoff">
<xs:annotation>
<xs:documentation>Setting this will cause retry attempts to use
exponentialBackoff algorithm</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="humanIntervention">
<xs:annotation>
<xs:documentation>This action causes the activity to
freeze</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="replayScope">
<xs:annotation>
<xs:documentation>This action replays the immediate enclosing
scope</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="rethrowFault">
<xs:annotation>
<xs:documentation>This action will rethrow the
fault</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="retryCount" type="xs:positiveInteger">
<xs:annotation>
<xs:documentation>This value is used to identify number of
retries</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="retryFailureActionType">
<xs:annotation>
<xs:documentation>This is the action to be chained if retry attempts
fail</xs:documentation>
</xs:annotation>
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="retrySuccessActionType">
<xs:annotation>
<xs:documentation>This is the action to be chained if retry attempts
is successful</xs:documentation>
</xs:annotation>
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="retryInterval" type="xs:unsignedLong">
<xs:annotation>
<xs:documentation>This is the delay in milliseconds of retry
attempts</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="abort">
<xs:annotation>
<xs:documentation>This action terminates the
process</xs:documentation>
</xs:annotation>
<xs:complexType/>
</xs:element>
<xs:element name="Properties">
<xs:annotation>
<xs:documentation>Properties that can be passes to a custom java
class</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="propertySet" type="tns:PropertySetType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="PropertySetType">
<xs:sequence>
<xs:element name="property" type="tns:PropertyValueType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="tns:idType" use="required"/>
</xs:complexType>
<xs:complexType name="PropertyValueType">
<xs:simpleContent>
<xs:extension base="tns:idType">
<xs:attribute name="name" type="tns:idType" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="faultPolicy">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:Conditions"/>
<xs:element ref="tns:Actions"/>
<xs:element ref="tns:Properties" minOccurs="0"/>
<!--Every policy has on Conditions and and one Actions, however,
Properties is optional -->
</xs:sequence>
<xs:attribute name="id" type="tns:idType" use="required"/>
<xs:attribute name="version" type="xs:string" default="2.0.1"/>
</xs:complexType>
<xs:key name="UniqueActionId">
<xs:selector xpath="tns:Actions/tns:Action"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:key name="UniquePropertySetId">
<xs:selector xpath="tns:Properties/tns:property_set"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:keyref name="RetryActionRef" refer="tns:UniqueActionId">
<xs:selector xpath="tns:Actions/tns:Action/tns:retry/tns:retryFailureAction"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="RetrySuccessActionRef" refer="tns:UniqueActionId">
<xs:selector
xpath="tns:Actions/tns:Action/tns:retry/tns:retrySuccessAction"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="JavaActionRef" refer="tns:UniqueActionId">
<xs:selector
xpath="tns:Actions/tns:Action/tns:javaAction/tns:returnValue"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="ConditionActionRef" refer="tns:UniqueActionId">
<xs:selector
xpath="tns:Conditions/tns:faultName/tns:condition/tns:action"/>
<xs:field xpath="@ref"/>
</xs:keyref>
<xs:keyref name="JavaDefaultActionRef" refer="tns:UniqueActionId">
<xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/>
<xs:field xpath="@defaultAction"/>
</xs:keyref>
<xs:keyref name="JavaPropertySetRef" refer="tns:UniquePropertySetId">
<xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/>
<xs:field xpath="@property_set"/>
</xs:keyref>
</xs:element>
<xs:element name="faultPolicies">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:faultPolicy" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
The fault-bindings.xml file should be based on the following XSD file:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="faultPolicyBindings">
<xs:annotation>
<xs:documentation>Bindings to a specific fault policy
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="composite" type="tns:compositeType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="component" type="tns:componentType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="reference" type="tns:referenceType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="2.0.1"/>
</xs:complexType>
<xs:key name="UniquePartnerLinkName">
<xs:selector xpath="tns:reference/tns:name"/>
<xs:field xpath="."/>
</xs:key>
<xs:key name="UniquePortType">
<xs:selector xpath="tns:reference/tns:portType"/>
<xs:field xpath="."/>
</xs:key>
<xs:key name="UniquePolicyName">
<xs:selector xpath="tns:reference"/>
<xs:field xpath="@faultPolicy"/>
</xs:key>
</xs:element>
<xs:simpleType name="nameType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="propertyType">
<xs:simpleContent>
<xs:extension base="tns:nameType">
<xs:attribute name="name" type="xs:string" use="required"
fixed="faultPolicy"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="referenceType">
<xs:annotation>
<xs:documentation>Bindings for a partner link. Overrides composite
level binding.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:annotation>
<xs:documentation>Specification at partner link name overrides
specification for a port type</xs:documentation>
</xs:annotation>
<xs:element name="name" type="tns:nameType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="portType" type="xs:QName" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
</xs:complexType>
<xs:complexType name="componentType">
<xs:annotation>
<xs:documentation>Binding for a component </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="name" type="tns:nameType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
</xs:complexType>
<xs:complexType name="compositeType">
<xs:annotation>
<xs:documentation>Binding for the entire composite</xs:documentation>
</xs:annotation>
<xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
</xs:complexType>
</xs:schema>