<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.
There are two methods available for creating a Java-based validator in SwitchYard:
Implement the org.switchyard.validate.Validator interface and add a <validate.java> definition to your switchyard.xml.
Annotate one or more methods on your Java class with @Validator.
When using the @Validator annotation, the SwitchYard maven plugin will automatically generate the <validate.java> definition(s) for you and add them to the switchyard.xml packaged in your application.
@Named("MyValidatorBean")
public class MyValidator {
@Validator(name = "{urn:switchyard-quickstart-demo:orders:1.0}submitOrder")
public ValidationResult validate(Element from) {
// handle validation here
}
}
The above Java class would produce the <validate.java> definition as following:
<validate.java bean="MyValidatorBean"
name="{urn:switchyard-quickstart-demo:orders:1.0}submitOrder"/>
The optional name element of the @Validator annotation can be used to specify the qualified type name used during validator registration. If not supplied, the full class name of the method parameter will be used as the type.
The CDI bean name specified by @Named annotation is used to resolve validator class. If you don't specify, then class name of the validator is used instead like following:
<validates>
<validate.java class="org.switchyard.quickstarts.demos.orders.MyValidator"
name="{urn:switchyard-quickstart-demo:orders:1.0}submitOrder"/>
</transforms>
Note that both of above <validate.java> definition has a bean attribute or a class attribute. bean attribute and class attribute are mutually exclusive.
ValidationResult is a simple interface which represents the result of validation. It has 2 methods, isValid() and getDetail(). isValid() returns whether the validation succeeded or not. _getDetail() returns error message if validation failed.
package org.switchyard.validate;
public interface ValidationResult {
boolean isValid();
String getDetail();
}
There are 3 convenience methods on org.switchyard.validate.BaseValidator, validResult(), invalidResult(), and invalidResult(String) which help you to generate ValidationResult object.
The XML validator allows you to perform a validation against its schema definition. Supported schema types are DTD, XML_SCHEMA, and RELAX_NG. It is configured simply by specifying the schema Type, the name QName, and the path to the schema file.
<validate.xml schemaType="XML_SCHEMA" name="{urn:switchyard-quickstart:validate-xml:0.1.0}order" failOnWarning="true" namespaceAware="true">
<schemaFiles>
<entry file="/xsd/orders.xsd"/>
</schemaFiles>
<schemaCatalogs>
<entry file="/xsd/catalog.xml"/>
</schemaCatalogs>
</validate.xml>
If you specify failOnWarning attribute as true, then validation would fail if any warning is detected during validation. If the XML content to be validated has namespace prefix, then you need to specify namespaceAware as true.
You can use XML catalog to decouple the schema file location from schema definition itself. This schema is orders.xsd which has a import element. It refers to logical name orders.base by the schemaLocation attribute:
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:switchyard-quickstart:validate-xml:0.1.0"
xmlns:base="urn:switchyard-quickstart:validate-xml-base:0.1.0"
xmlns:orders="urn:switchyard-quickstart:validate-xml:0.1.0">
<import namespace="urn:switchyard-quickstart:validate-xml-base:0.1.0" schemaLocation="orders.base"/>
...
And this is the catalog.xml which resolves actual schema location from logical name orders.base:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<system systemId="orders.base" uri="orders-base.xsd"/>
</catalog>