In-Depth

.NET: Microsoft's Enterprise Ticket?

Will .NET Framework bring Microsoft and true language-neutral development into the enterprise?

• By Jon Udell
• 04/01/2002

Even if your enterprise doesn't use Microsoft's stuff, which is highly unlikely, you're probably going to need to interoperate with it. The good news is that as .NET starts to roll out, you'll find that you can. Because principal components of the .NET Framework are already released, enterprise managers and developers need a basic understanding of its benefits and pitfalls.

Enter .NET
The genesis of .NET, according to Philip DesAutels, Microsoft's product manager for XML Web services, is often attributed to an internal memo from software architect Dave Stutz calling for a framework that would encapsulate best practices of software development. Chief among those best practices was componentization. Support for easy creation, deployment and use of components became the dominant theme of the Common Language Runtime (CLR)—the virtual machine (VM) at the heart of the recently released .NET Framework.

Unlike the Java Virtual Machine (JVM), the CLR was designed to be language-neutral and component-oriented. Any strongly typed object-oriented language can be mapped to the CLR. Modules written in any of these languages are, intrinsically, components. Packaged for execution in dynamic link libraries (DLLs ) and further packaged for deployment in assemblies, they deliver the binary cross-language interoperability of COM with radically less development and maintenance effort.

Once built, components can support two styles of integration, one homogeneous and tightly coupled (Windows platform, COM+), the other heterogeneous and loosely coupled (Internet platform, Web services). Like COM components, .NET components can be marked as transactional or pooled, or both. The means (access to COM+ services) and the end (scalable Windows-based enterprise systems) remain the same. What seems likely to change is the frequency of achieving that end. Lynn Robinson, a product manager for Webridge, a provider of hosted extranets, reports that ".NET handles a lot of the infrastructure we used to have to build ourselves, which means we can focus on app logic, not plumbing." Howard Keziah adds: "Object pooling, my God, how hard that was to manage under the old system, and now it's sort of automatic."

To play on the COM+ stage, a .NET module uses a piece of the .NET Framework called System.EnterpriseServices. To play on the world stage, the module can alternatively (or additionally) use System.Web.Services. In that case, the module can be marked as a [Web Service], and one or more of its methods marked as a [Web Method]. These simple annotations hide a welter of underlying complexity: Marshalling of objects to and from XML, implementation of SOAP (Simple Object Access Protocol) call/response logic, automatic creation of WSDL (Web Services Description Language) to simplify discovery and use of exported objects.

Note, by the way, that .NET-style coding is not the only way to export Web services. In version 1.5 of COM+, which shipped with Windows XP, a COM+application can be made directly into a SOAP-style Web service. There's also work underway to make SQL Server stored procedures, which hold a great deal of existing business logic, directly available as Web services.

Integration and Collaboration
From an enterprise perspective, the benefits of .NET's Web services orientation are twofold. It enables interoperability on the intranet, and collaboration across the Internet. The former, says Roger Sessions, should be the chief focus of most companies in the near future. Enterprise infrastructure is never homogeneous. A mixed bag of mainframe, Unix and Windows technologies is the norm rather than the exception.

Vendors on all sides, including IBM, Sun, Microsoft and BEA Systems, now largely agree on the core Web services "stack" which includes SOAP, WSDL and UDDI (Universal Description, Discovery and Integration, a directory for Web services). SOAP's interoperability isn't perfect yet, but it's good and getting better every day.

"I am thrilled with the progress," says Sam Ruby, a senior programmer with IBM who works on Web services infrastructure. "If I find a problem with another vendor's implementation and bring it to their attention, I don't get a defensive response, I get an enthusiastic thank-you for identifying a problem." Even Microsoft? Absolutely, says Ruby, an answer that bodes well for any company adding Microsoft pieces to its enterprise puzzle.

The second benefit of .NET's Web services focus, extra-corporate collaboration, is less interesting to Roger Sessions. "The idea of SOAP transactions among different companies over the Internet is a distraction," he says. "We need to make the systems within a company work together first." Clearly enterprise application integration behind the firewall is an urgent priority.

But others see cross-firewall collaboration as vital, too. "There are going to be lots of private VPN-like exchanges among companies," says Sam Ruby, "and it would be very nice if we could do that on standard protocols without requiring the same infrastructure." For Microsoft's Philip DesAutels, it's about going beyond point-to-point integration, in which SOAP is just a less proprietary version of earlier remote-procedure-call protocols. Rather, he says, let's create a "rich ecosystem" in which network effects can multiply. He cites Metratech, whose XML-centric software handles billing for telecommunications companies and next-generation service providers, as "a company that really gets Web services."

Jim Culbert, Metratech's VP of technology, says that he's talked to major carriers who are "spending billions on multiple OSSes [Operations Support Systems], and have to manage all of them, but there are no common components, no cleavage points, there's no middle ground for data." In a traditional enterprise system, he says, software encodes a set of fixed requirements, and when requirements change, the software must also—a slow, painful and risky process.

Businesses that offer flexible services, and that are enmeshed in increasingly dynamic partnership webs, need the kind of speed and flexibility that only a more data-driven approach can deliver. Using Metratech's solution, a service aggregator who wants to add a new partner doesn't write software to make it happen. Rather, the new relationship is expressed as a stream of XML data that feeds into the existing, unmodified billing kernel.

In either case, for internal integration or external collaboration, the magic lubricant is XML. It's used to describe both procedural interfaces and data formats. This does not mean fewer interconnect points or data formats. That complexity is an irreducible fact of enterprise systems. What XML does, Culbert says, is represent complexity in a way that machines can process much more cost-effectively, and more accurately, than humans can. In principle, this benefit was available years ago, using CORBA (Common Object Request Broker Architecture). In practice, CORBA never reached the critical mass that XML is achieving, thanks to XML's inherent simplicity and to the rich assortment of off-the-shelf tools that can, as a result, support it.

.NET Vision Meets Reality
Microsoft's broad and deeply-layered enterprise strategy overloads the term ".NET" to the breaking point. It's hard, but useful, to unravel the many meanings. The Common Language Runtime, at the core of the onion, aims to simplify the componentization of software. The resulting components can more readily exploit existing COM+ services (the "democratization of the middle tier"), and at the same time can play in the emerging world of XML web services.

The .NET Framework, analogous to the Java/J2EE class libraries, continues the long Microsoft tradition of the 80/20 solution—that is, it aims to deliver 80 percent of the best practices that programmers should master, while requiring 20 percent of the knowledge and effort. It's fascinating to note that this doesn't only make programming grunts more productive.

Managers and software architects, who haven't actually programmed for years, find they can now sketch prototypes in software rather than on whiteboards. "I'm primarily a prototyper and designer," says Impact Technologies' Howard Keziah. Exploring ideas was a prohibitive exercise when it meant mastering the details of COM and network plumbing. Now that the .NET Framework relieves much of those burdens, he says he can once again directly model the software his teams will implement.

For users of the .NET Framework, Visual Studio.NET will be the toolkit of choice. Here too, the aim is to make the plumbing easy or automatic, so that programmers can focus on business logic.

But not everybody buys into Microsoft's ease-of-use mantra. Roger Sessions, for one, is skeptical. For experienced enterprise developers, he doesn't think that .NET is compellingly more productive than J2EE. And it isn't portable, of course, since it requires Windows as a deployment platform. (Emerging alternatives remain unproven, including Unix/Linux ports of the CLR and Framework, and Java-based emulators like Halcyon Software's iNET.)

But where Windows is an acceptable platform, Sessions says, the cost of a .NET unit of work is far less than the cost of a J2EE unit of work. He's bullish on performance too. "The few benchmarks we do have," he says, "appear to favor the Microsoft platform by a wide margin."

Even so, Sessions discounts Microsoft's technology as a key factor in its enterprise adoption, or lack thereof. "How do you sell in the enterprise?" he asks. "How do you deliver consulting services and support? These are the roadblocks, not technology."

At least this much is clear. Whether or not Microsoft's .NET and Web services initiatives find near-term traction in the enterprise, the elements of the strategy—componentization, access to the middle tier, XML representation of business data and protocols—are universal and will matter to everyone. Even if you don't use Microsoft's products, you'll likely need to interoperate with it. As .NET starts to roll out, you'll find that you can.