November 28, 2014
Hot Topics:

Achieving Situational Awareness in Enterprise Services

  • March 27, 2008
  • By Surekha Durvasula
  • Send Email »
  • More Articles »

A. Creating a new service interface and service implementation. Some by code level re-use may be achieved by copying and modifying the implementation code base

Pros:

  1. Existing service implementation or code-base remains unaffected.
  2. The impact on existing consumers is minimal because retesting and redeployment efforts impact only the new consumers that use the new code-base.
  3. May result in a more performant deployment because it is tailored for use by specific consumer requests and contexts.

Cons:

  1. Creates the need for supporting multiple service versions and thus introduces new service versioning and service management policy issues.
  2. Consumers may need to know which service version they need to target and this in turn may result in consumer side changes. The reason is that the consumer may be required to "know" the right target service to fulfill the consumer-specific context and this knowledge is embedded in the request. More fundamentally, this breaks the premise of SOA.
  3. Consumers also may need to now be aware of dealing with the "situational aspects" of the changed payload as well.
  4. Service location for the purpose of mediation may become a problem if there is inaccurate or an insufficient amount of metadata available on the service request/service response envelope or header.
  5. Service location mediation may become a bottleneck and non-performant, especially if the entire payload has to be parsed to route the call to the right service version.
  6. There is a risk that the service behavior being delivered may not be in keeping with service usage semantics and "service contract" as is expected of the service provider.

B. Extending the service allows retaining the service interface while altering the service implementation

Pros:

  1. There is no need to support multiple service versions, just the need to redirect the request to the appropriate service implementation based on the service request context.
  2. Consumers are insulated from business rule variations and also service versioning complexity.
  3. Consumers do not need to worry about targeting their request to the "appropriate target service" because this is taken care of by the service provider.
  4. Consumers may not need to alter the payload definition or their consumption of the payload, but may need to augment some information on the request header.
  5. This model may be more in line with the SOA paradigm.

Cons:

  1. Introduces a service router or a service mediator component in the architecture that may become the performance bottle neck if a custom service mediator is employed instead of relying on a commercially available ESB component.
  2. Multiple service implementation code-bases will need to be supported by the service provider.
  3. Extending the service implementation code-base causes the service to have to be retested and redeployed and may have a negative impact on existing consumers because the service redirection component will need to be retested.
  4. Code base extensions may lead to overriding behavior instead of enhancing of the base behavior provided by the existing code base; this could lead to non-deterministic regression test results.
  5. Code extensions could cause the service usage semantics to be altered, thus digressing from the expected and advertised behavior of the service contract.

C. Applying the "Situational Awareness Injection Pattern" to retain both the service interface and service implementation

Pros:

  1. The Service Interface and the service implementation are preserved.
  2. Service implementation is extensible and flexible.
  3. There is a reduction in the amount of testing and redeployment level issues.
  4. Service behavior can be altered by specifying metadata; this results in greater speed to market given that the changes are not made to the code base.
  5. Business users could become self-reliant and responsible for altering the business rules, thus reducing the risk of loss of translation in the business rules.

Cons:

  1. Performance may be an issue due to externalization of the business rules.
  2. Depending on the metadata used to drive the business behavior, the metadata to business rule mapping logic could become complex.
  3. There is a need to introduce a business rules engine component to deploy the solution.
  4. Code testing and debugging during the stabilization phase of the service can become complicated.
  5. There is a one-time analysis hit to create the metadata repository that is extensible and flexible.

Overview of the Situational Awareness Injection Pattern

Making an enterprise service locale aware allows both the enterprise level rules and the locale-specific rules to be incorporated in honoring a service call. However, to preserve the code base, I propose a model that externalizes volatile business rules (regulatory policies and locale-specific business rules). This model keeps the service interface and the service implementation layers constant because the service implementation layer does not hard wire business rule definition and business rule interpretation logic in the code base.

This model also allows all layers of the service stack—in other words, the service interface and service implementation layer—to be re-used to deliver a consistent and robust solution. At the same time, context-specific rules are applied by the service provider and not by the service consumer. This then helps in making the service truly business friendly. Furthermore, creating a configurable "situationally"-aware service allows specific QoS policies to be applied, thus enabling the service provider to deliver context relevant business solutions.

The service model presented here shows how the attribution of both the information model and the canonical message interchange model is driven via the use of a metadata. Additionally, the attribute values are arrived at via the use of a business user friendly rules engine framework.

In this model, the service could either just return a business concept if it is just an information access service or else, in a more sophisticated service, it could also wrap a common business function. If a business function is being wrapped, the externalized rules would apply to the creation of the business concept attribute-set and the order in which regulatory rules are executed to alter the attribute values. Here, the assumption is that the end result of a business function execution is the creation of a "context specialized" business concept that is adapted to deal with the "situational rules" governing the consumer business context.

It must be noted that only those service interface-based operations that need volatile "situational" rules are impacted by the need to interpret external rules. This type of selective rules engine interaction enables the service implementation to be optimized to honor the consumer requests.

Rules governing how the business concept is populated and which algorithms are used are all encapsulated in the business service. These could be embedded in the business logic layer if these are stable, enterprise-worthy rules. On the other hand, in the case of volatile departmental rules, these could be defined in a business rules engine and these could be incorporated into the business logic layer at runtime. The algorithms and the rules are all encapsulated in the service and are easy to change in a consistent fashion. For instance, the enterprise may define the algorithm that is implemented in the service to be consistently applied. For example, customer profitability may be calculated to be a ratio of the sales factual information and payment history.





Page 2 of 6



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel