Every couple of years, Microsoft Corp. hoists a flag to rally the troops. Win32, OLE, Component Object Model (COM), ActiveX and Windows DNA would, we were told, revolutionize the business of creating and deploying software. Because these campaigns addressed important issues, they were greeted with a measure of enthusiasm. Because they entailed risk, uncertainty and retraining, they were greeted with an equal measure of weary skepticism.
So it is for the new campaign, which is called .Net. But this time, enthusiasts appear to outweigh skeptics. Everyone agrees that business applications and network services are becoming the same thing. IT has learned, and will never forget, the lessons of the first-generation Web: open standards, universal access, rapid development, continuous deployment.
Now the second-generation Web is being constructed, and Microsoft is determined to be one of its architects. Chastened by its failure to catch the first wave and challenged by the thriving open-source and Java communities, it's put together a compelling strategy. It aims, as usual, to deliver tools and environments that take care of plumbing so the majority of developers can focus on creating the applications they're hired to build. Here's a blueprint for the second-generation Web from a .Net perspective:
.Net uses XML for universal representation, exchange and storage of all kinds of data - and, in particular, to describe and manipulate component interfaces.
Today, components come in many flavors: shared libraries, script language modules and application-specific plug-ins. Component models like COM and Common Object Request Broker Architecture (CORBA) make code reuse among these flavors possible but not easy, so it often doesn't happen. .Net aims to make component construction and reuse so easy that there's no excuse not to do it.
In theory, objects created by object-oriented programming (OOP) languages are components. In practice, the languages' object models don't match cross-language component models like COM and CORBA. The .Net Common Language Runtime, a universal OOP engine, aims to solve this problem.
Because all .Net languages share the same object model, an object written in any language is automatically a component available to all others.
A bonus: OOP-style inheritance works across component and language boundaries.
Every programming language comes with standard libraries - called frameworks in the case of OOP languages - that encapsulate common code and define patterns for using it. The Java Development Kit's class libraries are such a framework. The .Net framework covers similar ground but in a language-neutral way. C#, Visual Basic.Net and other .Net languages are only lenses through which programmers see the same underlying framework.
Simple and open protocols let the first-generation Web scale up beyond most people's wildest expectations. Web protocol HTTP, carrying an HTML payload, brought client/server applications to the masses. On the next-generation Web, HTTP will also carry various XML payloads. Most notable among these is Simple Object Access Protocol (SOAP), which enables n-tier applications made by interconnecting network services across programming-language and platform boundaries. The .Net technology works hard to make it easy for developers to make and use components with SOAP interfaces.
In the n-tier environment, a network service has to juggle connections to users, data and other services. Windows NT and 2000 already supply basic middleware (Microsoft Transaction Server, or MTS, and COM+, respectively) for pooling and transactional control of these resources. The .Net platform doesn't invent new middleware. Instead, it aims to generalize and further simplify the use of existing COM+ technology.
Developers rely on tools that can capably build, debug and deploy software. Today, these tools are language-specific. But projects aren't. A first-generation Web service will likely involve several kinds of components and several flavors of glue. There are tools for building, debugging and deploying these various pieces, but there hasn't been one that comprehends the whole. That is what Microsoft hopes to achieve with Visual Studio.Net. Leveraging the universality of the .Net framework, runtime and languages, it gives developers a single interface through which to manage multilanguage, multicomponent projects.
The Next-Generation Web
These broad strokes paint a picture of software development for the next-generation Web. Some aspects have been known for a while. XML interfaces to Web services have been in use for several years. Many languages support XML-RPC and are now starting to support its successor, SOAP. Savvy Web developers are already using XML to isolate business logic from presentation and to offer interfaces to partner services.
Nobody needs to wait for .Net to do these things, and nobody should. Services built this way will interoperate now, no matter the platform or implementation language, and they will interoperate with .Net.
Using XML Interfaces
One early adopter of the XML interfaces strategy was New York-based Zagat Survey LLC, whose Web site delivers reviews of thousands of restaurants in dozens of cities. Zagat's content flows to browsers and Wireless Application Protocol (WAP) devices. The two presentations share a common XML layer, according to Chief Technology Officer Steve Forte. "Our wireless app calls all the same stuff, on the same server, as does our HTML app," he says. But while this architecture made a very clean WAP implementation possible, it didn't eliminate the need to write the XML-to-WAP translation by hand. That is one of the conveniences promised by .Net. "I would have loved to do the model once and have it automatically rendered into either HTML or WAP," says Forte.
Zagat has very specific plans for its first SOAP implementation. Today, Zagat links from its pages to a partner site, OpenTable, which offers a dining reservation service. This works, but Zagat would rather keep customers on Zagat.com and connect them to OpenTable behind the scenes. Again, this is entirely feasible today. OpenTable need not wait for .Net in order to produce an XML interface to its reservation service, and Zagat need not wait for .Net in order to use that interface.
What .Net will offer Zagat is mainly the convenience of tools and an environment that together reduce the friction involved. That's no small thing, though. Web services will create network effects in proportion to the number of them that exist. Helping developers get over the activation threshold is a big deal.
Domenick Branciforte, enterprise architecture manager at Royal & Sun Alliance Insurance Company of Canada in Toronto, is another .Net evaluator who's excited by the prospect of pervasive Web services. Today, he notes, portals are used to aggregate diverse services. For example, employees use an intranet portal to access corporate information services. They go to Yahoo Inc.'s or Fidelity Investments' sites to access external services. "Portals bring information together," says Branciforte. "But then we have a proliferation of portals, so what did that solve?"
Branciforte says he wants to create direct business-to-business connections between his company and partners such as the Department of Motor Vehicles. To the extent that services are available through conventional portals, this is possible today. "But when you find yourself doing HTML screen-scraping, it's a warning sign, a symptom of a bigger problem that you should solve," Branciforte says.
He says it's significant that in Visual Studio.Net, the creation and use of Web services is "a cornerstone, a given." This isn't rocket science, he points out. Like the Internet's core protocols, SOAP is pretty simple, and that's good. "This wasn't the time for Microsoft to get fancy," he adds. "It was time for Microsoft to get simple."
Breaking Some Eggs
Benefits of the Web services strategy are clear, and they're available now. Benefits of the .Net common language technology are equally clear but less immediate and less certain. The .Net platform is a work in progress. And to programmers now using Active Server Pages (ASP), Visual Basic Script, Visual Basic and C++ skills, it presents a very different paradigm. Visual Basic.Net, for example, departs dramatically from earlier versions. It approaches object orientation, components and exception handling more like the new C# than any previous Visual Basic. But like all .Net languages, Visual Basic.Net and C# are only ways of accessing the Common Language Runtime and .Net Framework.
Is there any real benefit in having different views of the common core technology? Branciforte says yes. "We have 175 VB developers," he says. "Does C# offer anything that VB.Net doesn't? We think not." While the new Visual Basic is very different, its family resemblance will help those developers leverage their existing skills.
But nobody is underestimating the scope of the impending transition. "I don't think anybody's going to be converting any major VB applications," says Bill Zack, a consultant who has been building enterprise applications for decades. "Instead, you'll see new stuff happening on .Net."
Zack says he's eager to get started. "We're well aware of the fragility of interpreted VB Script pages, because of the lack of strong type checking," says Zack. He'd also like to forget about the awkward and labor-intensive mechanisms in current Visual Basic dialects for handling exceptions.
Forte says Microsoft's readiness to break backward compatibility is encouraging. "For years, they've been hindered by that," he says. "Now, they're finally willing to break some eggs in order to make an omelet."
Pros of Common Language Technology
It's no accident that robust exception handling ranks high on everybody's list of desirable .Net features. That and automatic memory management are two of the things that have made Java the current favorite platform (and language) for building network services. When applications become constellations of communicating network services, a lot can go wrong. Managed memory eliminates a whole class of common problems that compromise both reliability and security. For example, buffer overflows that let hackers break into conventional systems become manageable exceptions in Java virtual machine- or .Net-based systems.
In the case of Java, of course, the language is the platform. There is comprehensive exception handling only when a whole system - components and glue - is 100 percent pure Java. One of the most compelling aspects of .Net is the prospect of unified exception handling across an entire heterogenous system. Already, in the .Net beta, an exception thrown in one language can be caught and handled in another. Since component builders and solution builders are often different people using different languages, there's theoretically a huge reliability benefit to be had by wrapping a common exception handling framework around these two domains.
Here's another interesting, though as yet unprovable, benefit: Today, when companies are hiring, they advertise for Java, C++ or Visual Basic programmers. But really, they're looking for experts in insurance, electronic publishing or medical records. Today, domain expertise is hard-wired to programming-language expertise, but it really shouldn't be. A developer of business logic for the insurance industry should be a domain expert, versed in the rules of the business and in the software components that implement those rules. The language used to express that domain expertise - in the form of components or of glue - shouldn't matter much.
This separation of domain expertise from programming-language expertise is a long-range goal that won't be achieved anytime soon. For Forte, though, it's something to look forward to. "We've had bitter debates," he says, "because one guy thinks he can do it better in Delphi, and another guy wants to use C++, but in the end, they both had to use VB." Forte says he hopes this my-language-is-better-than-yours bickering will finally just go away.
Getting Ready for .Net
At Royal & Sun Alliance, Branciforte's team has been preparing for .Net by shoring up the Windows infrastructure. That means upgrading from NT 4 to Windows 2000, moving from MTS to COM+, and ensuring that Internet Information Server 5 is "in place, optimized and understood." Its first .Net pilot project will probably be a business-to-business Web service.
Zagat.com has aggressive plans to launch a new hotel-rating site, based on .Net, as early as June. Forte says early indications are promising, but a .Net deployment will be contingent on stress-testing that hasn't yet been done. "If .Net explodes and shoots off sparks," the main site will be unaffected, and the new one could fall back to conventional Visual Basic/ASP, says Forte.
Pilot projects are the next logical step for every IT shop using current Microsoft Web technology. The .Net campaign is advancing on many fronts, and its ramifications are going to take a long time to sink in. There's a lot to learn, but developers think that the leverage afforded by .Net will more than repay the effort.
Will .Net produce a new kind of Microsoft monopoly? For Web services, the answer is clearly no. Microsoft doesn't own SOAP or related standards. For example, Web Services Description Language - which documents the "contract" between the producer and the consumer of a Web service - is sponsored by Ariba Inc., IBM Corp. and Microsoft.
For the Common Language Runtime and ASP.Net, the answer is yes, until and unless these technologies are ported from Windows to other platforms. Although Microsoft has submitted draft standards for C# and the common language infrastructure to the ECMA standards body in Geneva, there is no guarantee that the core .Net technology will show up elsewhere than on Windows.
If you're already a 100 percent pure Microsoft shop, that won't matter. Otherwise, you'll want to watch and wait for the open-source and Java communities to rise to the challenge. The second-generation Web will emerge in many forms. All of them, though, will likely be influenced by the .Net blueprint, which is remarkably clear and complete.
Udell is an author and independent Web/Internet consultant in Keene, N.H. Reach him at email@example.com.