SOA policy beyond Java and .NET

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 in which Software AG’s Miko Matsumura says, “For service development, both platforms have a lot of good stuff.”

But, looking beyond servers, or plumbing, Matsumura has a bit of a different view. In the interview,  he says:

“It may be preferable to treat policy via a declarative construct outside of either platform.”

He continues:

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 -

One Response to “SOA policy beyond Java and .NET”

  1. Paul H. Says:

    … there seems to be some confusion in the industry regarding “policy” - two phrases above exemplify the confusion: “treat policy via a declarative construct” and “a way of managing policy” … these phrases conceptually conflict with the perspective of “policy-based management” in which the elements of an enterprise/system are managed using declarative constructs - AKA policy.

    As for allowing enterprise/system configurations/behaviors to be managed by a policy-based management system, this does *not* prevent you from implementing those configurations/behaviors within the managed elements … all policy-based management does is allow you to treat like managed elements the same. For example, a Java Service Request Broker (e.g., Axis2) implements WSS configurations/behaviors one way whereas a Windows Service Request Broker (e.g. WCF) implements WSS configurations/behaviors another - a WS-Policy policy-based management system allows an operations person to express the abstract policy “All Service Request Brokers shall implement WS-SecurityPolicy profile X” and the policy-based management system translates this policy assertion down into configuration commands unique to the concrete Service Request Brokers (in this hypothetical case, Axis2 and WCF) … and the important thing to note here is that this works only when the configurations/behaviors in question are already implemented in all of the managed elements.

    That being said, intermediaries are just another type of managed element … let’s say your Service Request Brokers also include Groovy SOAP and SOAP4R - WSS probably isn’t implemented in these, and so you’d rely on SOAP intermediaries such as the WSO2 ESB to introduce WSS between clients and servers … again, all that the policy-based management system really does is translate the single abstract policy assertion down to the concrete configurations expected by the three managed element types: Axis2, WCF, and WSO2.

Leave a Reply