WSJ readers are already familiar with the concept and promise of Web services. For some time, media and industry analysts have been touting the revolution about to occur in the programming world as a result of universally accessible, reusable code that can be assembled to accomplish any business task.

Some of the claims are rightly looked on as hype, but there's an underlying solidity to the Web services model that makes it a compelling approach to software development. This article examines the interplay between Web services and a similar programming paradigm: business-rules management. There are many overlaps between business-rules management and Web services, but the former has been successfully implemented in far more real-world business applications. A look at the one may give enterprise developers a better idea of how to best work with the other.

Web Services
At their most fundamental level, Web services are merely programming "subroutines" that happen to be made available over the Internet. They are self-contained coding fragments that accomplish specific, well-defined tasks given a set of data to work upon. As a component business function, they do not mandate a visual interface or other I/O mechanism to communicate the results of their computations. That's left to the control of the calling application.

Of course, Web services offer a number of advantages over traditional callable code blocks. They are location independent - the code need not be physically owned, stored, or maintained by the using entity; they have a standardized access protocol; and they can be updated and repaired without affecting other parts of the application.

In their ideal realization, Web services provide a way of exposing business assets that empowers business users to specify complex business functionality in a clear, building-block fashion that can be quickly implemented and just as quickly modified.

Business Rules
Business-rules management has many of the same goals, barring the obvious aspects of Web-based availability. It's used to separate business decision processes from the mechanics of application I/O and control code. Rule services represent well-defined action determination tasks that can be called upon from many different applications. Business rules can be maintained and updated separately from the remainder of the program code. And they offer greatly improved visibility and comprehension to nontechnical business policy makers who wish to define and control business operations without worrying about programming syntax.

From an enterprise usability standpoint, business rules are best viewed not in their individual, atomic format, but as groupings intended to solve a particular decision task. Although the creation of rule services involves defining unique rules one at a time, a look at a single rule is fairly uninteresting from a business functionality outlook. One rule might validate a particular data value. Another might modify a discount rate based on a piece of customer demographic data. And a third might determine whether a product is appropriate for display in a selection list. Although each of these is an important low-level decision, none gives a sense of the overall business goal. One might refer to the rules as the "how" rather than the "what" of a business function. The "what" of a business decision process is a much more general description... "determine whether to underwrite a loan for this customer" or "respond appropriately to this employee's service request."

Business-rules management systems typically offer ways to group rules into functional blocks that accomplish a subtask. The subtasks can be combined in a procedural decision flow to conditionally use the proper subtasks in sequence to achieve the desired business decision. The overall decision flow can be viewed as a holistic rule service that is self-contained and can be accessed from any calling application when needed.

 

Business Rules and Web Services
In this view of rule services, it becomes clear that they are naturally suited for access using the Web services paradigm. A well-formed rule service has a clear calling point, is able to operate without further intermediary control from the calling application, and satisfies a clearly defined business function. All that's required is a way to publish the rule service using a Web services UDDI framework. The more advanced rules management software products come with automated generators to wrap rule services in the proper code constructs to enable them as Web services on the major Java application servers, ready to be published in a desired directory.

Individual rules are structured as a pairing of an explicit condition set (or rule premise) and a desired action. The most common way of thinking of this structure is the traditional IF-THEN programming construct: If a given condition is encountered, then perform the corresponding action. Naturally, rules may need to access data sources in the course of the execution. It would be inefficient and extremely difficult to pass every possible data point as an argument to the rule service on the off chance that a rule might need to examine it. So rules need on-the-fly access to external data sources as determined at run time. For instance, we might write the following rule: If Customer's Age is between 13 and 17 then set Customer's AgeGroup to TEENAGER.

The age of the customer could be looked up in a customer profile database, it could be read from an XML document, or it might be in memory as part of a Java object based on a recent transaction. Similarly, the AgeGroup value might be updated in a database or other data object as a result of executing the rule.

A more interesting situation is the case in which a rule's premise or action doesn't rely on a single property, but involves a complex function: If <Calculate Customer's Credit Rating> is greater than 1500 then <Issue Gold Card>.

The two phrases in angle brackets represent entire self-contained processes that the rule needs to initiate. These are natural candidates for Web services, since their tasks may not be carried out by the company determining that they're needed. They could be written and hosted by another party and accessed for a fee or through a licensing arrangement. A good rules-management solution plans for this type of access and allows direct access to Web services from within individual rules.

The previous two examples showed how Web services and business rules naturally work together to add value and power to component-oriented business processing. There is a third way that rules can support existing Web services, through authentication and authorization.

Security
Security of Web service processing is a major concern in making it practical for widespread use. Various companies, organizations, and standards committees are working on constructs for encryption/decryption, message confirmation, and user logon identification. Microsoft's .NET Passport and Sun's Liberty Alliance are two examples of single sign-on (SSO) frameworks that give companies "hooks" for tying their proprietary authorization strategies and policies to the external user information needed to make access decisions.

The mechanics to enable authorization and authentication are a major part of the solution. But even with these underlying building blocks in place, companies are still burdened with the task of clearly and consistently defining their rules for granting, refusing, and restricting use of systems and services. These rules are subject to change as user classifications are modified, new services are made available, and corporate policies change. A business-rules component that works with the security interfaces offers the capabilities needed in this area and allows companies to assert control over their Web services use.

UDDI
A final area of interface between Web services and business rules is UDDI (Universal Description, Discovery, and Integration). UDDI provides a means for describing published services, discovering businesses and business functions available to the caller, and integrating published services into calling applications. As with the security features mentioned above, UDDI addresses the technical infrastructure necessary to accomplish these tasks, but leaves their practical implementation "as an exercise for the reader." If Web services are to become a widespread shared service component and a potential revenue generator for publishers, enterprises will need a way to define rules for directory searches based on business-function descriptions, preferred partners, costs, and other factors that will be highly variant from company to company. The use of business-rules software will enable organizations to define and modify search and discovery criteria as needed.

What Lies Ahead
Web services are just beginning to move from an interesting theoretical model to a practical solution for companies. The first uses of Web services are likely to be intracompany, as an internal means for writing and accessing reusable business functions. Keeping Web services off publicly accessible Internet directories reduces security and discovery issues. In this limited-use scenario, Web services share many of the characteristics of business-rule systems. Each represents a self-contained business goal made up of subtasks that can be executed without intervention from the calling application. Business-rule services therefore make excellent candidates for Web services and have the advantage of being a tried and tested means of building component-oriented applications. Business rules are also ideally suited for making use of Web services to initiate complex conditions or action processes.

As companies progress to more aggressive use of public Web services shared between organizations, business rules will assist in defining and maintaining security of the shared services while offering a standardized means of searching and discovering applicable Web services based on proprietary criteria.

Companies interested in Web services can benefit from examining business-rules management as a technology to help them organize their new development work in a proven manner, while offering ways to control and manage expanded services in the future.

• Figure 1