In a recent blog posting I discussed how one of the organizing principles that we’ve introduced into our SOA and Cloud products has been the idea of reusable patterns, and how that PureApplication System allows us to nest these patterns together, allowing reuse at multiple levels.
However, that’s not the entire story. There’s a second part of our strategy that also extends across the same set of levels – the concept of policies to help you implement non-functional requirements. We first began implementing policy within our SOA products, particularly the WebSphere DataPower SOA appliances, WebSphere Registry and Repository and WebSphere Application Server where we implemented WS-SecurityPolicy. The concept here was simple; just like Patterns allow us to achieve reuse of template implementations of a particular approach, Policies allow us to specify the goals in a particular area, which we can then implement through the use of patterns specific to those goals.
For instance, with WS-Security Policy your security team could specify that they want each of their SOA services to use a particular approach for validating authentication tokens, or to use encryption in a particular way. The policies can be stored in WSRR and then they are implemented by mediations running in DataPower together working together with the WAS security infrastructure. What we introduced last year was a new approach that extended that idea with the concept of policies that can be defined using the WS-MediationPolicy standard. This way, you can specify policies around how your SOA services should have their traffic controlled – so that you don’t overload a SOA service and maintain a certain quality of service level. This year at IMPACT we expanded that support with additional capabilities – all built on the same set of products, but allowing you more flexibility in how you specify your own patterns to implement any policy for your SOA services that you can conceive of.
Just as with patterns, though, the policy idea wraps back around itself with PureApplication System. Probably the most important feature of Virtual Applications is the ability to specify policies for non-functional requirements like scaling as part of your Virtual Application pattern. An obvious evolution that we are looking into right now is how to provide policies for additional non-functional requirements such as security. So the concept again stretches across all levels, and helps liberate you from having to focus on HOW you implement your non-functional requirements and focus instead on the functional requirements that are the reason WHY you’re writing your software in the first place.
Related blog entries