News Stay informed about the latest enterprise technology news and product updates.

A middle way to SOA governance

John Michelsen, chief scientist at iTKO Inc., the service-oriented architecture (SOA) testing and governance provider, believes there is a middle way between the rigorous governance proposed for SOA based on WS-* specifications and the other end of the spectrum where Representation State Transfer (REST) approaches have little or no governance. As he suggested in part 1 of this interview, too much governance may stifle flexibility and too little may cause SOA applications to break when changes are made to Web services. He outlines a practical approach to governance for SOA in the second part of this interview from Integration World 2007 this week in Orlando, Florida.

Read Part 1

What do you recommend for developers trying to find a happy medium for SOA governance between the rigors of WS* and the much less rigorous approaches using REST?
You don't necessarily need to pick one over the other, but you might choose one based on your particular situation. If you're the Department of Defense and you really do need governance over flexibility, then you can go the WS-* route, but you don't have to do it in an oppressive level. You'll have a federated governance model where you apply the right level of policy at the right level within the systems you're working on. For example, governance policies around applications that do weather lookups for someone at a portal in the consumer space doesn't need the highest level of governance, but that same service may need an enormous amount of governance placed on it if it's being used out in the field to provide data for radar systems. There's an enormous difference there. So you could see DoD going the way of WS-* that's a WSDL-based, very structured, policy route, but to make sure I don't overdo it, I'm going to make sure I apply the right level of policy to the right level type of solution. What if you're doing something more REST oriented?
You can do the same thing if you're going the [REST] route. I kind of like the missile defense system having some governance, but for many applications it's overkill to go into such rigor. That's why the ground-up SOA projects are mostly going [Web-oriented architecture] WOA. There's no reason for them to deal with so much of this structure. The structure is more about horizontal governance where there's reuse of services across an organization horizontally. Since RESTful style SOA is generally not that worried about that form of reuse, it isn't that interested in that kind of policy. If I'm not at the DoD and I'm just building an ecommerce app, I might go totally RESTful, because I have a vertical governance problem. I may integrate with other things in a mashup style, but I don't have control over those whether they are on WS-* or not. In that case, I like the idea of going WOA. What level of governance do you think is basic regardless of what the implementation might be?
Here's what I talk about to our customers and prospects and in the talks I give. There are two basic layers of governance: the producer side publishing cycle and the consumer side consuming cycle. The difference between producing a service that is made available in a SOA and just creating a re-useable software component is the process you go through in making that service available to the rest of the network to consume it. You can build a component that's hidden and you never publish it and it's still a service, but it doesn't get out. So the publishing cycle is required for SOA. There are three key attributes for a publishing cycle of a service. There's the service itself and the endpoint to that service. There are the proof points required by the policy. Those are usually test cases with a product like ours to prove that it does what it is intended to do. What's an example of proof points?
If I do customer lookup services then I should provide test cases so people can see that I can validate that there are six or seven different scenarios where you want customer lookup with my service and it was accomplished. Here are the test cases to prove it. Here's my functionality and here's the proof that I actually do these things. And what's the third key attribute?
The third piece is the testability of that service. Essentially, it gets to the fact that if you produce the customer lookup service and I call your service and you are part of my workflow, I need the ability to validate that what you gave me as a response really is the accurate response. So those are the three attributes, the endpoint itself, the test cases and the testability. The tests are proof of certain policies. They may be structural policies, interoperability policies, security policies, performance. That's what's needed on the producer side. What is needed on the consumer side?
Most people don't think of the consumption side. They think the publisher does all the work. The producer made the service for customer lookup and I'm free to consume that thing any way that I want with however many applications I want. I don't have any kind of governance that I need to do. That's scary. Why?
Because if your service is being leveraged by eight to 10 different people and you don't even know those people, that's an inhibitor to you being able to make changes. Because if you make changes for one consumer, you'll have unintended consequences due to those changes and you'll blow up other consumers' applications. They're going to blame you, but you can't be all knowing. You can't know every possible way people are ever going to use the service. So there's a consumption cycle as well. That consumption cycle essentially does validations of the services behavior in the context of how it's being consumed.
For more information
SOA governance defined

The governance gap in SOA
Can you give an example of how that works?
I might consume your service in a particular way and I will create a policy level or test case that puts your service into the context where I'm going to use it. It validates its behavior continuously over time. So even though you are going to change your service – you've got every right to do that – I need the confidence that those changes won't break my intended use. Another user might come along and ask you to make an enhancement and that enhancement might offend the way I use your service. It happens all the time, but before we go to production and before we're all finger pointing, there's a conversation that goes on. I say to you, "Hey, the latest change you made just starting breaking one of my workflows." Now, we have a good old fashioned human conversation and figure out how we are going to make this work. We figure it out and then everybody is happy. We avoided a bug because we had the visibility on the consumption cycle. This is where governance is real. How do you mean real?
All the WS-* stuff is fine, but where producers and consumers of services really have trouble is at this level. It's the behavior of services and how they interoperate and how change affects them over time. If you get good at producer cycle governance and consumer cycle governance, you're going to be in great shape. And that's not something that can't be done in WS-* SOA or WOA. It can be done in either way.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close