Two systems are communicating via XML messages on a message queue and any received message must be validated for structure, content and business logic before being processed.

An XML schema offers validation on structure and content with data type restriction, required fields, choice structures and the like.

But this of course only gets me half way there. In a system I am currently working on, we do the remaining validation by deserializing the message to an object structure and validating context with a dedicated code library.

The problem is that first of all the validation is in two different places and it overlaps a bit since some validation can be done in both ways, and secondly maintaining the validation code can become tedious.

Is there a better way to do this, any best practices or tools out there?

  • They are two seperate domains and should remain separate. The XML schema validation is in implementation domain and the content validation is from the business functional domain. Commented Oct 12, 2018 at 14:57

2 Answers 2


Data types and required fields in the schema define the structure of the XML document, and should in my opinion only validate that the document is in fact a "complete document of type X". If this first validation fails, an attempt to deserialize it could fail.

The second validation could be regarded application or even context specific, errors would mean "your valid document does not contain valid values for the application (at the moment)".

If you share that vision, the two validation steps would never have a functional overlap, perhaps just a technical one.


I would want to only have one point where I do my validation and that would be object serialisation and business validation. It does depend on the solution but the concern about having 2 similar pieces of logic in differences is obvious. The second concern is that using schema validation could make your integration more brittle and prone to failure in production / maintanence if you ever change the structure at all. If you are don't use the schema validation then the interface is less brittle and can accept objects that are valid from the business / domain perspective that may otherwise fail and require schema validation changes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.