Some studies out and about of late have posed the question: Is Java a better path to Services Oriented Architecture [SOA] than .NET? That is the backdrop for a recent interview on SearchWebServices.com in which Software AG’s Miko Matsumura says, “For service development, both platforms have a lot of good stuff.”
“It may be preferable to treat policy via a declarative construct outside of either platform.”
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.
What do you think? Will the rush to virtualization help or hinder interoperability between .NET and J2EE?
SOA policy beyond Java and .NET - SearchWebServices.com