Rosenberg: What Microsoft Doesn't Know About SOA

Loraine Lawson spoke with Dave Rosenberg, CEO of MuleSource, the leading provider of open source infrastructure and integration software.

Lawson: So. You're among those who feel Microsoft doesn't "get" SOA? Why do you say so? Do you think they don't get it - or don't want to get it?
Rosenberg: I would say that not only does Microsoft not get SOA, they purposely are trying to usurp the whole concept for their nefarious doings. Microsoft offers nothing in the way of architectural development tools or infrastructure that supports the ideas behind an SOA. The Microsoft architecture of .NET is not designed to be service-enabled and when you try to service-enabled it yourself - when you try to build the infrastructure so you can take advantage of reuse - you find yourself in a very customized system having defeated the purpose. If you look at Microsoft infrastructure, it's all about trying to lock people into their hegemony and SOA is all about giving control to the user.

Lawson: Did you see Microsoft's 100-something page thesis on SOA, titled "SOA in the Real World?"
Rosenberg: I can't tell you I've sat there and poured over every word. It's not unlike their "Get the Facts" anti-Linux campaign - it's simultaneously interesting and full of crap at the same time. What's interesting to me about Microsoft's approach is the obvious thing to do with SOA is to say, "Of course we have a strategy - here's what you do now and here's what we'll do in the future." What should've been very easy for them to say, "Yes we'll be a part of this and we want to start to think about our way of doing it," - that would be acceptable. Instead they take this bizarre approach.

There's no clear answer from Microsoft on what their vision for SOA is or how their products or things you'd buy from them would participate in a SOA. For that matter, there's nothing from Microsoft that would say to someone, "I should use these products for my SOA." All of a sudden, .NET went from being a language, to an application framework, to being a "Windows platform" again. Developers are quick to shun things that they don't trust and I think Microsoft sets the tone for how their development community thinks about larger-scale concepts and so far they've succeeded in making SOA confusing.

Lawson: So, is Microsoft's talk about SOA a barrier to its acceptance among developers?
Rosenberg: From what I can tell, they're not doing themselves any favors. The whole sort of wait-and-see approach is not great. What's interesting is developers do eat that Microsoft dog food pretty fiercely. They wait for Microsoft before they make choices. It's a challenge for architects in terms of being flexible and having agility in their work. If you look at IBM or BEA, it's very clear what their vision of SOA is. With Microsoft, it's just not clear.

I think some of that is related to the fact that .NET was not built to be a SOA or a services platform. They don't want a heterogeneous environment; they want the entire Microsoft suite everywhere. For instance, a couple of months ago, they were calling it service-oriented infrastructure. What is the rationale with not going with the industry standard terms?

Before I started this company, I was the CIO of a financial services firm. Initially, we had an all LAMP and Java infrastructure. Prior to my getting there, they outsourced the development of a .NET application. We went from having a highly scalable, flexible infrastructure that was able to consume data and services across the enterprise and added a .NET application into the infrastructure - it was a complete and utter silo. It was built around this framework that was not meant to go in a services direction, and we basically had to adjust everything else in the enterprise for this one application that couldn't align itself with the rest of the business. And that is the unfortunate side of what .NET has done to development. Conceptually, Java guys are more likely to understand the SOA model than the .NET guys are - developers are not trained to think about other applications in .NET. They aren't trained to think about wanting to consume or expose a service to another application. That has so far been a barrier to using .NET as a platform to do SOA.

For better or worse, this development style is what .NET developers live and breathe. If Microsoft doesn't have a component, it doesn't exist. But in the real world, you still need to solve that problem.

How can a company that in the know be so clueless about such an important concept as this? This is the world's largest technology company and it's proven to be completely impotent and useless with SOA so far.

Lawson: So, do you think this is a sort of marketing ploy by Microsoft or just because they didn't anticipate that SOA would take off?
Rosenberg: I think it's a bit of both. What I'd tell you is that they should embrace SOA. Open source, you can see why they don't embrace it - but SOA - they should say it's awesome and encourage it. It doesn't make a lot of sense. In the real world, we see people who have similar situations to the one I described, with one or two .NET applications they want to get on the bus (enterprise service bus). Does Microsoft give you an obvious answer? Kind of, but not really.

Lawson: How do you work a .NET application into a service-oriented architecture?
Rosenberg: You need some kind of interface to the .NET application - you could, for example, create an object that will talk with the .NET application. The issue is less about bringing .NET apps into the SOA as using .NET for SOA. The right way to build SOA is to have services exposed from the get-go. It's just not the way the .NET world builds their applications yet. We have lots and lots of users who take one of the available interfaces and extract the data from the .NET application using MULE and pass it into the bus that way. There's still a lot of EAI (enterprise application integration) going on related to .NET.

What Microsoft has gotten themselves into is this quandary of SOA being about services and protocols, whereas EAI was about connectors and ways to get data out of places. Right now, Microsoft doesn't have a great answer for either integration method. Their answer is to write a bunch of code.