Navigating the Waters of Web Services With .Net
To call Microsoft's .Net architecture significant and ground breaking invites instant and often vehement feelings. Yet some important .Net products are scheduled to appear in the first half of 2002, and with their release comes the reality that Web services are beginning to appear on the horizon of those who operate Web sites and Web servers.
Thus, with this tutorial we aim to highlight what to watch for in .Net during the coming months.
The thrust of the Web services concept is to create applications by stitching together components (objects) from various sources on the Internet. Different companies may produce each component, but Web services protocols will ensure that these components interoperate. Likewise, each component will be priced separately, usually in some kind of leasing or rental arrangement. (See our tutorial, The Web Services Value Chain for a detailed discussion of the fundamentals of Web services.) On or off the Web, this is a new model for applications, and it has profound implications.
For one thing, developers must pay much more attention to how seamlessly a Web site can be integrated with another Web site. Servers and applications will have to be adapted to the needs of security, performance, and complexity found in distributed applications.
Will every Web server be involved with Web services? Although this is difficult to predict because it depends on the success of Web services, it's safe to say, probably not.
Will it be possible to ignore Web services? Again, probably not.
And the same can be said for Microsoft's .Net. Whether an enterprise chooses to adopt Microsoft's approach, as this particular gorilla wades into Web services, most of the world is likely to follow.
An Eye on the Standards
While developing .Net and related products, Microsoft has scrupulously (for Microsoft, anyway) employed Web standards. Even if you are not planning to embrace .Net, it is important (and perhaps vital) to keep an eye on developments in:
- XML (Extensible Markup Language)
- UDDI (Universal Description, Discovery, and Integration)
- WSDL (Web Services Description Language)
- SOAP (Simple Object Access Protocol)
Some of these protocols have other uses, but for the next several years Web services will dominate much of their use and development. These standards are the reason people feel Web services have a much better chance for success than previous distributed application schemes (e.g., CORBA and DCOM). Adherence to standards will determine just how well Web services components can really interoperate.
Of the four standards, UDDI is a particularly important bellwether because it will be used to create Web services registries (directories). UDDI also specifies how a browser or server can go out on the Internet and locate a desired Web service from the registries. The contents of these registries, how they are reached, and how efficiently they lead to using a Web service will have a lot to do with the success of the Web services concept.
Get Out Your Wallet
The .Net architecture is comprehensive -- close to breathtaking. Under this voluminous umbrella, Microsoft is gathering a large number of products. Some of these are its own, but many are from a raft of partner companies.
Buying into .Net will require buying a suite of products. And in remaining true to the Web services concept, an enterprise will likely buy, lease, or rent each product separately.
Until the Web services themselves are developed and ready to be released, most of the Web services products will be related to the creation and deployment of the services. The main product is currently Microsoft Visual Studio .Net, which contains programming languages and many other tools (e.g., .Net Framework), geared to the creation of Web services. Although they will not be required by Visual Studio .Net, Microsoft is also preparing its various server offerings (e.g., BizTalk) to provide complementary features for deploying Web services.
Another important element of .Net is packaged under the title HailStorm. HailStorm contains a set of services, such as notifications, e-mail, calendaring, contacts, and an electronic wallet, designed to improve communication and management of data between various platforms (i.e., PC, portable, and pocket). HailStorm has raised its own storm of protest over its potential for invasion of data privacy -- just one of several issues that will affect Web services.
C# or Java
One of the unfortunate realities of the ongoing Microsoft vs. Sun feud is that .Net will not incorporate Java as a primary programming language. Instead, Microsoft has developed C# (C-sharp) as an alternative (and very similar) language. Choosing .Net will probably mean also choosing C#. However, within the environment of Visual Studio .Net, C++ and Visual Basic will also be .Net compatible.
Adding Application Servers
Outside of relatively trivial uses, it's clear that an enterprise implementing Web services will probably require additional servers. For a while, most of these servers will be what we generically call application servers (see our tutorial "Web Servers vs. Application Servers: Making the Right Choice" for more information about using Web servers and application servers).
Application servers are the dedicated aggregators of data and processing for Web servers. They will play a key role in marshalling and managing Web service components -- a job that is too complex for the current generation of Web servers. Microsoft is weaving .Net features into BizTalk and other servers, and while this doesn't rule out using other application server products, it does give Microsoft an obvious advantage.
Three Points to Consider
- Web services are an unproven concept both technically and commercially. Even with the hype flying high and all the major software companies seemingly convinced of the righteousness of Web services, they are a long way from reality. In other words: Web services might not turn out to be quite the be-all, end-all they are being portrayed as.
- Microsoft's .Net is going to have stiff competition from Sun Microsystems, IBM, and other vendors in the Java camp.
- Microsoft does have a head start. By the end of the first quarter of 2002, many of the major initial elements of .Net will be in general release -- not just in beta or prototype versions. Likewise, many partner products will also be released. Microsoft began developing .Net back in the days when people were taunting it for being late to the Internet party. It's been serious (as in making money) about Web services for several years. The early reports on .Net elements indicate that Microsoft's ambitious scheme is, at a minimum, workable. And it is quite possibly better than that.
Thus, even those who don't like Microsoft (and enterprises that refuse to use its products) will be making a serious mistake if they underestimate the impact of .Net on not only Web services but also Web applications in general.