Aspect Enforcement
When we introduced aspect-based SOA Governance, we defined aspects as key non-functional characteristics of enterprise services that are of importance to business today. This is [intentionally] a very broad definition that covers a lot of things ranging from security and monitoring to QoS metrics, censorship and regulatory compliance. It is fairly obvious that the governance platform should be able to treat such diverse characteristics quite differently and we capture this diversity by categorizing the aspects by enforcement level. When we designed our solution we have identified four such enforcement levels and everything that I have encountered so far fit neatly into this taxonomy.
Before we dive into these levels and their meaning, I would like to remind how Sun SOA Governance Solution uses the aspects. Our fundamental approach is based on governance-by-contract. We create end user consumable Service Offerings by combining service implementations with one or more reusable Governance Contracts. The contracts are constructed from clauses and each clause contains a statement about a specific governance aspect. These statements are made by associating an aspect with a specific value, for example:
- Throughput = 10 transaction per second
- Availability = 99.999%
- Time to Recover = 5 hours
- Usage Metering is true
- Security specified by
<ws-security Policy document> - Clearance level is “Top Secret”
- The service complies with the European Privacy laws
Aspect Enforcement Levels are directly related with the kinds of values that can be used to make statements about the aspects:
- ADVERTISED – the lowest level when the associated value is in human-readable form only with no formal semantics and enforcement strategy. For example, in order to reason about the Sarbanes Oxley Compliance of a composite application, one needs to know that the services it depends upon have been audited for compliance as well. The corresponding governance clause can simply state: the service has been audited and found to be in compliance with Section 404 and 803 of Sarbanes-Oxley Act.
- SPECIFIED – similar to ADVERTISED, but the aspect value is specified in a formal machine-readable form with exact semantics. Tariff (cost of service invocation to the consumer) is a good example of aspect that can use this level.
- REPORTED – similar to SPECIFIED, but implies that the system can and will actively monitor compliance and report violations. Report here means simply make known to someone and can include things like raising an alert, sending a message, including a warning with the reply or simply writing to a log. This level is typically used with various QoS aspects, such as throughput, latency, availability, reliability, time to recover, etc.
- ENFORCED – similar to REPORTED, but means that in addition to reporting non-compliance the system will attempt to take a corrective action when it occurs. The nature of the corrective action depends on the type of the aspect. For restrictive aspects, such as security and throttling, it usually means simply rejecting the request. For affirmative aspects, such as performance or availability, governance engine might attempt to use service management capabilities to remedy the situation, for example issue the Increase Capacity request to the container hosting the service implementation or failover to an alternative implementation. There are many more possibilities, for example compliance aspects might transform the requests and/or responses to censor classified information or replace personally identifiable attributes with surrogates, etc.
The two higher levels have to be supported by the run-time infrastructure and require that corresponding aspect enforcement methods to be implemented and deployed into the governance engine or, in case of delegated enforcement, registered with it.
It is also worth noting that an aspect doesn’t have to be always associated with a single enforcement level. Sometimes, depending on business requirements and context, it could make sense to support two or more levels for the same aspect. For example throttling can be enforced for external consumers, over which an organization has no direct control, and just reported for internal ones where alerting operations should suffice. The following table illustrates how a Throughput aspect can be defined at each level:
| ADVERTISED | "The system has sufficient throughput to sustain non-batch loads during normal business hours" |
| SPECIFIED | 10 TPS |
| REPORTED | If average throughput under load falls below10 TPS for more then 10 seconds, the system will raise an alert and notify service provider and affected consumers. |
| ENFORCED | Same as above, but in addition the system will use service management interface to issue increase capacity directive. |
In particular, Sun SOA Governance Solution supports development of context-aware aspect enforcement methods that adaptively change behavior depending on the enforcement level of the aspect with which they are associated. For example lease and throttling aspects included with the framework support both enforced and reported semantics.
Conclusion
I hope that I made a good case for the need to recognize and support all four aspect enforcement levels in a comprehensive SOA Governance platform. In a future post I also plan to show how the SPECIFIED level helps to deliver on the original vision of SOA that has been largely forgotten in the recent rush of “practical” implementations.
