| QUESTION & ANSWER |
SOA policy beyond Java and .NET |
 |
By Rich Seeley, News Writer
29 Aug 2007 | SearchWebServices.com |
|
|
Refusing to join the debate over which is best for SOA development, Java or .NET, Miko Matsumura, vice president and deputy CTO for Software AG, says, "For service development, both platforms have a lot of good stuff." But looking beyond service development to SOA governance and policy, he suggests that none of the above is the right choice. "It may be preferable to treat policy via a declarative construct outside of either platform," he said. If policies are coded into the services by developers using either Java or .NET, SOA loses agility and business users lose the ability to have a say in setting policy. Since agility and business side participation in creating applications is central to the SOA philosophy, these are major loses. Matsumura foresees a third way emerging among vendors, which will eventually be turned over to a standards body to ensure interoperability. In this interview, Matsumura explains why policy and governance need to move beyond developer platforms.What do you mean when you say policy needs a declarative construct outside Java and .NET?
Miko Matsumura:
In SOA there are really two emergent phenomena. One that happens at the business level and one that happens at the enterprise level. At the business unit level there is the federation of different constituencies across a lifecycle. For example, developers have to deal with the operation people. The operations people are dealing with things like virtualization. So let's say some service is under heavy use. The operation people might want an intermediary, the ability to trigger virtualization to spawn new instances of services as policy. And you can't actually embed that into application logic because if you did it for Java, for example, then that wouldn't work if you went over to .NET. And if you did it in .NET, it probably wouldn't work if you went over to Java. So there may be a need for non-development constituencies to have a way of managing policy, particularly as you get more heterogeneous.
Like the enterprise level where things usually are heterogeneous?
Matsumura: Yeah. It gets even more complex as you move to enterprise SOA. Not only do you have federation of different lifecycle constituencies but you also have federation of completely different business interests. What happens in that situation is that the policy of one unit has to interact with the policy of the enterprise.
Can you give an example of that?
Matsumura: For example, it may be the policy of one business unit to have a certain level of security encryption. But it may be the policy of the enterprise to have an even stronger level of encryption. So the notion that you can take policy inside a single platform container is not that functional of an approach as you start to scale. An example would be a bank where they have CORBA services, .NET services, Java services, mainframe CICS services, services of hundreds of different types. The notion that you want to embed the logic of policy in a container or platform is not going to work.
So where does the policy logic sit then?
Matsumura: There are two answers. Today there is policy logic around each of the different lifecycle constituencies. A very simple example is runtime policy. A lot of the runtime policy falls into the governance system, the new registry/repository policy system, but it turns out that other forms of policy logic exist in a lot of other types of systems. What I think is going to happen around policies of all different types is there is going to be a need for policy federation. That's the future scenario.
Would this be part of the registry/repository, but separate from what was developed with Java or .NET?
Matsumura: Yeah. Because what we're really talking about is the ability to externalize policy. The point that is essential is that in order to automate and federate governance, which basically means in order to take someone else's concerns into account, you actually need some kind of system that allows you to manage that. And the system that allows you to manage that isn't the system that's contained within the system that created it. The metaphor is you can't really QA your own stuff. The system that created something can't be the same system that manages something because they're controlled by the same person. That's actually the wrong approach.
So what is the right approach?
Matsumura: The right approach is there are people who create things and there are other people that manage the things that are created. That's where you start to see the need for externalizing policies into declarative systems and manage these systems through systems of record. It's a complex argument but what I'm trying to say is there are rules and logic that transcend development.
Is the tooling to do policy by declarative construct is that available now, or is that something we're moving towards?
Matsumura: I think we're at the very beginnings of this art. What we've done is taken a few examples of these externalized enterprise logic scenarios, such as runtime policy. We've crafted very nice user interfaces based on things like Web browsers. And we've called the result something like policy system of record, registry/repository. But instead of saying lets make a way of declaring policy that's only meaningful to a developer, let's make a way of declaring policy that may be useable by a business unit constituency, someone who is sophisticated but not necessarily in development. That enables a lot more dynamic and agile change management. It's easier to change a parameter on a running service than it is to change the source code for the service, compile it, QA it and redeploy it.
In part two of this interview tomorrow looks at the future of SOA policy implementations that go beyond development platforms.
|
|
|
|
