Microsoft Vista is going to be generally available at a computer store near you on Monday, but if you are working...
in the service-oriented world should you care?
When Bill Gates unveiled the prototype of Longhorn at the Microsoft Professional Developers Conference in October 2003, he said it would be the big leap in operating system technology since Windows 95. It has taken the Redmond, Wash.-based software leviathan more than three years to make that leap. During that time the development cycle was interrupted to add security features to Windows XP. Eventually, Longhorn was renamed Vista, a metaphorical improvement more in keeping with the Windows simile, which also ended the "where's the beef?" and "bunch of bull" jokes.
Now that Vista is going to start appearing on the desktops of business end users and home consumers, if for no other reason than it will be loaded on almost any non-Apple notebook or desktop computer they can buy, does it really matter? Especially, for those working on SOA projects that are supposed not to care about individual operating systems?
We asked some thought leaders in the SOA world, and this is what they told us:
Why Vista matters: the short answer
Jason Bloomberg, senior analyst, ZapThink LLC.
The most exciting aspect of Vista in the context of SOA initiatives is the fact that Microsoft has essentially made the operating system into a rich client. In other words, Vista enables Web applications, portals, desktop applications and by extension mobile devices to be service consumers with rich user interfaces.
The secret sauce here is the combination of the three core foundational technologies for Vista: the Windows Presentation Foundation, Windows Communication Foundation, and Windows Workflow Foundation. Any developer in the Microsoft environment, whether in the enterprise or at an ISV, can leverage these technologies to build a full range of next-generation rich service consumers.
Why Vista matters: the long answer
Ron Schmelzer, senior analyst ZapThink
There's a consuming side of services as well. There's not just exposing service interfaces and all the backend and the messaging. We have to consider how we consume these services. Microsoft is positioning one of the benefits of Vista as being a strong service consumer, so you can build these rich Internet applications and have a native platform that is inherently capable of consuming and composing services. It's also not just Vista, but what is on top of it: Windows Communication Foundation, Windows Presentation Foundation, Windows Workflow Foundation. These make up what Microsoft calls the connected services framework. They are really building the operating system itself to be a first-class SOA participant.
It will help SOA developers who are already in the Microsoft universe. If you're building an application and you're trying to get that application onto as many desktops as possible, and at least some of those desktops are Microsoft based, Vista offers some improvement over Windows XP.
For example there is the Communication Foundation, which was formerly known as Indigo. Indigo was an abstraction of a number of existing Microsoft-based communications and messaging technologies. On the Windows platform, developers have a choice of as many as five technologies to make components talk to each other. You can use Microsoft MessageQ, ASP.NET, .NET Remoting, and COM+ among a variety of different options. So the problem was that there was no real consistency. One developer would use one middleware technology and another would use a different one, until it became very confusing. Microsoft decided to wrap all of these in one runtime layer, which was then called Indigo. Then the developers can tell Indigo what they want in terms of messaging characteristics, and Indigo will use the best messaging technology for those requirements. There's been some confusion because Gartner once called Indigo an ESB, but it's not a product. It's an enabling technology on the .NET platform. You could potentially take the Indigo/Windows Communication Foundations and put it on a specific hardware server and make it look like an ESB, but as far as using it on platforms other than .NET, I don't think that is going to happen.
As for developers working on the Java platform, Vista is not going to help them very much. The question is will Microsoft join the Service Component Architecture (SCA) and Service Data Object (SDO) initiative, which are an attempt to create a framework for service development that maps to an underlying infrastructure. It would provide common packaging for services, but to what extent will Microsoft participate in that?
Microsoft is adding value to its platform. It's not trying to add value to other people's platforms. That consistently has been Microsoft's position. You can use other tools and Microsoft will interoperate with those tools to an extent, but if you want to develop for the Microsoft platform, you have to take advantage of the Microsoft technology. You can't fault them for that. That is their business.
Microsoft's SOA problem
Dana Gardner, principal analyst, Interarbor Solutions
Microsoft has been demur about calling SOA SOA and that's largely because most definitions of SOA rely less on Microsoft client platforms and applications than on rich Internet applications or Web-based applications, which are predominantly standards-based.
Interestingly, developers like using .NET and Visual Studio, but they also like the idea of running applications, components and services with an ecumenical bent to the client and server platforms. Virtualization, Java VMs and Linux offer more choice on runtime environments, even when apps are built in VS.
When you move from a client-server computing paradigm to a Web- or services-oriented one, Microsoft loses some of its mojo -- which is the interdependencies between platform, applications and the tools that join them.
Microsoft has had to walk the open Web services walk and talked that talk too, but the SOA walk and talks may be a bit too risky for some in Redmond. On the other hand, SOA is real and Microsoft will have to watch the market carefully.
But so far, Vista does not make or break SOA as its largely being defined, and any older Windows or newer Windows apps can be and will be absorbed as services -- natively or not -- by broad-based SOAs.
The OS shouldn't matter but …
Tony Baer, principal analyst, onStrategies
In an SOA world, the OS "shouldn't" matter, but whenever it comes to interoperability, standards will only get you so far. As Tip O'Neill once said, all politics is local. Sure, there's WS-I, to ensure, for instance, that Microsoft's implementation of the SOAP standard (or whatever is covered under the various profiles) is compatible with BEA's, but ultimately success depends on whether the development teams have the right configurations at all layers of the stack to ensure that everything works.
SOA lowers the barriers to interoperability, but it doesn't eliminate them.
Vista's impact on SOA will be negligible
Miko Matsumura, vice president SOA, webMethods Inc.
The net impact of Vista will be negligible, as SOA primarily functions above the abstraction layer of the operating system.
OS level benefits such as Virtualization, Windows Communication Foundation (Indigo) and native XML formats via Office are already available to earlier Windows versions. Vista makes incremental improvements in reliability, security and interoperability, but it's not revolutionary from an SOA perspective. Many developers would have killed to see WinFS/Longhorn's structured persistence as part of a more powerful metadata and persistence strategy for the OS, but Microsoft killed WinFS, at least with respect to shipping it with Vista.