The December issue of the Web Services Journal has an article by Henry Bowers on "Building Business Rules in Web Services Applications." What caught my attention was the ability to do something like this incrementally in the same way I advocate doing incremental transitions to web services for data in my paper on Enabling Web Services. At one point, Henry says:
[Another] approach is to separate business rules from the business logic. Depending on the construction of the applications, this can be fairly easy. For example, the 400 pages of if/else statements mentioned earlier are located in a handful of functions. These routines can easily be wrapped up as a Web service. This service is sent the same parameters with which the original functions were called and returns the same values after executing the rules. ...
The first advantage is that other applications can now make use of the same rules. Suppose, for example, that a mortgage insurance company wants to establish what proportion of its loan portfolio is at risk. It might obtain updated information on its customers and run the data through the qualification engine to see who would be rejected or assigned a lower credit score. To do this analysis, the company needs to access the business rules without dealing with the other processing of a loan application. It is not interested in receiving text streams for loan documents; it wants only the results generated by pushing data through the qualification rules.
Web services provide a unique opportunity to implement this kind of reusability by carving out sets of rules into callable services. In addition, they encourage the conversion of many standalone data formats into XML, which has the benefit of simplifying overall application integration (at the cost of performance, which in high-volume settings is far from negligible).
Sites that choose this path are often surprised at how quickly benefits become apparent. The separation of rules processing as Web services can be implemented progressively. Complete conversions of applications are unnecessary. Also, once rules are segregated as Web services, new opportunities for their use appear quickly. For example, business analysts can much more easily perform what-if scenarios by rolling hypothetical data through the rules.
This is exactly the right approach. As you can, incrementally expose web APIs (internally or externally, as appropriate). The marginal cost isn't that great and the more APIs you expose the greater the potential interoperability. Small, scripted aggregations lead to serendipidous applications: Jon Udell's LibraryLocator bookmarklet is a perfect example of the kind of interesting things that can happen with just a few scripts when APIs are exposed, documented, and reachable.
