Introduction
Service Oriented Architecture (SOA) is an architecture paradigm that supports the creation of business services that incorporate common enterprise-worthy business behaviors that are expressed by a re-usable interface and are governed by policies.
Given that business services are not tied to the implementation but to common business semantics have enterprise-wide applicability; these business services are capable of being discovered by the end users as opposed to "finding" these services by having to drill through terse and complex Application Programming Interface(s) or APIs. In addition, having business definitions of services that are "advertised" on an enterprise-wide platform promotes the concept of re-use of business services. This in turn leads to promoting business agility because business offerings are assembled from re-usable services instead of being built.
Among the stated benefits of SOA is the separation of the interface from the implementation of the service. The preservation of the interface can be referred to as interface durability. A byproduct of decoupling service definition from service implementation and deployment in a SOA-based service deployment model is enhanced service interoperability. In other words, the implementation of the "published" interface can be provisioned via software components that could be written in any language or be deployed on any platform as long as they adhere to the service interface and are available for remote access.
Despite all of the benefits, global multi-national enterprises face a special challenge in leveraging SOA as the architecture paradigm for deploying foundational services. Specifically, the concept of interface durability becomes the core issue. Being that enterprises that are typically spread across multiple geographic zones, they also are governed by multiple regulatory agencies. These types of enterprises find it challenging to adhere to common business service definitions, due to the vast diversity of "situational" and "locale" variances. This then opens up the need for an architecturally sound way to handle the "operational" diversity in a manner that enterprise-class services would need to support without breaking interfaces or replicating services.
Objective
I will introduce the Situational Awareness Injection Service Pattern to help those architects looking for an innovative, architecturally sound way to handle business variation in enterprise class services without the need for breaking interfaces or replicating services.
This article tries to demonstrate how an enterprise can deal with locale-based adaptation without impacting the concept of interface durability. The pattern also shows how enterprises can improve their responsiveness and enhance business agility to deal with the inevitable change in today's business environments.
Assumptions
This article assumes that the reader is a SOA practitioner and that this article is not a SOA primer. Neither is this article attempting to justify SOA as an architectural paradigm. A basic understanding of the concepts of externalized Rules Processing is assumed.
In addition, the article proceeds under the assumption that there is a strong relationship between the service interface and the business payload (referred to henceforth as a business entity or a business concept) being returned by the service operation. The service consumer context is considered to be the input to the service provider whereas the service consumer context adapted business concept is considered to be the outcome of the service invocation.
It should be noted that this article does not discuss the design constructs that could be utilized by the service provider to implement non-enterprise worthy or business-area specific business behavior. Whether the model includes the use of a rules engine that expresses business unit specific algorithms or else if the model leverages a service adapter, service gateway, or service broker pattern to identify and route the call to the specific service implementation layer is left up to the application architects' expertise. The article considers any of the previously mentioned design models as appropriate for incorporating business-area specific business logic.
Business Scenario Overview: Business Reasoning to Support the Need for the Situational Awareness Injection Pattern
I will use the following business scenario to illustrate the problem domain.
A global financial company has multiple divisions, such as a brokerage division, loans division, credit division, retail banking division; all of these divisions have a common need for getting customer account information. The assumption in this case is that this enterprise-worthy business concept is accessed via requests that are made to a common enterprise class "informational access business service."
Even though the various divisions of an enterprise such as this may have the need for customer account information, there are some core differences in what aspects of customer account information is needed for making further "business context"-specific decisions. Depending on the business division and the calling consumer, context retrieval of one or more aspects of the customer account information is governed by contextual business rules, regulatory rules, and locale specific business rules. Furthermore, associative business concepts that are needed to populate the customer account business attributes may be impacted by "business-area specific" rules. These may include business concepts such as the customer credit profile, customer preferences, and the customer profitability business concept definitions. In all cases, either the final customer account business entity attribute values or base attributes may be altered based on the business context, regulatory domain, and the "localized business" rules that govern the particular business subsidiary or business division.
The purpose of this article is to outline a strategy that would allow enterprise-class business services and the business concept payloads that are returned by them to be applicable and re-used across the enterprise's multiple business areas. There is also an attempt made to come up with some design and implementation strategies that allow the service behavior to be re-used while accommodating the "situational" behavioral changes.
To this end, I demonstrate how to incorporate localized business context, locale-driven regulatory policies, and regional influences into a common enterprise service by externalizing locale-specific rules and policies. Further, I show how these variant business rules can be incorporated at deploy time or runtime to deliver maximum business agility. The proposed solution also enables re-use of the service implementation layer, thus making a more compelling case to adhere to a common interface definition for a business service such as the customer account informational service that has cross-enterprise applicability.
Note: Appendix A details the Customer Account example in far greater detail.
Possible Alternative Business Service Options to Deal with Operational Variance Among Business Divisions
As mentioned above, SOA is a vehicle to achieve business agility. However, this does not mean that an enterprise and specifically a service consumer do not have to react to locale-specific rules and policies. Before you embark on defining the actual architectural pattern, you will review a few alternate design and implementation models that can be employed to accomplish this goal.
The following approaches point to various degrees of re-use that can be applied to the design and implementation of a service as a solution to accommodate "situational" variance:
- Creating a new service interface and service implementation: Offers code reuse
- Extending the service implementation while retaining the service interface: Service interface re-use (and possibly base service implementation re-use)
- Injecting situational awareness into the service implementation while retaining the service interface definition and most of the service implementation layers: Service interface reuse and service implementation re-use
It should be noted that these alternative models are documented in the order of increased flexibility and enhanced re-usability of the service interface and the service implementation layers.
IE 7
Firefox 2.0
