By now, you’ve probably heard some rumblings about Microsoft’s latest strategy to move their products and customers forward while leveraging the Internet. What began with “Information at your fingertips” has become “Information on any device, anywhere anytime.”
The technical underpinnings of this strategy have moved from OLE to COM to Windows DNA and now Microsoft .NET. In this article, we’ll look at what’s different about this new platform and why you should care.
This is the first of several columns by Tim Landgrave that discusses Microsoft .NET. Other columns will look at how it affects your engineering, development, and training plans and what you can do to be prepared.
NGWS: The .NET glue
The first major plank in the .NET platform is Next Generation Windows Services or NGWS. Using NGWS, Microsoft and its partners can develop widely available, customizable, and easily integrated services.
Microsoft touts its Passport service as the first example of NGWS. Passport, which is generally one of the most visited sites on the Internet, is never actually directly accessed by a user. The Passport site is an authentication service that other Internet companies can use to verify the identity of someone visiting their site.
For example, users signed on to Passport can automatically sign on to Hotmail or Instant Messenger without re-entering their userID and password. Purchasing sites like buy.com will allow a Passport user to make purchases without requiring additional authentication if the user is currently logged on to Passport.
From a user’s perspective, it makes browsing the Web easier and more transparent since they won’t have to re-enter IDs and passwords at every site they visit for customized content. From a developer’s perspective, it relieves them of the burden of creating their own authentication mechanism. They can just integrate the Passport authentication into their application, and customers then use the Passport facilities to support issues like name or address changes, password changes, security updates, 100 percent uptime, and so on.
While this is an important step in the development of the Web, it’s the concept that’s the most compelling. What if all sites were developed in such a way that anyone could imbed the site’s functionality in their application?
For example, what if you could write an application in which you could use the travel searching and booking resources of an Expedia or the purchasing resources of an Amazon, buy.com, or Staples? Since NGWS is built on Internet standards like HTTP, HTML, XML, and SOAP, new applications on any platform—not just Windows NT or Windows 2000—will be able to interoperate.
COM vs. .NET or Sun vs. Microsoft or UL vs. URT
So how will these services be developed and deployed?
One of two ways: using a Universal Language (UL) strategy or a Universal RunTime (URT) strategy. The Sun/Java camp promotes the use of a single, cross-platform UL with implementations of the interpreter for each computing platform. The problem with this strategy is that it forces companies to retrain their developers on a proprietary development platform (Sun refuses to release the language specification to a standards body) in return for getting the performance of an interpreted language.
For Sun and the makers of large, expensive, multiprocessor boxes, this makes perfect sense: Create applications that require lots of hardware.
The .NET strategy approaches the problem differently. Rather than force people to learn new development languages and strategies, instead encapsulate the common functions of a robust, scalable, interoperable, message-based transactional environment in a URT that any language can program against.
This approach also allows applications or components written in any language not only to interoperate with other components, but also for any component to be sub-classed by another component. This is the developer’s Holy Grail—reuse of prior work without requiring access to the underlying source code.
Detractors of the .NET strategy will point out that the URT will only be available on Windows CE, Windows 98, Windows NT, and Windows 2000. But they won’t discuss the 80 percent plus market share enjoyed by these systems or the built-in capability to interoperate with UL-based systems by using standards such as XML and SOAP.
Who is the consumer?
The other important point to remember here is that the ultimate consumer of these services is not necessarily a Win32-based PC. With the explosion of WAP-enabled cell phones, Internet appliances, and other ways of getting access to Internet information, it’s become critical for Microsoft to have a strategy for delivering this information.
The .NET strategy specifically addresses the need for common ways to develop server-based applications whose clients can be any system that has Internet access. What Microsoft hopes to accomplish with .NET is that future Internet-based services will be developed using Microsoft server platforms (like Windows 2000, IIS, SQL Server 2000, and Exchange 2000).
Microsoft’s .NET signals Microsoft’s recognition that the client will not always be a Windows PC. It’s a positive step for Microsoft and, more importantly, for the companies that have countless hours invested in the deployment of their platforms and the education of their technical employees.
How do you feel about Microsoft’s latest strategy? Does its new Internet-based platform represent the next big thing, or is it too early to tell? Give us your opinion. Send us an e-mail or post your comments below.