November 28, 2014
Hot Topics:

Achieving Situational Awareness in Enterprise Services

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

The service implementation process logic may take on multiple paths depending on the consumer context. The service provider also uses the consumer usage context to insure that only the relevant information is returned based on the needs of the consumer. This could also dictate what the consumer is allowed to view. The service provider also may be able to use this same usage context to optimize the amount of processing performed and the amount of information returned. Also, the provider may be able to make a determination on whether the information that is embedded in the payload needs to be encrypted and certified depending on whether the consumer is an internal or an external third-party requestor. Again, the semantics of the service invocation may vary based on the consumer usage context.

Description of the "Situational Awareness Injection" Pattern

Architecture Tiers of a Standard SOA Model

The following key architectural components are leveraged in any multi-tiered, SOA-compliant model. The layers are service consumer layer, service mediation layer, service provider layer, and the service implementation layer. In addition to these logical architectural layers, the metadata repository is leveraged to accomplish the contextual adaptation and business variation being described.



Click here for a larger image.

Figure 1: Description of the core component interactions in the "Situational Awareness Injection" pattern



Click here for a larger image.

Figure 2: Core architecture components of a Service Implementation Layer

The following are the key to achieving a dynamic business concept attribute set, attribute values, and business function behavior.

  1. Controller (not in the MVC pattern but in the service provider's service implementation layer) looks up the configuration to get information about the locale information, operating business context, Line of Business or Division, 3rd party roles, regulatory policy categories, and so forth.
  2. Controller uses the metadata repository to fetch the business rules that drive the attribute-set definitions for the business concept and the override rules that impact the static values of the attributes.
  3. Controller leverages a DAO (Data Access Object) to load the attribute-set and any static attribute values from the database.
  4. The DAO creates/loads the Attribute Set that makes up the business concept.
  5. The DAO creates/loads the Attribute Values that makes up the business concept.
  6. Controller delegates the task of constructing the rules to the Context Interpreter.
  7. The Rules Framework takes on the task of applying rules and assigning the attributes to the business concept to the Rules Framework. Following are some details about the internals of the Rules Framework and the behavior it manifests:
    • Rules may be used to define "context-specific" business concept attribute sets.
    • Rules also may be used to override the static attribute values obtained from the database under "specialized" business conditions and when the business concepts have to be adapted to deal with volatile regulatory policies.
    • Rules also may change the attribute set and the values assigned to the attribute set in response to any 3rd party interactions that are involved in executing the business function wrapped by the service.
    • The assumption is that static values are materialized from a single data source of values or in more complex businesses there could be a taxonomy of rules that override these attribute values as a series of rules fire, altering the base value.
    • Rules Framework can also be used to define Rule Sets that support the definition of a hierarchy of rules where the order of execution of rules is important. In this model, one or more rules can be used to process static values of an attribute and then these attributes can be aggregated to create a complex derived attribute.
    • Rules Framework may define taxonomy of rules based on the Rule Type categories as well. In this model, the order of precedence of situational Rule Type category application can be modeled into the Rule Sets. For example, business unit operational rules are applied and processed prior to regulatory rules. In this model, business unit operational attribute-sets or attribute values may be overridden when the subsequent regulatory rules fire.
    • Rules also may be used to determine how to calculate and apply enterprise-compliant algorithms to certain attributes or attribute values of a business concept.
    • In general, the Rules Framework is only leveraged to support volatile attributes. Static attributes of a canonical model are built into the business concept. It must be noted that there is a support and performance impact to having dynamic attributes and dynamic values via the Rules Framework.
    • Finally, it must be noted that the behavioral model when leveraging dynamic rules renders the service implementation layer less deterministic from an error handling perspective.
Note: Appendix B defines the interactions of the infrastructure components in the setup view and runtime views that help to demonstrate how the architecture components work together to support the concepts of the Situational Awareness Injection service pattern.




Page 3 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