In his post entitled Business Rules, OCL, XML and Schemas Daniel Cazzulino writes

DonXML is proposing extensions to OCL to express business rules that can be used at code-gen time and at run-time. He mentions my Schematron implementation called Schematron.NET, which allows many business rules to be expressed simply in terms of standard XPath expressions. I believe such an XPath-based language is good enough to express almost every business rule.

Udi Dahan commented as an example, a rule "only a bank manager can authorize a loan above X" which he said couldn't be expressed with Don's idea. It could, indeed, with something along these lines (XPath-like):

<assert test="sec:principal-role('BankManager') and po:Loan/@Amount < 1000">
  Only a BankManager can place a loan of more than $1000.
</assert>

Using rules-based XML validation is a good way to augment the capabilities of the W3C XML Schema language which is traditionally used to describe message structures in SOAP-based XML Web Services. In the post on Daniel's blog Udi Dahan asks

I like the technique. I'm still puzzling over the strategy. From a SOA approach, where does this go ? What makes it different/better than any other rules engine ? You've given me something to think about. Thank you.

In an SOA approach the rules are part of the message contract. A service endpoint can accept certain kinds of messages that satisfy its message contract. Using a rule-based language like Schematron just makes for writing a tighter contract than one could write using a traditional XML schema language like XSD.

In fact, Aaron Skonnard wrote an article on MSDN entitled Extend the ASP.NET WebMethod Framework by Adding XML Schema Validation  that introduced this to some degree which he followed up with two episodes of MSDN TV; Validating Business Rules with XPath Assertions, Pt. 1 and Validating Business Rules with XPath Assertions, Pt. 2


 

Tuesday, 03 February 2004 18:25:57 (GMT Standard Time, UTC+00:00)
What I was actually talking about was more along the lines of enhancing the strongly typed datasets with the proposed use of OCL in the schema, so that when the XSD tool creates the classes for strongly typed datasets, in could also create business constraints within the strongly typed dataset, along with custom exceptions. This way we could write less code, and stay insync with the models.

DonXML Demsak
Tuesday, 03 February 2004 22:39:25 (GMT Standard Time, UTC+00:00)
I've thought about it some more and I've reached certain conclusions. Business rules should NOT be part of the message contract. I mean, if you toss messages that don't conform to the contract, you lose too much valuable information. OTOH, would you then accept messages that don't conform to the schema ? That would sort of defeat the purpose of the schema.

Security checks, business rules, auditing, etc all have to take place in the case when a message arrives containing a request. Should the message fail a rule, you'd want ( or need - depending on conformance requirements ) to audit exactly for what reason this happened.

Sure, you could wire up such a system to do this at the contract level, but conceptually and architecturally it doesn't belong there. Pretty much all you've done is move functionality from one place to another ( less suited one - IMO ).
Tuesday, 03 February 2004 23:26:32 (GMT Standard Time, UTC+00:00)
Udi,
That does raise the question of why bother having a schema at all. After all, the constraints specified in the schema are just a random mix of features that were arrived at by compromise by some W3C committee. Do uniqueness constraints belong in the schema or as part of business rules? How about specifying fixed or default values? Where is the line drawn?
Wednesday, 04 February 2004 01:21:07 (GMT Standard Time, UTC+00:00)
As I understand the concept of schema, the point is to say that "I can work with this message" - nothing more - that my minimum requirements have been met. I don't think business rules belong at the boundary for exactly this reason. It ties up the system itself - business rules, constraints, etc into the "messaging infrastructure".

Now, I'm not saying that using schema with all the fancy features couldn't be used to implement the business rules engine. It actually sounds quite interesting. The difference being that it will be internal to the system, even more so, internal to a service in the system - not on the system boundary.
Wednesday, 04 February 2004 01:21:24 (GMT Standard Time, UTC+00:00)
As I understand the concept of schema, the point is to say that "I can work with this message" - nothing more - that my minimum requirements have been met. I don't think business rules belong at the boundary for exactly this reason. It ties up the system itself - business rules, constraints, etc into the "messaging infrastructure".

Now, I'm not saying that using schema with all the fancy features couldn't be used to implement the business rules engine. It actually sounds quite interesting. The difference being that it will be internal to the system, even more so, internal to a service in the system - not on the system boundary.
Thursday, 05 February 2004 14:55:58 (GMT Standard Time, UTC+00:00)
I have a better technique now, which relies on policy. Check out http://skonnard.com/archive/2004/02/04/213.aspx.
Comments are closed.