Lists Home |
Date Index |
It totally depends on your level of trust and competence along
with the legal dependences and requirements!
I have just implemented some prototypes for the US Government that
integrate validation into the messaging layer, coupled to partner profiles
that are stored in an ebXML Registry.
This allows trading partners to self-provision against the profiles and
rules they select for the types of interchanges they want to legally
agree to do. The goal is to provide automated collaborations where
partners can join with minimum manual intervention and start-up
Underneath it is all controlled by ebXML CPA profiles in the registry
and then linked to OASIS CAM templates that contain the business rules.
The Hermes messaging server inspects the inbound ebXML envelope
and matches the CPA id of the partner to the CPA instance in the
registry - checks that the service/action request is allowed for that
partner, and then performs the CAM template validations against the
actual message content. Any errors are directly generated by the
messaging layer and routed back to the sender. Successful
transactions are then passed off to the backend business application
for final consumption.
This was demonstrated as an OASIS Interop @ XML2004.
All the Java source code, documentation and PPT for this is
Roger L. Costello wrote:
> Hi Folks,
> Suppose that you have an application which exchanges XML instance
> documents (instance data) with trading partners. I'd like to get a
> feel for how people are addressing these issues:
> 1. Do you validate outgoing instance data? Do you validate incoming
> instance data?
> 2. What criteria do you use for deciding whether or not to do run-time
> Note: By "validate" I am referring to "XML validation", that is,
> validate an XML instance document against a schema (DTD, XML Schema,
> RelaxNG, of Schematron).
> Also note that I am talking about "run-time validation". That is,
> dynamic validation of XML instance data while a system is operational.
> RUN-TIME VALIDATION SPECTRUM
> There are two ends of the spectrum with respect to run-time validation:
> a. Never validate: neither outgoing nor incoming instance data is
> b. Always validate: every outgoing and incoming instance is validated.
> Let's consider each of these:
> NEVER VALIDATE
> Suppose that you and your trading partners have agreed to a schema.
> And suppose that you tune your application so that it flawlessly
> generates instance data conforming to the schema. In this scenario it
> seems reasonable to skip validating outgoing instance data. And if
> your trading partners have similarly tuned their applications then it
> seems reasonable to skip validating incoming instance data. (In other
> words, one-time static XML validation is good enough)
>>>> MOTIVATION: The motivation for skipping validation is to avoid the
> performance hit incurred by doing validation. In scenarios where
> there are a lot of instances being exchanged then avoiding validation
> could provide a substantial savings in processing.
> Question: Does anyone have performance statistics on validators?
> ALWAYS VALIDATE
> Suppose that you are receiving instance data from a variety of trading
> partners and some of them cannot be trusted to send you conforming
> data. In this scenario it seems reasonable to always validate
> incoming instance data. And if your application is assembling
> dynamically created data then it seems reasonable to always validate
> outgoing instance data.
>>>> MOTIVATION: The motivation for always validating is to prevent bad
> data from entering your application, and prevent your application from
> sending out bad data.
> Where does your company stand with respect to run-time validation:
> - Do you validate every outgoing instance?
> - Do you validate every incoming instance?
> - Do you validate only certain outgoing instances? What criteria
> do you use for determining which outgoing instances are validated?
> - Do you validate only some of the incoming instances? What
> criteria do you use for determining which incoming instances are