Comparing NRL

NRL is designed to be a core component in a successful Enterprise Integration Architecture, or Service Oriented Architecture (SOA). It is very unlikely that any large scale architecture can be built using only NRL, however it may partly replace components.

Here are some common languages and concepts that you may compare NRL to:

Service Orchestration

It is common to invoke NRL-generated artefacts from BPEL engines, queuing components or other BPM services, for example:

• To validate messages sent or received by service endpoints
• To perform sophisticated transformations between XML and other standards

NRL fits in well with these services as it provides a readable specification of the core transformation and validation rules that combine well with graphical flow representations.

Rule Engines

RETE rule engines are widely used in industry. They provide inferencing and rule chaining capabilities and are particularly suited to complex decision making based on a large number of input factors: credit card applications are a common example.

It is unfortunate that the term business rule has become overloaded: NRL does not solve the same problem as inferencing engines: they are not designed for validation or mapping (or broadly: data processing), and have implementation footprints sizable enough to make them useful only for very large projects.

Domain-Specific Languages

DSLs have the same goal as NRL: to give non-technical domain experts a higher-level language to express themselves in.

A DSL tends to be much more specialised than NRL: it is constructed for a particular purpose, in a particular domain (e.g. pricing complex financial instruments). As such, it can provide much more expressive power in its keywords.

NRL, by contrast, is non-domain specific. There is no language to design, and hence significantly less overhead. The language remains the same, a constraint and action language optimised for data processing tasks: the models you work with provide the domain information.

Schematron

Schematron is frequently used to express validation rules over XML. When combined with XPath 2, Schematron can express first-order predicate logic constraints.

NRL works on a higher level than Schematron, and requires no understanding of XML or XPath. This does mean that certain types of Schematron rules are not expressible in NRL:

• There is no sibling or ancestor navigation
• Technical details in XML, such as CDATA sections, or attributes vs elements are hidden from the NRL rule writer and cannot be distinguished

NRL makes these choices on purpose: business rules do not concern themselves with storage details. It does mean, however, that for low-level XML validation Schematron may be preferred.

OCL

The Object Constraint Language (OCL) is an OMG standard for constraining UML models. When NRL was first conceived, one of the early tasks was to replace OCL in a financial institution. Whereas OCL provides some more expressive power, it is difficult for non-technical users to review, let alone write.

NRL also provides an action language that has been proven in production projects.

Code

Our position is that it is not feasible to generate entire systems from high-level specifications. There will always be a place for hand-written, specialised code.

NRL replaces core parts in a well-defined architecture: validation, enrichment, mapping and, sometimes, routing. These parts can be generated, as they follow common patterns. They also happen to be the parts of the architecture where business logic gets buried.