Climbing the Stack: Full SOA Participation

Using iRules and business rules to create a dynamic application-layer routing infrastructure that fully participates in your SOA

You may recall that we've previously examined how to implement the SOA Router Pattern using iRules. We've also discussed the implementation of business rules via iRules. But we haven't discussed how to pair the two and raise the participation of the application delivery controller in a SOA environment from bystander to first-class citizen.

The Concept

One of the hurdles application delivery controllers like BIG-IP Local Traffic Manager face is the ability to climb the OSI stack and participate in SOA interactions rather than simply directing traffic. While the router pattern is certainly a compelling case for the ADC's ability to participate at a higher level in SOA interactions, perhaps more interesting is the capability to interact with decision making components of a SOA, such as a business rules engine (BRE), and dynamically route messages based on that interaction.

Basically, you're abstracting business rules to some kind of service (a BRE, a POJO, etc...) that can be queried by an iRule.

How It Works

The basic requirement is that there exists a Rule Service, either implemented as part of a BRE or some other system, that provides a mechanism through which an iRule can invoke the service and receive some kind of information that is then used to determine where to next route the traffic.

  1. The Process
  2. 1. The client sends a request.
  3. 2. Using an iRule, BIG-IP extracts the appropriate data necessary to formulate the query to the Rule Service and executes the query. This could be a SOAP request, a REST-based query, or some proprietary application format via a number of transport protocols, but most likey to be HTTP.
  4. 3. Using the response returned from the Rule Service, the BIG-IP directs the original request to the appropriate node in a pool of servers.
  5. 4. The response is returned to the client.

[diagram links to larger version of image]

Step #2 is really where all the magic happens, and is technically just an extension of the original scenario in which BIG-IP acts as a BRE. Rather than an iRule implementing the business logic that determines whether a loan request goes to a manual or automated process server, the Rule Service makes the decision, but leaves the actual act of routing up to the BIG-IP via an iRule's interpretation of the Rule Service's response.

The Value

While BREs are often discussed as a part of a Business Process Management (BPM) solution, those deployed within a BPM and without are generally services based, meaning that they can be invoked from outside the BPM or other orchestrated processes. The primary purpose of abstracting business rules and managing them via a BRE rather than in code is to offer the business stakeholders - those who understand the business rules best - to implement those rules in a loosely coupled fashion. This loose coupling has the additional advantages of providing the means to dynamically modify the rules at run-time without requiring the intervention of application developers. This enables the agility and reuse promised by SOA.

The ADC adds value by interacting as a first-class citizen of the SOA environment, becoming part of the process rather than simply the means to an end (i.e. the delivery of the process). While an iRule could implement the business rule, modifications to that rule require intervention by administrators. While it's typically more cost and time efficient to implement these rules in an iRule rather than in code, it still requires additional time to implement, test, and deploy the modifications. By extracting the rule into a BRE and writing a reusable, dynamic iRule that interacts and participates in the process, the agility of the application, the rule, the infrastructure, and the overall organization is further enhanced, allowing the business to react in near-time to volatile market conditions and changing requirements while reducing the overhead and time associated with modifying tightly-coupled policies or code.

Imbibing: Coffee

Published May 14, 2007
Version 1.0

Was this article helpful?

No CommentsBe the first to comment