SOA Advisor
Microsoft's Absence
Microsoft is absent from the definitions process around SCA and SDO. Is it ready to pursue a proprietary approach for a pseudo-SOA?
- By Dana Gardner
- 05/15/2007
Back when Web services standards were being devised, Microsoft was head of the pack. It was one of the main supporters of the WS-* family of specifications that found a home at the Organization for the Advancement of Structured Information Standards (OASIS). Microsoft was all for "open" at the Web-interoperability level.
Now, a new series of SOA standards is headed to OASIS, ones that could create a whole market segment around SOA common programmatic principles. Microsoft, however, is absent from the definitions process around service component architecture (SCA) and its sibling, service data objects (SDO). That could mean that Redmond will pursue a proprietary approach to bake what I'd call pseudo-SOA into its operating system stack.
As John Bell, enterprise architect at Marriott International Inc., recently pointed out during a BriefingsDirect podcast, such a tack is not new to Microsoft:
"... Microsoft tends to build those kinds of capabilities [in] as part of the operating system. Other vendors tend to create them as standalone products and infrastructure pieces," Bell said. "If you're a small company, having it built into the operating system is a value to you; but in large, heterogeneous environments, that can be costly to you. ... If you look at CORBA versus COM and DCOM, it's the same story."
My question is this: Why is SOA interoperability any different than Web services interoperability when it comes to benefiting business? At its most basic level, SOA aims to make heterogeneity in IT systems an asset, rather than a liability. If Microsoft sees interoperability at the Web services level as a productivity benefit, why is standardized interoperability at a programmatic level, embedded within widely accepted SOA open standards, any less beneficial?
Shouldn't Microsoft be interested in helping organizations make best use of existing apps, data, runtime components and services? The Open SOA consortium of large IT vendors seems to think that reuse and extension of heterogeneous IT assets is a good idea, and one that won't put them out of business, either. If IT organizations think broad use of IT assets is a good move, they need to tell Microsoft about it. Now.
Community Feedback
Microsoft will listen to its users, but they must be forceful, vocal and committed. Recall the Microsoft-Novell Inc. agreement last year, which established better interoperability and management of newer Windows servers and Novell's SuSE Linux server distribution in the same environment. Microsoft heard its customers, who wanted to better manage Linux and Windows platforms together at a lower total cost.
If customers can convince Microsoft to reduce complexity in mixed Windows and Linux environments, why can't the same thinking apply to SOA at the programmatic and meta-data level? The danger here is that we all end up back in 1998, with two types of SOA implementations -- one open and standards-based, the other married to Windows. If you recall, 1998 was when competing Enterprise Java and Windows-centric approaches left developers and architects struggling to make the two camps work together. And that situation lead to the creation of the WS-* specifications.
Maybe it would be better to avoid the whole break it-fix it cycle, which seems based on Microsoft's desire to wager that its hegemony can be leveraged to dominate yet another chapter in computing.
For myself, I think SOA is different. By definition SOA is about avoiding another cycle of break it-fix it and moving directly to driving productivity and capabilities in the business.
Learning from the Past
The backers of SCA and SDO fear history may repeat itself. They say that SCA/SDO may do for standards-based SOA what J2EE did for n-tier distributed computing in the mid-1990s-enable an architectural approach that supports a variety of standards-oriented infrastructure vendors, while offering common platform porting ease to a new generation of ISVs, partners, suppliers, integrators and channels. All J2EE did was help spur a large Web, intranet, portal and e-commerce ecology of apps and services.
Microsoft, at the time, needed to respond, and did with .NET, Common Language Runtime and C#. And enterprises had to buy all of that stuff, too.
The SCA/SDO backers say they invited Microsoft to join their effort to adopt a programming-level standardization of SOA, rather than Web services-level interoperability. But members doubt Redmond has a real motivation to move .NET to a programmatic open standards level. SCA/SDO is nonetheless expected to make interoperability between .NET- and non-.NET-based services a natural and rudimentary aspect of SOAs, albeit at a higher cost due to Microsoft's separation from the pack.
It doesn't have to be that way. Tell Microsoft how you feel now.
About the Author
Dana Gardner is president and principal analyst at Interarbor Solutions, an enterprise IT analysis, market research and consulting firm. Gardner tracks and analyzes Web services, application-development tools and application optimization techniques. He is also the producer of the podcast series, BriefingsDirect.