[Series Links: Part I / Part II / Part III / Part IV]
In the last post we looked at how SOA Software is used to manage and maintain web services. Today, let’s look at how we can configure web service “policies” to do everything from encryption to load balancing.
So far we’ve seen that a give service managed by SOA Software can have a “policy” attached to it. What is a “policy” really? The types of policies we’ll look at here include “management” policies, “SLA” policies, and “access” policies. For a BizTalk developer, think of a management policy as a pipeline. The management policy configuration page looks like this:
You have a series of components to handle the request message, and series of components to handle the response message. Again, very much like a BizTalk pipeline. For the Record component in this template, you can configure it as such:
You can snag either the entire payload, or choose to grab only a specific record(s). Odds are, you’d only have a policy do this much recording of data during a test or debugging scenario. But, it’s quite useful if you’ve got a series of complex components (encryption, etc) and want to print out the result after a particular stage.
The Security policy component is quite powerful. You can perform authentication checks to ensure that the service client is a valid user in a defined identity system. After choosing which identity system the policy should confirm against, you next choose the means of capturing the actual identity. Choices include SAML, x509 certificates, HTTP Basic Auth, and more. From this component you can also apply or verify digital signatures.
If you choose to, you can also apply WS-Encryption and WS-Decryption capabilities. The WS-Encryption lets you choose the way to encrypt, and then WHAT to encrypt. So you could identify 4 nodes in your SOAP payload that contain sensitive data, and ONLY encrypt those fields.
You could also choose to manipulate the message a bit by using the Strip Element component. Let’s say that you’ve already verified a signature, or received credentials in the payload that are now unnecessary. You could strip those out before sending the message on to the next hop. Nice.
For performance reasons, you may also want to use a Caching component. In this case, the Policy will compare the SOAP body/envelope and if it matches an instance in cache, the cached response message is immediately returned.
Other valuable management policy components include:
- Authorization
- Schema Validation
- Dynamic Management (where you can re-route the service to different service locations based on rules)
- Data Transformation
- Compression/Decompression
- Load Balancing
Those were examples of “management” policies in SOA Software. You also have the ability to create additional policy types. One interesting one is the SLA Policy. In this type of policy, you can dictate performance-related metrics that should result in a system level alert. For instance, my policy below says that if SOA Software encounters more than 25 SOAP faults in a 1 day period, raise an alert. And remember, this specific policy can be associated with individual services and operations.
There’s also the concept of Access Policies which can be used to restrict traffic to a given service. If you had an external vendor calling your service, you could create a policy that says that a particular user/company can only execute the service 500 times a day, or, only between the hours of 8am-5pm Monday through Wednesday.
Now you could have the concern that managing these policies, and who is using them, could be a nightmare. What sort of dependency tracking do you get? The answer is, surprisingly strong reference management. In my Policy Overview screen, I can see how many service operations use a given policy.
I can then drill even further, and see each operation using a given policy. That alone is useful, but what if a mass update needed to happen? From this view, I can make bulk changes to each service that uses the policy!
That’s huge. Otherwise, even 50 services could be a challenge to maintain, not to mention 500!
It’s a fairly safe assumption that the “policy” functionality of SOA Software is where you find significant business value. All of these policies are applied, and enforced, without touching your service, or creating code. I suspect that my company will use the security-related components most frequently. The non-security policy components will definitely find a home in various policies, but we’ll see a universal adoption of security components off the bat.
As you’ve seen so far, managing existing services is easy. The only place where a developer needs to be cognizant of the fact that a service is managed is when they CALL that service. The next post is where I bring it all home. Specifically, how can BizTalk Server (or ANY .NET/Java application) make accurate calls to a service managed by SOA Software?
Richard Seroter's Architecture Musings 