Agile decision services without XML details

Externalizing enterprise decision management using service-oriented architecture orchestrated by business process management makes increases agility and allows continuous performance improvement, but…

How do you implement the rules of EDM in an SOA decision service? 

• Do you worry about how requests are expressed in XML?
• Do you write rules that match against the structure of a document object model (DOM)?
• Do you write patterns against paths within the nested structure of XML documents using XPATH?

Not very agile, right?  Not very accessible to non-technical users, right?

Personally, I do not worry about XML or write rules at the level of document structure or using XPATH.  I prefer to write rules at a conceptual level that is above the level of data encoding or data structure.  In fact, I want my rules to be as independent of the XML schema definition (XSD) as possible.  I want my rules to work if I switch to another implementation that gets its data from an SQL database or a Java or .NET object model in the middle tier.  Why should my rules depend on any particular data model?

In other words, rules should be written on a semantic foundation.  The semantic foundation lies above the details of a data model and any technical syntax used to access it.

Here how to do it:

1. Take your data model and figure out what it means.
2. In the case of an XSD, take an element nested within another and figure out how they are related – semantically.
3. Once you understand the relationship between two elements in the XSD, write down what it means (i.e., its semantics) so that someone who is unfamiliar with XML would understand it.

For example, in ACORD, the code shown below represents, among other things, that:

• A business owner policy (BOP) is a commercial policy.
• A business owner policy must identify at least one insured (who may be a principal).
• A business owner policy may involve one or more producers (i.e., agents)
• A business owner policy covers at least one location.
• A business owner policy has a primary line of business (LOB).
• A request to update a policy may have attached files.
• A request may have remarks.

Consider writing rules that use these phrases versus XPATH code.

• If an insured under a BOP…
• If the primary LOB of a BOP…
• If a PDF is attached to a request to update a commercial policy…

Such expression of rules allows governance of an insurance practice to be much more agile.  If XPATH rules are required there will clearly be a expensive, length, waterfall process to implement any new policies.  And if the policies are captured and maintained at a level above the data model, they can be reused across internal systems (that may not use ACORD) and external systems that integrate with agent management systems or exchanges.  If rules are written in terms of XML, they will not be portable to other services that use different web service definition language (WSDL) or that use a relational database (i.e., SQL) or object-oriented models (e.g., Java or .NET).

To conclude, we recommend that you define an ontology that is independent of your data model and that you use that ontology in capturing and managing your business logic.

The alternative is to write rules that use XPATH to match against XML documents that conform to the following, for example:

   <xsd:complexType name="BOPPolicyAddRq_Type">
      <xsd:sequence>
         <xsd:group ref="MSGRQINFO" minOccurs="1" maxOccurs="1"/>
         <xsd:element ref="Producer" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element ref="InsuredOrPrincipal" minOccurs="1" maxOccurs="unbounded"/>
         <xsd:element ref="CommlPolicy" minOccurs="1" maxOccurs="1"/>
         <xsd:element ref="Location" minOccurs="1" maxOccurs="unbounded"/>
         <xsd:element ref="BOPLineBusiness" minOccurs="1" maxOccurs="1"/>
         <xsd:element ref="CommlSubLocation" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element ref="FileAttachmentInfo" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element ref="RemarkText" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>

Such business rules will obviously be limited to a very technical user community.

In other words:

1. business agility will remain limited,
2. stakeholders will remain at more than arm’s length, and
3. governance, risk and compliance (GRC) policies will not be reused across silos.

To realize these benefits with existing rule engines or business rules management systems (BRMS), look for the following:

1. Support for building an ontology that maps into an XSD.
2. Support for asserting XML that conforms to an XSD into the rules engine at runtime.
3. Support for rules that reference ontologies grounded in an XSD to apply without needed to understand the structure or content of the XML document.

The essence of these requirements is that a BRMS should deliver its end user authoring metaphors not just for Java or .NET object but also for XSD and WSDL specifications. 

I am not aware of any tools that do this for JESS, CLIPS, or Drools / JBOSS Rules, however.  There are some approaches in the logic programming community.  For example, XSB has some support for matching against XML, but it takes the XPATH approach by asserting the tree structured data that corresponds to an XML document and leaving up to the rule author to write rules that traverse the data structure.  Other Prologs take similar approaches.  Some assert objects that correspond to the document object model (i.e., “the DOM”, which is the tree structure of the XML). 

• Any approach that emphasizes XPATH or DOM may not go far enough to accomplish core enterprise objectives concerning policy management.

Although there may be other approaches, my favorite means of eliminating data model concerns from policy capture and management is to transform the data level up to the semantic level.  Ideally, the tool you select will do this for you.  That is, if your tool generates the XPATH or DOM rules that turn asserted XML into the semantic model that supports your ontology, your GRC policies will be independent of the implementation.

 If your tool doesn’t do this, I would recommend that your technical team does it manually.  The return on investment will be high versus any alternative approach.  I promise.