WS-Policy Framework

I have been hearing a lot of talk of late, regarding Policy-Driven Approach to SOA development.  Policy presently in the minds of many these days, applies primarily to Security, and Governance.  However policies or WS-Policy Framework provides a general purpose model and corresponding syntax to describe and communicate the policies of a Web Service and includes:

          WS-Policy,

          WS-PolicyAttachments,

          WS-PolicyAssertions.

So while we think of policies in terms of security and governance we see that the framework is extensible to cover a range of policies ie. reliable messaging – QoS, contracts, compliance, and management of other policies like behavior, rules, guidelines, preferences, and other requirements associated with web services.

Policy Management will Continue to Grow

Most SOA developments are focused on the development, composition, and consumption of business services.  However more and more development is concerned with security and governance.  Security is an on-going battle and needs to be considered as part of any new development especially if you go beyond the firewall.  Security is an on-going concern for any enterprise; however we need to move beyond security so we can get to a service-oriented economy where we can have real network-based automated transactions: SOA Hubs and SOA Networks.

Beyond security we see governance (many companies are pushing governance) as being the ‘Policy of the day’ and right behind that we are seeing compliance ie. Layer 7 Technologies (www.layer7tech.com) as the next policy of importance.  While most SOA deployments are focused on a single policy, in the future web services are going to get a lot more complex as we add a variety of policies simultaneously.  You need to keep the bigger picture in mind when you buy a security-based only solution, a governance-based only solution, or a compliance-based only solution.

Intelligent SOA Network Appliances

Given that we start implementing SOA Appliances within the network, they are likely to become more dynamic, downloadable devices that provide policy enforcement points for policy assertions.  Since the variety of policies continue to grow and are constantly changing these network elements must be flexible.  The real value in these devices is not the hardware per se, but the software “value-add” they provide and as Policy Enforcement points.

Policy Driven Development

Let’s say that the trend towards policy-driven development continues to grow and that the business analyst gets involved in the SOA development at the beginning of the development process and drives these policies through to deployment.  Here is an example of an IBM SOA Development process: model -> assemble -> deploy -> manage and governance (and other policies).  This process could also include a loopback process for the constant on-going tweaking of these policies ie. policy lifecycle management.

In this case we see a SOA development process carries the policies from modeling to the network deployment and on-going management.  What I want to identify here is that the movement of these policies to the network elements (SOA gateways and SOA appliances), means that these SOA Appliances are likely going to be proprietary and tightly coupled in order to be deployed and managed.  If so this goes against the many principles that Service-Orientation was founded on.

Tightly Coupled SOA Appliances

As a vendor of a complete end-to-end SOA solution, I can dictate the technologies, and communications methods to be used for conveying and the management of these policies between the gateway and the network elements.  Right now this is a completely proprietary and could be a tightly-coupled solution.  Until interoperability standards are adopted these solutions will not be interoperable ie. I cannot easily plug a SOA Appliance from one vendor into another vendors' security, governance or other policy solution.

Many of these end-to-end single-purpose policy based SOA solutions will work well for closed single purpose SOA Hubs, or SOA Networks however this could lock you into this vendors solution and lock out vendors that don’t offer a SOA Appliance?  Also remember in the future you may want to add additional policies or consume business services from other enterprises.

Beware - choosing a SOA Solution Vendor may require that you buy and get locked into SOA Network Appliances from that Vendor.