Preparing for Indigo-Choosing the Right Technology Today

Indigo is the next generation application connectivity and services from Microsoft, superseding the variety of .NET connectivity solutions available today: ASMX Web services, Remoting, and Enterprise Services. Since .NET debuted some five years ago, all three technologies have been inundated in either hype or misconceptions. With Indigo around the corner, it is time to take a long hard look at these three technologies, and separate fact from myth so that you will be best prepared for Indigo. This article starts by examining the existing technologies, describing their merits and shortcomings, putting them in the correct perspective of a modern distributed application, and suggests where to best apply them. Then the article briefly describes the Indigo programming model, and assesses how to best mitigate the cost of the migration.

Crossing Boundaries with Web Services

Web services are a generic name used to describe method invocation using a text-based protocol over HTTP. Web services are not synonymous with SOAP - most non-binary, text-based protocols such as HTTP GET or HTTP POST could qualify as Web services. Web services are not specific to the Web and are often used by intranet-based applications. In fact, today, most deployed Web services actually are used in the context of intranets. The architecture of Web services is simplicity itself - a Web server such as IIS receives a request over HTTP. It is then up to the Web server to interpret that request. In .NET, a request for an ASMX page causes IIS to load a corresponding Web application in a worker process and let a set of .NET DLLs use a class associated with that ASMX page to handle the request. This architecture is shown in Figure 1. .NET does the conversions from the request payload (often in SOAP XML) to Web method calls. .NET is also responsible for converting returned values from managed types to standard text-based representations. Under .NET 2.0, the Web server need not even be IIS - any running process can easily become a HTTP requests handler.

Converting types to and from text representation has a performance penalty, but more important is the limitation on the expressiveness of the types you can expose on the Web service methods. In addition, using HTTP as a connectionless protocol imposes certain restrictions on the object model, as it is best-suited for single call objects. Maintaining state is usually confined to a session.

Because Web services themselves are based on simple text-based protocols, they lack the ability to support high level business semantics. With respect to security, raw Web services have no support for propagating security call context, single sign-on authentication, credential management, impersonation, and so on. Web services do not flow transactions, and there is no way using raw Web services to comprise a few Web service calls into a single logical transaction. Web services lack concurrency management so they leave developers susceptible to distributed deadlock and hard to resolve reentrancy issues. To address these issues, you need to implement complex emerging standards such as WS-Security or WS-AT (Atomic Transactions). Since most of these emerging standards are still, well, emerging, anything concrete you do now is likely to be proprietary and couple the service provider to the service consumers. In addition, extending Web services is a notorious task, and while .NET makes it easier than other platforms, it is still not a job for the faint of heart, and well beyond the reach of most developers.

The reason organizations and developers are willing to put up with these shortcoming is interoperability. Since Web services cater to the lowest common denominator (text over HTTP), virtually every operating system, Web server, and development technology can expose or consume Web services. Imagine a .NET client that wants to interact with a J2EE component. Neither one of these technologies support natively calling the other, yet both support Web services, so you can use Web services to interoperate between the two. C++ components on Windows can use Web services to interact with C++ components on Linux. In general, any kind of technology boundary, from operating system to development language can be bridged using Web services.

The presence of a firewall poses another kind of a boundary; a trust boundary in this case. Fortunately, since all that is exchanged between the Web service provider and the Web service consumer is text, most firewalls will allow Web services calls by default. In general, you can use Web services to cross all types of boundaries: technological, trust and security, deployment topology, organizational, geographical, and so on.

By: Juval Lowy

Juval Löwy is a software architect and the principal of IDesign, a consulting and training company focused on .NET architecture consulting and advanced .NET training. This article contains excerpts from his latest book (Programming .NET Components 2nd Edition (O'Reilly, 2005). Juval is a frequent presenter at development conferences and Microsoft's Regional Director for the Silicon Valley.

Over the last three years Juval has been part of the Strategic Design Review process for .NET 2.0.

Microsoft recognized Juval as a Software Legend as one of the world's top .NET experts and industry leaders.

Contact him at www.idesign.net