<MyBook xmlns="example"> <Chapter1/> <Chapter2/> </MyBook>
Validation feature provides a functionality for message content validation.
Take the following message content:
<MyBook xmlns="example"> <Chapter1/> <Chapter2/> </MyBook>
And follwing XML Schema definition:
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="example"
xmlns:orders="example">
<element name="MyBook" type="example:MyBook"/>
<complexType name="MyBook">
<sequence>
<element name="Chapter1" type="string"/>
</sequence>
</complexType>
</schema>
The XML content is still Well-Formed, but it has a Chapter2 element that is not declared as the child of MyBook element in the XML Schema, So the content is not Valid against this XML Schema. We often need to perform this kind of validation before processing its data in service logic, but implementing the validation logic directly in the consumer or provider pollutes the service logic and can lead to tight coupling. SwitchYard allows for the validation logic to declared outside the service logic and injected into the mediation layer at runtime.
Validation of message content is specified in the descriptor of your SwitchYard application (switchyard.xml). The qualified name of the type being validated name is defined along with the validator implementation. This allows validation to be a declarative aspect of a SwitchYard application, as the runtime will automatically register and execute validators in the course of a message exchange.
<validates>
<validate.xml schemaType="XML_SCHEMA"
name="{urn:example}MyBook">
<schemaFiles><entry file="/xsd/orders.xsd"/></schemaFiles>
</validate.xml>
</validates>
Since validations occur with named type (i.e. type A) as well as transformations, it's important to understand how the type names are derived. Please refer to the Content Type Names section in the Transformation chapter if you have not ever seen it.
Switchyard currently offers support for the following validators