Here are a few thoughts on why business rule validation in middleware like the SOA Suite is still useful: 1. Centralized validation. Putting business rules in middleware allows them to be centrally defined and enforced for any service that uses that middleware, rather than requiring each service to implement the same validation logic. 2. Dynamic rules. Business rules may need to change over time as business needs evolve. Middleware rules can be updated without changing individual services. 3. Reusable validation. The same business rules may apply across multiple services. Defining them centrally avoids duplicating validation logic. 4. Standardized validation. Using a standard format like Schematron promotes consistency in how rules are defined and enforced.

1. Business Rules Validation
in the SOA Suite with
Schematron

2. PROGRAM
• XML, XSD, X-Path, XSLT
• XML (Business Rule) Validation
• Validation Gap: Schematron
• Examples
• Schematron in the SOA Suite
• Business Rules Case
• Discussion

3. XML
XML: eXtensible Markup Language
Store almost any kind of data in a structured form
that applications running on any platform can
easily import and process and is human
readable.
XML became the underlying standard for many
new Software standards:
• Web: XHTML, RSS, Atom, XMPP (chat), AJAX
• Web Services: WSDL, SOAP (Simple Object
Access Protocol)
• Documents: ODF (Open Document Format), MS
Office OOXML (docx), Apple iWork
• Etc., etc

4. XML EXAMPLE
<?xml version="1.0"?>
<dining-room>
<manufacturer>The WoodShop</manufacturer>
<table type="round" wood="maple">
<price>$199.99</price>
</table>
<chair wood="maple">
<quantity>6</quantity>
<price>$39.99</price>
</chair>
</dining-room>

5. XSD
XML Schema:
• Define structure of xml including data type of elements
and contstraints
• Schema is also in XML format
 So there is a XML schema that defines an XML
schema
• Can be seen as the “ERD” or “DB Design” for XML

6. XSD EXAMPLE
<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://amis.nl/schematrondemo/common"
targetNamespace="http://amis.nl/schematrondemo/common"
elementFormDefault="qualified">
<xsd:element name="Employees" type="tEmployees"/>
<xsd:complexType name="tEmployees">
<xsd:sequence>
<xsd:element name="Employee" type="tEmployee"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tEmployee">
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="Salary" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:long" use="required"/>
<xsd:attribute name="manager_id" type="xsd:long" use="optional"/>
</xsd:complexType>
</xsd:schema>

7. XPATH
XML Path Language (XPath):
• Is primarily used to address the nodes of an
XML document modeled as a tree of nodes
• Is named after its use of a path notation for
navigating through the hierarchical structure
of an XML document
• Uses a compact, non-XML syntax to form
expressions for use in Uniform Resource
Identifier (URI) and XML attribute values
• Fully supports XML Namespaces
• Is designed to be used by XML applications
and XSLT (and XQuery)

8. XPATH EXAMPLES
//price  2 element nodes
/*/*/@wood  2 attribute nodes
//@wood/..  2 nodes (table and chair)
/dining-room/*[price > 100]/@wood  1 attribute node
//price[1]/text()  2 text values! (both price are first)
(//price)[1]/text()  1 text value (first from result collection)

9. XML STYLESHEET (XSLT/XSL)
XSLT processing takes an XML source document and an
XSLT stylesheet, and produces an output document
The XSLT stylesheet:
• Is an XML document itself
• Contains rules that map patterns in the input to
static XML to send into the output
• Uses XPath expressions to get data from the XML
source
• Can contain XSLT logic (if, choose) and operators
(for-each) to process the XML source
The output document is typically another XML
document, but XSLT can be used to create other plain-
text documents as well.

10. XSLT EXAMPLE *

11. XML (BUSINESS RULE) VALIDATION
Three types of XML Validation
• On data / element itself:
Data type & Constraints
• XML Structure:
Element names & Child/Parent Constraints
• Between data elements:
Business Rules

12. XML (BUSINESS RULE) VALIDATION
Three types of XML Validation
• On data / element itself:
Data type & Constraints
 XSD
• XML Structure:
Element names & Child/Parent Constraints
 XSD partially! (no conditional)
• Between data elements:
Business Rules
 ??

13. SCHEMATRON
• Used for validating an XML Document
• Validation of Business Rules
• Validation of conditional structure
• Rules are defined in Schematron format which
is also XML
• Is built on XPath expressions
• Is an ISO/IEC Standard
• Basically is a double XSTL transformation

14. SCHEMATRON
Usage:
• Define your Business Rules in an XML
document in a fixed format and structure
(Schematron) with the usage of XPath
expressions
• Transform your Business Rules XML using the
Schematron XSLT to create your Business
Rules XSLT.
• Use your Business Rules XSLT to validate your
XML data (Transformation). Output are the
errors, so no output means the data is valid.

15. SCHEMATRON
• Double XSLT transformation:
• 1. Rules.xml with Schematron.xslt =>
Rules.xslt
• 2. Data.xml with Rules.xslt => Result

16. SCHEMATRON FILE
<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.ascc.net/xml/schematron">
<pattern name="patternName">
<rule context="x-path">
<assert test="x-path condition">Error message</assert>
<report test="x-path condition">Error message</report>
...
</rule>
</pattern>
<pattern name="patternName">
...
</schema>

17. SCHEMATRON EXAMPLE 1
<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.ascc.net/xml/schematron" >
<pattern name="Number of characters in an abbreviation">
<rule context="Afdeling">
<report test="string-length(@afk) &lt; 2">There are not enough
letters in the abbreviation</report>
<report test="string-length(@afk) > 3">There are too much
letters in the abbreviation</report>
</rule>
</pattern>
</schema>

18. SCHEMATRON EXAMPLE 2
<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.ascc.net/xml/schematron" >
<pattern name="Sum equals 100%.">
<rule context="Total">
<assert test="sum(//Percent) = 100">Sum percentage is not
100%.</assert>
</rule>
</pattern>
</schema>

19. SCHEMATRON IN THE SOA SUITE
• Default filename extension “sch”
• No report, so only assert tag!  not(report)
• Define namespace prefixes with uri tag:
<ns uri="http://amis.nl/schematrondemo/company" prefix="cmp" />
• Implemented in Mediator:
• „Feature‟: Generate HTTP error (e.g. return error with FireForget)

20. BUSINESS RULES CASE
Company HRM XML file company containing departments
containing employees:
• An employee may not be the manager of himself.
• All normal employees (so not a manager) must have a
manager.
• There is only one manager without a manager
(only one president).
• All employees should have less salary than any
manager
(manager = employee in department “Managers”).
• The relation manager and employee is a valid one, so
the manager of an employee must exist.

21. CASE EXAMPLE DATA
<Company><Department name="Ground Two" abbr="GR1">...</Department>
<Department name="Ground Two" abbr="GR2">
<Employees>
<Employee id="13" manager_id="20">
<Name>P. Pietersen</Name>
<Salary>1550</Salary>
</Employee>
<Employee id="14" manager_id="20">
<Name>S. Smit</Name>
<Salary>1600</Salary>
</Employee>
</Employees>
</Department>
<Department name="Managers" abbr="MAN">
<Employees>
<Employee id="15">
<Name>M.A. Nager</Name>
<Salary>1700</Salary>
</Employee>
<Employee id="20" manager_id="25">
<Name>L.E. Ader</Name>
<Salary>1600</Salary>

22. SCHEMATRON BUSINESS RULE
IMPLEMENTATION
An employee may not be the manager of himself.
<pattern name="Employee may not be the manager of himself">
<rule context="//com:Employee[@manager_id]">
<assert test="@manager_id != @id">Employee may not manage himself</assert>
</rule>
</pattern>

23. SCHEMATRON BUSINESS RULE
IMPLEMENTATION
All normal employees (so not a manager) must
have a manager.
<pattern name="All normal employees have a manager">
<rule context=
"//cmp:Company/cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">
<assert test="@manager_id">Employee must have a manager</assert>
</rule>
</pattern>

24. SCHEMATRON BUSINESS RULE
IMPLEMENTATION
There is only one manager without a manager
(only one president).
<pattern name="Only one manager without manager, mr president">
<rule context="//cmp:Company/cmp:Department[@name='Managers']/cmp:Employees">
<assert test="count(com:Employee[not(@manager_id)]) = 1">There should be
only one president</assert>
</rule>
</pattern>

25. SCHEMATRON BUSINESS RULE
IMPLEMENTATION
All employees should have less salary than any
manager
(manager = employee in department “Managers”).
<pattern name="Managers earn more than normal employees">
<rule
context="//cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">
<assert test="com:Salary &lt;
min(//cmp:Department[@name='Managers']/cmp:Employees/com:Employee/com:Salary)">
Employee earns too much</assert>
</rule>
</pattern>

26. SCHEMATRON BUSINESS RULE
IMPLEMENTATION
The relation manager and employee is a valid
one, so the manager of an employee must exist.
<pattern name="Manager does not exist">
<rule context="//com:Employee[@manager_id]">
<assert test=
"//cmp:Company/cmp:Department[@name='Managers']/cmp:Employees/com:Employee[@id=c
urrent()/@manager_id]">No valid manager</assert>
</rule>
</pattern>

27. TOTAL SCHEMATRON BUSINESS RULE
IMPLEMENTATION
<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.ascc.net/xml/schematron">
<ns uri="http://amis.nl/schematrondemo/company" prefix="cmp" />
<ns uri="http://amis.nl/schematrondemo/common" prefix="com" />
<pattern name="Managers earn more than normal employees">
<rule context= "//cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">
<assert test="com:Salary &lt;
min(//cmp:Department[@name='Managers']/cmp:Employees/com:Employee/com:Salary)">Employee
earns too much: <value-of select="com:Salary"/></assert>
</rule>
</pattern>
<pattern name="Employee may not be the manager of himself">
<rule context="//com:Employee[@manager_id]">
<assert test="@manager_id != @id">Employee may not manage himself</assert>
</rule>
</pattern>
<pattern name="All normal employees have a manager">
<rule context=
"//cmp:Company/cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">
<assert test="@manager_id">Employee must have a manager</assert>
</rule>
</pattern>
<pattern name="Only one manager without manager, the president">
<rule context="//cmp:Company/cmp:Department[@name='Managers']/cmp:Employees">
<assert test="count(com:Employee[not(@manager_id)]) = 1">There should be only one
president</assert>
...

28. DEMO

29. PERFORMANCE
When there are
1. a lot (hundreds) of Schematron rules and/or
2. your input data (payload) is huge
performance problems can arise.

30. PERFORMANCE
1. A lot (hundreds) of Schematron rules
This problem is the easiest to handle:
Split the Schematron file up in more files and
serialize them with Mediators.
Place the Schematron rules which fail most in the
first Mediator and the ones which fail least in the last
Mediator.

31. PERFORMANCE
2. Huge input data (payload)
This problem is quite tricky. Not only for Schematron
validation, but the SOA Suite in common!
Advise for Schematron validation is to split up the
payload (BPEL / OSB) in multiple chunks.
This can be a „vertical split‟, so divide at certain
elements.
But also an „horizontal‟ split, so ommit data which is
not necessary for the (chunk of) Schematron
validation rules.
Even a combination is possible!
With a split-join in the OSB or in BPEL with parallel
processing the output can be merged.

32. DISCUSSION
Statement:
“No Business Rules in the Middleware”