An associate of mine recently asked me if policies on services in a service oriented architecture should be enforced by date, or better yet, be able to expire or sunset them. I gave it a quick thought and replied “It depends..” So I have given this a lot of thought over the last year or so, and my conclusion comes down to the fact that it depends on many factors.
These factors, although not exhaustive for brevity’s sake, might include your business process, auditing requirements, internal and external security standards, and typical performance factors such as response time, availability and throughput.
Let’s start off with the performance factors: Response time, availability, throughput and fault/error counts are a good starting point for building service level agreements. Are your service level agreements considered in-process policies or post-processed activities? Should SLAs be enforceable by date? In my thinking, SOA-based SLAs whether they are in-process policies or post-processed activities, they should be date enforceable-as they are basically the outline of your real world service level agreement, and as such have a start and possibly an end date.
Working backward from the factors list, we have an internal and external security standards. Well, should they? It depends right? (Most people who know me, know that “It depends…” is sort of my default “caveatted” answer.) I do believe that SOA security policies should be enforced by date but that also depends. If one applies a security policy knowing full well that they are never going to change that policy, should one care about setting an enforcement date? Probably not. For example, I’ve been mandated an SSL request/response exchange between two services because it is internally mandated that traffic has to be transport encrypted.
However, if you do know you are going to sunset a security policy at a certain date (for example, you will be adding more capabilities to succeed the current security policy), then yes, that is a good thing. From most SOA environments that I’ve had to deal with, they haven’t thought that far ahead in the future. Heck, most of the time they are just trying to play catch-up with the standards, vendors and/or other competitors.
One thing that might be worth mentioning is that only recently have SOA enforcement policies started to become more standardized. This includes WS-Security. WS-Security is an over-arching conceptual model for providing a mechanism to do “partial” security is a SOA environment. WS-Security incorporates X.509, Kerberos, SAML and Username Tokens, and covers SOAP with attachments and Rights Expression Language. A big problem that I see right off the bat with this is that many standards are incorporated into it by other organizations including OASIS, W3, MIT and the ITU. Now, these organizations say they all are trying to advance the standards but differing very large companies influence the specifications and standards to their liking.
As one could hazard to guess, most companies and organizations have competing agendas. These agendas don’t necessarily align with each other. This could be a problem in the future if one is enforcing SOA policies by date. In a SOA world, some enforcement points might have adaptive security policies. In this SOA world, composite services might not always be controlled in one environment. They are simply organic. That is they take on new changes to policies, as long as they are technically valid, and start enforcing them. So, having a standard like WS-Security, which will be dependent upon other standards, could cause an adverse reaction if a message hop occurs outside of the network to a vendor that is not enforcing your standard. Certain organizations have differing security requirements. Remember, the reason behind SOA is interoperability with data messages across heterogeneous environments-not necessarily interoperability with security requirements.
What are your auditing requirements? To determine the enforcement of policies for logging of data, ask yourself this question: “Do I need continuous data from now until the end of time?” If the answer is yes, then an enforcement date is not necessary. You simply apply the policy to services and let the intermediary do all the logging. However, if your answer is no, then look at it realistically. You might be pondering to yourself: “Well, I really only care about logging data to a service between 9 am and 5 pm for the 1 month prior to Christmas-because that is when our organization will more than likely have a higher risk of security breaches, higher order and higher service consumer volume. I want to be able review that period after Christmas and determine a more scalable or more secure architecture for the same period next year.” THIS is a very good reason for creating SOA policies that are date-enforceable.
You simply can’t talk about SOA without mentioning business process. It is an inevitable fact that business processes mandate a lot of implied requirements, in and out of a SOA environment. Since business processes in a SOA environment are generally made up of multiple services, aka Composite Services. As such Composite Services might be the whole business process or part of a business process. In modeling business processes, do they all have the same requirements? The answer is almost always and inevitably ‘No’. While some business processes, when looking from design and business process patterns, look similar they are 98% more likely to be different in actual implementation. Hence the name pattern, it simply a model for building things to a spec or standard that look like your requirement.
How does this affect us from a SOA Policy/Date enforcement point of view? Well, as mentioned above, you might have certain auditing or security requirements for business processes-or for performance, certain events must happen within a certain period of time. Things that come to mind are HIPAA and or financial services requirements. Some processes are heavily regulated. But then again, do we need to enforce auditing requirements by date? Maybe or maybe not-is it or is it not required by law or internal regulation. It could be dependent on a lot more factors that are not necessarily mentioned here.
Recommended for YouWebcast: The Art of Growth Hacking: Gaining Early Traction by Doing Things that Don't Scale
So to summarize, SOA policy enforcement by date is heavily dependent on factors that one doesn’t necessarily have control over. As I stated in the introductory paragraphs, this list of factors is not necessarily exhaustive. So when thinking about enforcement by date, also think about the overall maintenance of rolling out policies. That could be a job in itself. How much work are you willing to do upfront as well as on a continuous basis?