Toggling Extra Validation in DIT/SIT But Not In PROD

Use a marker group to toggle extended request validation in SIT/DIT but not in PROD.

In DIT and SIT, it makes sense to validate every detail about the incoming request and the outbound response. Developers are making mistakes populating the data, outdated WSDLs are used, all kinds of things go wrong. The earlier the defects are found, the less expensive it’s to fix them.

Validation is a must.

In PROD though, assuming all our applications are internal and went through that rigorous DIT/SIT testing phase, running validation (especially XML schema validation) is an expensive process, needlessly consuming CPU cycles and memory.

The effect is especially devastating on pass-through proxies: where without validation the request is not even materialized, validation requires a DOM to be built and then values compared to the schema. While non-validated request may be delayed for less than 5ms in OSB, validated one may take hundreds(!) for large payload.

We need a simple way to trigger validation logic on and off depending on environment.

Bad: Code Change

Code change is simply not an option. The code deployed to PROD must be the same we tested in SIT, and in SIT it should have validation on.

Better: XQ Configuration File

Better option is a XQuery file that controls the validation: read a value from XQuery resource to decide if the validation should be performed:

ExtendedValidation.xq:

(: use 'Validate' in DIT/SIT/UAT, 'No' in SOAK/PROD :)
'Validate'

It is a workable solution, alright. In my experience though, operations and production support folks are not very happy to modify something they see as a part of the code.

Excellent: Marker Group

Recently a colleague of mine, Evan Zhang, offered a way better solution. He suggested to create a marker group that can be added (or not) to the user that calls OSB entry proxy.

Suppose we called this group ‘extraValidation’. Suppose also that our entry proxies are open for user ‘innerUser’.

In the code then we can do this check:

data($inbound/ctx:security/ctx:transportClient/ctx:principals/*) = 'extraValidation'

and if the result is true, we do extra validation.

We can then add the user ‘innerUser’ into group ‘extraValidation’ in DIT and SIT, and every request from this user will be thoroughly validated. In PROD though we do not add this user to the group, and validation is not performed.

Support people are happy too, because they are working with familiar objects (users and groups) instead of OSB resources.

Source-Based Validation

We may even do extra validation based on the source of the request!

Remember that we decided do no validation in PROD because all our internal applications are very well tested in DIT and SIT. But what if the same service is now exposed to partners outside of the organisation? We cannot be sure that the outside code passes the same rigorous testing process, and thus we must validate the incoming requests. If we blindly enable validation for the whole service, our internal requests will be validated too, wasting resources.

But if we assign outside clients a separate user (a good idea anyway) and then place that user into ‘extraValidation’ group, we get the best of both worlds: our internal requests will not be validated and will work at their fastest; while the requests coming from outside will be fully validated.