Developing for .Net

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.


In every programming environment, there's a division of labor. A few people make the components that many others glue together. Components are often written in compiled languages such as C and C++. The glue is usually a scripting language, ideally one supported by an integrated development environment. The first-generation Web is bound together by glue languages: JavaScript, Perl, Python, PHP and several forms of Visual Basic. But it's also balkanized into glue-language communities. One .Net goal is to universalize the glue - making components, plus the knowledge and the tools to use them effectively - available to solution builders, whatever kind of glue they prefer.


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 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% 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.

1 2 Page 1
Page 1 of 2
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon