Freigeben über


XMLValidatingReceive Pipeline Clarification

In my previous post on the default behaviour of the XMLReceive pipeline with respect to validating a message against a schema I detailed the creation of what I termed the "XMLValidatingReceive Pipeline".  In response to this posting, Payal Arya emailed me the following question with respect to this posting, which highlighted the need for more clarity around how the pipeline works:

"Your posting was very helpful, however I had one question that what's the use of XML Disassembler and Party Resolution in the Pipeline, when only XML validator solves the purpose."

After getting this question, and reading through my post again I clearly did not detail the reasoning for the use of these components, so here goes.

The reason why I kept the XML Disassembler and Party Resolution components in the pipeline is that I wanted the standard XML Receive pipeline to be enhanced with an automatic schema validation function.  This would then provide me with an enhanced, generic pipeline I would be able to use in any development that required schema validation.  This required that I keep the same functionality that the XMLReceive pipeline provided, and just extend its functionality: so that the XMLValidatingReceive pipeline effectively becomes an evolution of the XML Receive pipeline's generic functionality.

The alternative, if you wanted the simplest pipeline that would still do schema resolution and validation, would be to create a pipeline that just has the Xml Validator component in the pipeline.  As the Xml Validator component will automatically resolve the schema from the message's target namespace and root node name, it would be able to identify the schema associated with the received message, and then perform the validation as well.

By keeping the XML Disassembler component in the pipeline, however, the pipeline will still support any envelope and debatching processes embedded in the schema design, and the debatched messages would then be validated by the Xml Validator component. Similarly, by including the Party Resolution component, any party resolution logic that you may require in your solution is still supported. Obviously, if you do not require either of these functions in your solution and you do not want to incur the overhead of these additional components you could exclude these pipeline components, and your pipeline would still perform the validation function.