A Note On Policy Portability

Today, I write like my colleagues. No humor. No funny title. No family stories. Just boring technology evangelizing.

I apologize.

But, I have something to say, and it can't wait until I think of a funny, but related personal story.

People often ask about policy portability. In particular, something along the lines of:

"Is there a way to create an XML representation of the policies configured/applied to services so that we can store them in the registry and share them with other policy enforcement points?"

Policy would only be truly portable if there were a standard that defined how policy should (could) be written. It would have to define a lot of things that we take for granted, like how to define semantics of policy constructs (defining something as simple as response time can vary greatly from vendor-to-vendor today). That in itself would be difficult, but perhaps not impossible.

The larger challenge becomes the "value added features" that vendors enable in their products that differentiate them from one another. From Progress® Actional's perspective, these value added features include Service Stabilizers, Dimensions, and Message Fields - all aspects of our product that add to the flexibility, scalability, and overall power of the platform. These are powerful features that provide detailed insight into service usage and control in a shared environment.

Realize, that this might sound like I'm trying to defend my product's value-add, but in fact, this is one of the real differentiations - how powerful can a governance solution write policy? How flexible can the policy be? How can it be applied creatively, to make sure everything is managed, even services you don't know exist? (Yeah-  you got that. We can write policy, and have it be inherited by services we don't even know exist. And, the policy automatically kicks in, when appropriate, without having to restart services, app server, or management platform).

I'm not sure I think these things could never be standardized. But, perhaps it might happen. And, we'd be all for it for those of us who work on and with Actional products. But in an emerging market, in many ways, the market is still trying to figure out what works and what doesn't. That's why many of the WS-* standards efforts (including WSDM, which I think in some ways might have indirectly led to policy standardization) have faltered. I think the standards got a bit ahead of the market and actual implementations.

Back to my point. It's very useful to visualize, in a way that scales to the enterprise, performance by customer, business process, or whatever arbitrary business characteristic a business manager wants. It's powerful to see this information without any a priori knowledge of the set of information to view things by (e.g. you don't need to pre-configure the list of customers, we can discover them live, and as the list changes, dynamically adapt and instantly start collecting new customer stats). None of that would be possible if policy were delivered as the lowest common denominator across vendors. Delivered as a standard, we'd all have to agree on how to define these things first... and in my opinion, that's too much to ask of a standards organization at this point in the maturity of SOA Governance.

SOA What? From another point of view, it seems to be a growing need. That is, for a policy written in one place to be stored centrally and then pushed to various (policy) enforcement points.

Of course, that's expressed as a feature, not as a benefit. The benefit is to be able to govern policy better, and have consistent policy deployment across the SOA.

One way to solve this problem is to only deploy solutions that embed Actional agents! Then, you can use our policies everywhere. Policies can be attached to the WSDL and stored in registries using WS-Policy standard (we do this today). Before you discount this as a "sale pitch," take a look at the breadth of platforms supported.

Actional Agents are available for a broad range of platforms, including:

1. BEA
2. Microsoft
3. IBM
4. Oracle
5. Sonic ESB & SonicMQ (Progress Software)
6. Tomcat
7. IBM DataPower
8. TIBCO BusinessWorks
9. JBoss
10. Lombardi Teamworks (see my recent webinar on this topic)
11. Cisco ACE XML Gateway (formerly known as Reactivity)

And, there are platforms that we support that have not yet been announced (and probably some I've overlooked) so ask your account manager for the complete list.

Why have these partners chosen to embed the Actional technology? Simple. We perform and scale orders of magnitude beyond any other solution out there. And, the Stabilizers, Message Fields, and Dimensions mentioned above add an abstraction layer that makes cost of ownership really low through a really flexible policy implementation.

In other words, our Agents can be embedded in places where performance and scalability are critical. Places where other technologies simply couldn't live because of their footprint or intrusiveness. Imagine how the very powerful XML accelerators that embed our technology would behave if each time an XML payload needed to be processed, the management solution had to send the message back to the central management server?

But, I digress into hitting my competitors for poor enterprise scalability. We've just been removing so much of their stuff lately...

The downside of putting Actional everywhere would be the perception of our policies being proprietary and being locked into Actional. Well, I tell you what... any solution you choose, that'll be the case. The advantage to Actional is that if you choose one platform, say BEA, and all of a sudden, they get acquired by another vendor, say Oracle, you can easily migrate to the new platform without having to redo your policies. You can easily plug-replace, or amend, you infrastructure with an instrumented platform, and not have to re-design your policy infrastructure. At that point, you need to decide three things to choose the right policy infrastructure (Actional!):

1. Does the solutions scale to my needs?
2. Is the policy authoring power sufficiently robust?
3. How many partners consistently support the policy infrastructure?

In fact, the argument against us being proprietary is to look at the alternatives (considering that any solution today is really proprietary)... one alternative is to have weak policy authoring (through a lowest common denominator policy language) or, point-to-point vendor integration to work around the lack of standards. Point-to-point integration has the weakness that usually each integration is done differently, and not all features are available everywhere.

I think a single vendor solution that doesn't compromise policy flexibility or power, or solution scalability or performance, while enabling a broad selection of policy enforcement points (and for that matter, policy repositories via WS-Policy) and technologies/protocols, is a desirable, and in fact, preferred alternative.