| QUESTION & ANSWER |
SOA policy: Enterprise logic vs. application logic |
 |
By Rich Seeley, News Writer
30 Aug 2007 | SearchWebServices.com |
|
|
A metaphor from "The Simpsons" comes to mind when Miko Matsumura, vice president and deputy CTO for Software AG, talks about the future of service-oriented architecture (SOA) policy. He points to the episode opening where there is a car and at first it appears that Maggie, the baby, is driving. But as the scene expands, we see that Marge, the mother, is actually driving and Maggie is in a car seat with a toy steering wheel. In terms of controlling SOA policy, business people are in the position of Maggie with her toy steering wheel. Developers, whether working in the Java or Microsoft .NET platforms have tended to be in the driver's seat. As Matsumura explained in part 1 of this interview yesterday, that is not good governance practice and it is in the process of changing. In today's interview, Matsumura offers a view of how those changes may eventually transform how developers and business people interact in an SOA world.Read part 1
The new approach to policy implementation that you see coming is still in the early stages, right?
Miko Matsumura: I think we're in the first inning of nine. Ultimately there's going to be a need to start to federate policy from the perspective of the concerns of different enterprise constituencies. That's really the goal.
How do you get there from here?
Matsumura: Let me tell you the next logical step. Right now we're mostly federating the concerns of other IT constituencies. We moved from the concerns of developers to the operations management people who handle contracts and runtime policies. What's emerging is the notion that we want to externalize the concerns of the QA department in the form of things related to governance as well. I think we're slowly creeping across the concerns of different IT constituencies across the lifecycle, but I think ultimately we're going to have to be inclusive of the concerns of governance and regulatory parties, things like business rules and lots of different concerns and constraints across the enterprise.
Is this something that being done by vendors like yourself or is it going to be hammered out in a standards body, or both?
Matsumura: It will be both. The thing that is important is that people that are moving into enterprise SOA need solutions today and as the market matures the ability to federate these concerns enables us to standardize. That's good for everyone.
Will we eventually then end up with a language like BPEL?
Matsumura: The thing that I think is going to end up happening is that there are two basic ways to assert policy. One of them is parametric. You can make a policy that says this value should not exceed 100. That's a parametric declaration that tends to be fairly simple in terms of how it's asserted and you can actually reflect that in a user interface fairly easily. You can make a little numerical box and put the parameter in there. That's how we do service level agreements. The second notion is a little more complex, which is when you start to assert declarations about sequential behavior like BPEL. So that becomes an externalized declarative process, which is parse-able, validate-able and governable. But what I think eventually is going to happen is there is going to be a convergence of the user case requirements and there are going to be different approaches to these problems.
What's that going to look like?
Matsumura: Let me give you an example. Some constituencies are going to want a Web page to control certain parameters. Others are going to want clever BPM tools. Some constituencies are going to want clever rules engines, but other constituencies may want domain-specific languages. Ultimately what you are going to want is a system that enables each enterprise group to express their requirements, desires, constraints and expectations. If you're able to automate that you will be able to create a framework for what I call enterprise logic as opposed to application logic.
And all of this will be outside Java or .NET?
Matsumura: Right. Because the issue becomes that while both of those constructs are extremely expressive and powerful, the amount of influence that non-developer constituencies can exert over those and the extent to which their needs can be met by these types of systems is somewhat limited. Those platforms are strong for certain kinds of logical assertions because of their power and flexibility, but the world is not ruled by application logic. It ruled by enterprise logic.
It sounds like you wouldn't want the automakers to control the traffic signals?
Matsumura: Development is an extremely important constituency, but with that being said there is an emerging sense that doing large scale computing transcends just the development function.
So your position is that enterprise logic transcends the debate over Java and .NET?
Matsumura: My bottom line is there is Javaland. There is .NETland. And there is SOAland. And the logic in SOAland is partly in .NET, partly inside Java, and then there are other things.
And the other things like policy need to be outside both Java and .NET?
Matsumura: I think that's a logical assertion. The notion of setting a service level on a service and managing it from a mediation point is clearly not a language-embedded or constrained construct. It's something that ought to be transcendent so you can manage all your services.
|
|
|
|
