Validation

[r1c]

Hi,

I'm just trying to get up to speed with JBossESB and have been looking to see what is provided out of the box regarding message validation.

I was hoping to find something like a schema validation action that could be configured but am unable to find anything.

Can anyone point me in the right direction or provide some insight into how you are doing message validation.

Thanks in advance,

Ric

[ryanhos]

Ric,

I don't believe that there is a canned xml validation action in the standard distribution. I suspect that many individuals are taking advantage of the implicit validation performed via the various xml-to-pojo mapping frameworks.

If you end up writing a validation action, I'm sure the project would gratefully accept it as a donation if your circumstances permit you to do so. I've written several EIP-inspired routers and actions, but my employer has yet to give me the go-ahead to donate them. JBoss ESB has promise, but needs quite a few additional standard features to be really useful out of the box.

[beve]

Hi Ric,

I've added a Jira for this: https://jira.jboss.org/jira/browse/JBESB-2213. This has been committed to the main svn trunk:
Action: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/src/org/jboss/soa/esb/actions/validation/SchemaValidationAction.java
Test: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/tests/src/org/jboss/soa/esb/actions/validation/SchemaValidationActionUnitTest.java

There is a quickstart named schema_validation that demos the action:
http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/samples/quickstarts/schema_validation/

If you are not in a position to build from the trunk you could simple copy the action and use in your project until the next release comes out.
Let us know if you have any additional requirement for such this action.

Regards,

/Daniel

[r1c]

Hi,

Thank you both for your responses and Daniel that's pretty impressive efficiency.

Currently I am evaluating JBossESB for a customer and have some other work to do so I'll have a look at the action later. For now I think the requirement is simply to validate a message against a schema so what you have commited should tick that box.

I do have other questions but I'll start a fresh thread as soon as I get a chance.

Thanks again.

Ric

[kconner]

It is not necessary to add such an action to the ESB as there is already support for validation. Why does the current code not work for you??

[r1c]

Hi Kevin,

It's not that the current code does not work for me, I am currently evaluating the ESB and was looking for something that does validation.

I couldn't see anything obvious in the docs for specifying a schema to validate messages so posted asking for advice.

Can you provide an example of how the current release supports this?

Thanks,

Ric

[kconner]

The current codebase includes the capability of exposing a service through a webservice and, as part of this, introduced the ability to validate the schema. This has been enhanced slightly by the work for https://jira.jboss.org/jira/browse/JBESB-1984

The base code is already in the trunk and will be released as part of ESB 4.5, the work having been done for the SOA platform 4.3 release.

The additional modifications have not been ported across to trunk as of yet as we need to develop a mechanism for handling the evolution of the schema. Once this is complete we will move the rest across to trunk and will also release them as part of ESB 4.5.

The original work was handled by Jim Ma and moved across to the platform branch by myself as part of https://jira.jboss.org/jira/browse/JBESB-1653

(next posting for details)

[tfennelly]

So if the message was (for example) delivered via the file router, can this be used to validate the message? Support for multiple schemas?

[kconner]

Now for the specifics.

There is a quickstart within trunk that demonstrates the use of the webservice feature, as can be seen from the following configuration.

http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/samples/quickstarts/publish_as_webservice/jboss-esb.xml

This configuration specifies the schema for the request, response and for user defined faults.

The validation is enabled by setting the 'validate' attribute on the 'actions' element to true. This will force the pipeline to validate the incoming request and outgoing response against the specified schemas.

The platform branch also contains a unit test for testing the validation and the enhancements covered by JBESB-1984.

The configuration for the test is http://anonsvn.jboss.org/repos/labs/labs/jbossesb/branches/JBESB_4_4_GA_CP/qa/junit/resources/server/ebws/META-INF/jboss-esb.xml and this will be included in the ESB 4.5 work.

[r1c]

As I understand what you are saying is that there will be schema validation for services exposed as webservices in the next release of the ESB.

I am looking for the ability to receive a plain XML payload over HTTP - no SOAP - and validate the XML against a configured schema. I guess this scenario is not covered by ESB using the features you describe.

[kconner]

The current trunk would therefore support something like the following

<actions inXsd="/request.xsd" outXsd="/response.xsd" faultXsd="/fault.xsd" validate="true">
 <action ... />
 <action ... />
</actions>

[kconner]

"r1c" wrote:
As I understand what you are saying is that there will be schema validation for services exposed as webservices in the next release of the ESB.

The service does not need to be exposed over webservices for validation to be used.

"r1c" wrote:
I am looking for the ability to receive a plain XML payload over HTTP - no SOAP - and validate the XML against a configured schema. I guess this scenario is not covered by ESB using the features you describe.

Yes, this scenario can be supported by the code in the current platform release and ESB trunk.

[kconner]

"tfennelly" wrote:
So if the message was (for example) delivered via the file router, can this be used to validate the message?

In the sense that any router forwards to a subsequent service and that service would then be responsible for validation, yes.

"tfennelly" wrote:
Support for multiple schemas?

It only allows you to specify a single request schema, if that is what you are asking The schema is supposed to represent the contract of the service so the service is free to define alternatives within that schema if necessary.

If, however, you are asking whether a single service can support multiple, distinct, contracts then this is not possible with the current code. You would need to have the distinct contracts handled by distinct services.

[r1c]

I apologise up front if I have missed something really obvious in the documentation.

The current trunk would therefore support something like the following

<actions inXsd="/request.xsd" outXsd="/response.xsd" faultXsd="/fault.xsd" validate="true">
 <action ... />
 <action ... />
</actions>

So schema validation can be applied to the action processing chain of any service in the ESB

Yes, this scenario can be supported by the code in the current platform release and ESB trunk.

Is this in release or trunk?

Where is this documented and is the validation performed around each action in the chain?

[kconner]

"r1c" wrote:
I apologise up front if I have missed something really obvious in the documentation.

There is no reason to apologise for anything.

"r1c" wrote:
So schema validation can be applied to the action processing chain of any service in the ESB

That is correct, yes.

"r1c" wrote:
Is this in release or trunk?

It is not yet in a project release, ESB 4.5 will be the first project release to contain this code. This is available through the SOA platform however, as the work was originally driven through that release.

"r1c" wrote:
Where is this documented and is the validation performed around each action in the chain?

There should be documentation in the Programmer's Guide detailing our current work on service contracts.

The validation is specified at the service contract layer though, not around each action, as the actions are an integral part of the service and are free to make whatever changes they feel are necessary. It is when the response is returned to the caller that any response would be validated.