By rtenhove on Apr 24, 2007
Why wrong? Just wait for the second shoe to drop... the service is too successful, and is reused by consumers far and wide in the company. Suddenly it slows down, adversely affecting business processes. People get grumpy, and fingers are pointed, and emergency plans must be hatched to scale the service to cope with its own success.
This scenario plays itself out every day, and it points out a lot of different deficiencies that all point to the need for both design- and run-time governance of any SOA system. I'll save design-time governance for another day, and dwell on some aspects of run-time governance of the system.
First, a definition, then an assertion. A policy enforcement mechanism (PEM) is a mechanism in the SOA infrastructure where run-time policies (security, SLA and the like) are enforced. The PEM can enforce access controls, ensure schema compliance, guard against over-use of a service, load balance, do content-based routing and much more.
Now the assertion: a service isn't really reusable unless it is offered through a PEM. The PEM gives you operational control of the service that is completely unrelated to the logical function provided by the service. SOA enables reuse, but unregulated reuse can result in an inability to control that reuse in any fashion. In some environments that might be just fine, but in most commercial environments such a collegial situation is rare, and the risks of suffering a meltdown (as illustrated in the little scenario above) quite real, and very costly (not to mention career-limiting :-) ).
This bears restatement: a service offered without run-time policy enforcement mechanisms is not truly reusable.
Regulating reuse is just the tip of the iceberg. It is an instance of a more general problem of ensuring that services comply to all applicable policies within the production environment. Examples include auditing requirements, privacy controls (e.g., all SSNs are to be encrypted), and even service mediation (versioning, or perhaps protocol). And just to make things worse, compliance is a moving target: legal requirements change (both over time, and by legal jurisdiction), as do internal policies.
This sounds like it is pointing to a massive application maintenance headache. How it the world do I write services that comply to all these extra, changing requirements, when it is tough enough just getting the core service functions right in a timely fahsion? How do I respond to what are operational issues and needs from within the normal software development life cycle?
Fortunately, there is a better way than brute-force, code-first solutions. The good old trick of "separation of concerns" is very handy here. Our PEM can be completely removed from service providers, and placed into a Policy Enforcement Point (PEP) in the SOA infrastructure. This separates the concerns neatly: the service provider concentrates on supplying the core service, and nothing more. The PEP "protects" that core service by acting as an intermediary between the service provider and the service consumer, enforcing all applicable policies so that the provider will only receive messages that are compliant. Further, the policies enforced by the PEP can be changed without affecting the service provider, allowing policies to be changed quickly and frequently, and completely outside the service's software development life cycle.
The service consumer, obviously, deals not with the service provider, but the PEP. The service offered by the PEP is often referred to as a "virtual service".
There is a lot more to be said about this. If you are interested in practical, policy-guarded service reuse (and that should be most of you SOA folks), and you are attending JavaOne in May, please attend TS-8459, titled Service Virtualization: Separating Business Logic from Policy Enforcement, Wednesday May 9th, at 6:35 PM. I'll be co-presenting this talk with Scott Morrison, from Layer 7 Technologies, who has a lot of experience with service virtualization in SOA systems. I hope to see you there!