|
Wednesday July 04 2001 Microsoft and Web Services Caught in the .NET Microsoft has arguably the most coherent and finely tuned Web Services strategy of any of the large technology companies. In this article, I'll explain what I think Microsoft is doing, why they're doing it, and how they intend to pull it off. Microsoft.NET Back in June 2000, Microsoft announced something called "Microsoft .NET". This is perhaps the most ambitious project Microsoft has undertaken, with a marketing campaign to match. Microsoft is pitching .NET as "a platform for Web Services". They are proposing that if the user wants to build Web Services, or even just use Web Services, the best platform out there to do that is Microsoft.NET. Whether the key decision makers come to agree with them remains to be seen, because .NET is not slated to reach a final release until sometime next year. However, a big part of the reason why building Web Services is easier with .NET is because it is easier to build all kinds of applications with .NET. Microsoft have managed to "get into the minds" of their developers and create a set of tools and technologies that make it far easier to build complex applications than ever before. In reality, .NET is about much more than just Web Services, so why is Microsoft pushing it as a technology for building Web Services? It's not to hide the true purpose of .NET, which is simply to ensure that Microsoft still exists in twenty years time (even an amateur Microsoft "watcher" can hypothesize that). Rather, Microsoft recognizes that other software companies, consultants, and technology evangelists are going to start heavily promoting Web Services. They want a vehicle in place ready to take these early adopters to market. To put it simply, they want people to think, "Hey, we need a Web Service. I've heard .NET is really good for that." .NET is in fact more than just a 'key technology' for Microsoft, because without it - or something very similar - they would be under threat from another platform coming along to usurp Windows. The presence of the .NET strategy reduces this threat, as it potentially allows every developer in the industry to use it, regardless of preferred platform or language. In many ways, the whole .NET strategy is too big for a simple and effective marketing message, and so what we see is Microsoft hyping up this particular part of .NET. The Web Services technology in .NET is relevant enough to be of interest to the industry watchers, and because it's interesting, .NET will gain a lot of coverage in the press. In addition, it's at a point today where it's useful enough to start delivering real results to the people implementing Web Services with it. The logic of all this is that by getting people to buy into the "use .NET to build Web Services" sell they will be able to convert those people into the "use .NET to build everything" sell, which is ultimately where they want to be. Codename: Hailstorm The first commercial Web Services that Microsoft will make available are currently known by the codename "Hailstorm". Microsoft have made no bones about the fact that they will turn Hailstorm into a considerable source of revenue for the company - this is not a free service that they're throwing out there to see if it works. From day one, they are confident that they can make money from it. You should look upon Microsoft's confidence that Web Services will work as a sign that Web Services will indeed change the face of software development as we know it today. Web Services Architect has already covered Hailstorm in a previous article by Johann Dumser, but in short Hailstorm is a set of fairly obvious services that a lot of software will use. They provide things like a central store of a user's personal information, a way of authenticating themselves to different web sites and applications (this is currently known as "Passport"), a way of centrally storing pictures and documents on the Internet so they can be accessed from anywhere, and so on. It's expected that Hotmail, the phenomenally successful Web-based e-mail service, and Windows Messenger, will also become part of Hailstorm. Developers wanting to build web sites or applications that use these services will be able to do so through a Web Service. Imagine that you want to buy something from an e-commerce store. On a typical web site today, you'd have to enter all of your personal information in order to place an order. With Hailstorm, the owner of the site can integrate authentication services and an electronic "wallet". So, even if the customer has never bought from you before, she can visit your site, authenticate herself with Hailstorm and you (as the web site owner) will be able to perform the transaction. From the perspective of business, this is a great advance because it means a site can be engineered with less work. The developers no longer have to worry about authenticating the user, or providing a safe and secure way to capture credit card information - Hailstorm does it all for them. From the perspective of Microsoft, Hailstorm is also a great idea. Historically, Microsoft has had considerable success with technologies that make life easier for developers. It's highly likely that developers will adopt Hailstorm in droves. The first thing this does is provide Microsoft with a new revenue stream - although we all know that Microsoft has a proven track record of making money, it never hurts to find new ways to make it. The second thing it does is promote Microsoft as being a company that really understands Web Services. This is likely to have the effect of drawing developers to Microsoft's way of doing things, thinking "if Hailstorm is based on Microsoft technology and is so successful, and I base my solutions on the same technology, I could be just as successful". The third and final thing it does is get people used to Web Services and the whole software-as-service paradigm. Microsoft needs consumer confidence in this to be high in order to move people away from the current, physical software distribution model to a rental model, something they are keen to develop for other products such as Office XP. Web Services, Today Microsoft have made available the "SOAP Toolkit" that enables developers to start building Web Services using the familiar "Windows DNA" technology. This is based on all the products and technologies that have been around for a long time, things like COM, Visual Basic 6, Visual C++, Windows 2000, and SQL Server. Microsoft does recognize that it's going to take the industry a long time to move to a position where .NET is dominant - if indeed it ever does. The SOAP Toolkit has been released to ensure that developers wishing to build Web Services, but who do not wish to move over to .NET, won't have any motivation to leave the Windows platform. Although building Web Services with the SOAP Toolkit is not as easy as developing them with .NET (as the SOAP Toolkit is based on older, but tried and tested, Windows DNA technology, developers don't have access to the great new tools and technologies that are part of .NET), the SOAP Toolkit does allow developers to build Web Services, and to build applications that use Web Services owned by other organizations. Developers can download the SOAP Toolkit from the Microsoft Developers Network Finally... UDDI The final part to Microsoft Web Service strategy is UDDI. This is an on-going topic of discussion on Web Services Architect, mainly because it's a great idea in need of support from the industry - support that has not been coming, so far. UDDI provides a way for companies to find other companies that expose Web Services. The current UDDI initiative was founded by Microsoft, IBM, and Ariba, and it's looking like Hewlett-Packard and others will be joining the party. Conclusion In this brief article, I have outlined four ways in which Microsoft are engaged with Web Services. There are more, particularly in the future of the popular Web property MSN and the way that the giant Microsoft.com web site works under the hood. The important message to take away is that, for now, Microsoft are backing Web Services technologies 100%. Read Matt's other article for Web Services Architect: Web Services 101. |