SOA: Responsibilities of Service Providers (Part 6)

Responsibility 5:  Implement business rules and edits to ensure the validity/integrity of the operation and any data that is mastered.

This blog post is one in a series.  An overview and general outline of this series is linked here.

Background

Okay so you might think this responsibility is an obvious one.  It is.  But it shouldn't be overlooked.  A service that does not implement the complete set of edits breeds unexpected results, complexity, and other issues.  Interfacing apps and end-users dependent upon accessing resulting data later (and even using a downstream enterprise data warehouse) are left holding the proverbial bag.

Considerations

There are a number of methods to implement edits and rules.  The nature of the service will drive the technical approach.  Here are a few examples:
  1. Service uses XML Schema Validation to ensure a valid request has been submitted.  Much easier than writing code!!  See best practices below.
  2. Edits and rules implemented within code.  Typically this is useful for things that cannot be expressed via XML Schema.  The unit of work doesn't commit unless all edits and rules pass successfully as part of processing the request.
  3. As part of processing a request, a rules engine is invoked (either across the network as a chained service call or local to the service) to ensure validity.  Only insert a rules engine when it makes sense to do so.
  4. After a service is invoked, the underlying business process requires human action before a "logical unit of work" is complete.  This is best addressed with a human workflow engine to route requests for review and action.  On subsequent queries, a best practice is for the service to indicate the workflow status for any in-flight requests.
Often a service will leverage one or more of these strategies.  For instance, it is common to use both 1 and 2 together.

As a best practice, XML oriented services should leverage the richness of XML Schema to describe what constitutes a valid request and response. Examples of items that can be enforced include:
  • One to many relationships
  • Required vs. optional values
  • Dependent values (if X exists, Y and Z are required also)
  • Enumerated list of valid values for attributes/elements
  • Types and patterns.  Minimum and maximum lengths

With both SOAP (within WSDL) and REST, XML Schema is the mechanism to outline an interface contract to all clients.  A rich contract also enables a client to generate rich language specific bindings.  This provides an object based representation to easily construct requests and parse responses to/from the service.

Quite often I encounter opportunities to strengthen the XML Schema definition to increase the effectiveness of an interface contract.  In my view, managing a service's interface definition is a critical activity.  On the surface this seems like a mundane task; however, when done properly the benefits are quite visible.  This is especially the case when a robust interface versioning strategy is utilized to seize decoupling opportunities.