{section}
{column}

h1. Features

The Validation Service-Engine allows to validate and filter Petals messages against an XML Schema.

\\
Each configuration of this component embeds an XML Schema (made up of one or several XSD files).
When such a configuration (i.e. service, i.e. service-unit) is called, it validates the received message against the XML Schema.
Depending on the called operation, the returned message is either a boolean (*validate* operation) or the received message or a fault (*filter* operation).
*filter* and *validate* are the only operations this component supports.

\\
This component only acts as service provider, not as a service consumer.
In fact, it provides a validation / filtering service (the filtering relies on the validity of the message against the XML Schema).


h1. Recommended usage

The Validation component may be used before calling a critical service.
It allows to make sure the message to send has the right shape.
For some services, this can be useless. For some others though, it can be critical to perform this check.

\\

{code:lang=java}
if( validationService.validate( MSG )) {
criticalService.criticalOperation( MSG );
}
else {
log( "The message was invalid." );
}
{code}

Following our previous algorithm, it appears that validating or filtering a message only makes sense if this message is going to be sent to another service.
That supposes that there is a chaining service, that will first call the validation service, and then call the real target service.

# Message from the chaining service to the validation / filtering service.
# Response from the validation / filtering service to the chaining service (the MEP is InOut, always, no matter what the operation is).
# Message from the chaining service to the real target service.
# Optional response, depending on the MEP for the second service.

\\
This chaining service can be implemented by a POJO (a Java service that runs in Petals) or an Enterprise Integration Pattern (EIP).

<!-- The target name space depends on the version of the Validation component -->
<tns:validateResponse xmlns:tns='http://petals.ow2.org/components/validation/version-1'>
<tns:valid>true</tns:valid>
</tns:validateResponse>

<!-- The target name space depends on the version of the Validation component -->

h3. The "filter" operation

*filter* filters the received message by validating it against the XML Schema embedded in the service-unit.
If the message is valid, then it is returned as the response.
Otherwise, a fault is raised.

{warning}


h2. Validation services and WSDL interfaces

By default, services deployed on the Validation component do not need a WSDL.
However, as a good practice, it is better to provide it one.

h2. Limitations

Configurations for this component cannot be used as a proxy to call other services.
Neither to validate attached, nor to intercept and validate messages on the fly.
Interceptors would better fit this kind of use case.

\\
The validated / filtered content is always the payload from the input message.


h1. Component configuration

The component can be configured through its JBI descriptor file, as shown below.

<name>petals-se-validation</name>

<petalsCDK:ignored-status>DONE_AND_ERROR_IGNORED</petalsCDK:ignored-status>
<petalsCDK:notifications>false</petalsCDK:notifications>
<petalsCDK:jbi-listener-class-name>org.ow2.petals.se.validation.listener.JBIListener</petalsCDK:jbi-listener-class-name>
</component>
</jbi>{code}


\\
The component configuration includes the configuration of the CDK. The following parameters correspond to the CDK configuration.
{include:0 CDK Component Configuration Table}

\\
This component does not have any specific configuration parameter.

\\
{warning}
The Petals-SE-Validation component can only handle messages coming from inside the bus. Therefore, you cannot specify an external-listener class-name.
{warning}


h1. Service Configuration

h2. Service Unit descriptor

The Service Unit descriptor file ( jbi.xml ) looks like this:
{code:lang=xml}<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jbi="http://java.sun.com/xml/ns/jbi"
xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
xmlns:validation="http://petals.ow2.org/components/validation/version-1"
xmlns:serviceNs="http://petals.ow2.org/simpletransformation">

<jbi:services binding-component="false">
<jbi:provides
interface-name="serviceNs:ValidationInterface"
service-name="serviceNs:ValidationService"
endpoint-name="ValidationEndpoint">

<!-- WSDL file -->
<petalsCDK:wsdl>your optional description wsdl file.wsdl</petalsCDK:wsdl>

<!-- Validation specific fields -->
<validation:schema>schema.xsd</validation:schema>
</jbi:provides>
</jbi:services>
</jbi:jbi>
{code}

\\
A JBI descriptor for an Validation service-unit can only define one _provides_ block.

\\
*Configuration of a Service Unit to expose an validation / filtering service into Petals ESB:*

|| Parameter || Description || Default || Required ||
| schema | Location of the XSD schema. This path must be a relative path from the root of the SU package. \\ | \- | Yes |

\\
{include:0 CDK SU Provide Configuration}
\\
{include:0 CDK Interceptor configuration for SU}


h2. Service Unit content

The service unit must contain the XML Schema and the JBI descriptor (jbi.xml file).
It is also highly recommended to provide a WSDL description for this service (though it is optional).
This WSDL is not mandatory, but not providing it will prevent your service from interacting with other Petals services and components.

\\
The directory structure of a SU for the Petals-SE-Validation looks like this:

{noformat}
su-xslt-TransformationName-provide.zip
+ META-INF
- jbi.xml
+ XsltService.wsdl (recommended)
+ myfile.xsd (required)
+ myfile2.xsd (required if myfile2.xsd is imported in myfile.xsd)
{noformat}
{column}

{column:width=350px}
{panel:title=Table of contents}{toc}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list}{panel}
{column}
{section}