.NET* Application Server Fundamentals for the Enterprise

By Matt Gillespie

The Microsoft .NET* application server that is incorporated in to Windows* Server 2003 provides a robust, flexible, and secure environment for the deployment of enterprise applications on Intel platforms. By supporting a wide variety of other application environments, it provides the flexibility that enterprises require in order to make best use of their existing code base, to accommodate new business partnerships, and to leverage developer expertise most effectively. By supporting Intel® platforms, the .NET application-server environment provides IT managers the flexibility of choosing server equipment from a wide array of OEMs.

This article is focused toward the concerns of IT Managers and decision makers, and to a lesser extent, solutions architects and developers. It will demonstrate the .NET application server's robustness and forward-looking suitability for the deployment of large-scale enterprise applications. It particularly addresses issues of the .NET application server's interoperability with Java* and legacy technologies and introduces some of the capabilities that the next generation of Microsoft Visual Studio*, code-named Whidbey, will bring to the application-server environment.

One key aspect of the interoperability of the .NET application server with Java 2 Enterprise Edition* (J2EE) components is the full support for Web services standards by both the .NET application server and the major players in the Java application server market, including BEA WebLogic* and IBM WebSphere*. For a comparative introduction to all three of these application servers, see another article in this series, "Overview of Enterprise-Class Application Servers."

By means of UDDI, SOAP and other Web-services standards, Web services components created in .NET and those created in Java can interoperate directly within a single application without being changed from their native environments. Thus, a .NET application server can host an application that directly incorporates J2EE components from multiple Java application servers in the same enterprise or across the Internet.
Outside the Web services context, interoperability between .NET and Java application servers is also well-supported, albeit rather more complex. The fundamental challenge in providing interoperability between .NET and Java application servers lies in mapping data types from one platform to the other. The simplified scenario in Figure 1 shows the server architecture for an application that uses presentation logic based on ASP.NET* to support the user interface and business logic based on Enterprise Java Beans (EJBs)* to access data from an enterprise back end:



Figure 1. Sample implementation that requires .NET/Java interoperability.

In this scenario, for the presentation logic to communicate with the bus iness logic, many data-type mismatches will likely need to be addressed. There are many data types that exist on the .NET platform but not Java, and vice-versa, and there are also inconsistencies in how the different platforms define even simple common data types such as strings.

One means of addressing this interoperability challenge is to serialize the data before passing it between the application servers. Simply stated, serialization is the act of converting a data object into a byte stream of either binary data or XML. That byte stream can then be passed over network interfaces to the other application server before being deserialized. Both .NET and J2EE application servers use serialization/deserialization processes internally, and so each incorporates both a binary serializer and an XML parser that support serialization and deserialization.

The binary serializers that are incorporated into .NET and Java application servers are not directly compatible with one another, since they are not capable of converting data types from one platform to another. Fortunately, however, third-party serializers such as Intrinsyc Ja.NET* and JNBridgePro* work with the .NET serializer to support that functionality.

Since XML is inherently self-describing, platform-independent, and well suited to machine-to-machine communication, direct data interchange of well-formed XML documents is possible between .NET and J2EE application servers. In practice, this implies that the parser in the .NET application server might take a .NET-specific data type, convert it into XML, and pass it to the J2EE application server, which would parse the XML and convert it into a J2EE data type. (This operation is accompanied by the obverse operation – from a J2EE application server to a .NET application server.)

XML-based serialization depends upon use of the Serialize and Deserialize methods, respectively of the XmlSerializer class in order to map .NET classes to XML objects and vice versa. Mapping Java classes to XML and vice-versa is accomplished by the use of third-party serializers such as XML Data Management*, Apache Cocoon* , Open XML Framework (OXF)* or Java Architecture for XML Binding (JAXB)*.

Interoperability of .NET application servers with J2EE application servers provides a key value proposition to enterprises that wish to leverage the full spectrum of existing components and expertise at their disposal. As the next section of this article shows, the .NET application server also provides robust support for predecessor technologies.

Both the .NET application server and major J2EE application servers are optimized for Intel platforms. The ongoing commitment by Intel and the makers of these application servers to enable high performance from the combination of these software and hardware platforms is good news for IT departments. By supporting high-performance deploym ents on servers based on Intel® Xeon® processors and Itanium® processors from multiple manufacturers, .NET and J2EE provide flexibility in platform selection that translates to cost savings and scalability.

The .NET application server supports very robust integration with previous technologies. That integration includes peaceful coexistence of multiple generations of .NET technology, as well as components and applications based on the Component Object Model (COM), the unmanaged predecessor of the .NET application environment.

Microsoft released version 1.0 of the .NET Framework in 2002, and version 1.1 in 2003. While they share the same core technologies, assemblies (.NET managed components) written for version 1.0 will not necessarily function properly on version 1.1 of the Framework and vice-versa.

Thus, it is often necessary for a single application server to run both versions of the Framework side-by-side, which is well-supported by the .NET application-server. That ability allows components written for both Framework version 1.0 and version 1.1 to both run in their native environments, even in the same application. The application server integrates the operation of these two versions of the .NET framework seamlessly.

In order to support existing investments in unmanaged COM components that companies have already developed, the .NET application server supports the incorporation of those components into .NET applications using Runtime Callable Wrappers (RCWs). The RCW is a proxy that the .NET Common Language Runtime (CLR) creates dynamically at runtime. Using an RCW, a .NET application can call a COM component directly, incorporating its functionality as if it were a native .NET object. The RCW actually exists as a managed object within the CLR, so this incorporation is transparent.

The .NET application server also allows legacy applications to call .NET assemblies using a related technology called a COM Callable Wrapper (CCW). COM applications can thus use a CCW as a proxy to call a .NET assembly, incorporating the functionality of that assembly as if it were a native COM object.

The .NET application server's robust support for multiple versions of the .NET Framework, as well as interoperability between .NET managed code and legacy unmanaged COM objects, enables a tremendously flexible environment to support various generations of technology under one environment. The continuing development of the environment will continue to support multiple generations in this fashion for the foreseeable future, as well as building on the those technologies in terms of efficiency of development, security of deployment, and flexibility of operation.

Servers based on Intel architecture are well suited to deployments of the .NET application server. In addition to the optimization of the Windows Server 2003 operating system for both Itanium processors and Intel Xeon processors, core features of Intel server architectures make them a strong bet for the se deployments. The explicit parallelism, large cache, and massive addressability of the Itanium microarchitecture provide industry-leading scalability and performance on a non-proprietary architecture that provides extremely competitive cost/performance when compared to proprietary RISC architectures.

Intel Xeon processors deliver outstanding performance, versatility, and low cost of ownership for the .NET application server through Hyper-Threading Technology, Integrated Three-Level cache architecture, and the Intel® NetBurst™ microarchitecture. Systems based on either the Itanium processor or the Intel Xeon processor are a sound choice for Windows Server 2003 and the .NET application server. As described in the following section, the landscape will get even better for such deployments as the software and hardware platforms evolve.

The Microsoft Visual Studio .NET* development environment is highly integrated with the .NET application server, enabling developers to easily take advantage of advances in Windows server platforms. For instance, Windows Forms provide the basis for rich-client applications that integrate directly with the Windows user interface and back-end services such as Active Directory*, Windows authentication and other Windows security features.

The next generation of Visual Studio*, code-named "Whidbey," is scheduled for release in 2004. Whidbey will bring enhancements to many aspects of the .NET application server environment, including improvements to the "no-touch" application-deployment strategy.

The introduction of "ClickOnce Technology" technology in Whidbey will build on the ability of no-touch deployment to deploy and maintain Windows clients over the wire with such features as support for running applications offline, rolling back installations to previous versions, and listing applications in the 'Start' menu and 'Remove Programs' control panel. It will also allow deployment of the .NET Framework along with an application. In order to make this deployment model more robust, Microsoft is improving code-access security, providing more granular and extensive control over the capabilities of applications hosted by remote Web servers. This change allows the model to be more flexible while also improving security.

Windows Forms themselves under Whidbey and the .NET application server will feature more robust features and controls. These will include an Active Document container that will allow Microsoft Office* documents to be hosted within the Windows Forms application, layout controls that will enable form elements to resize according to screen resolution and form dimensions, and improved support for asynchronous applications.

Whidbey will also enable the .NET application server to ensure consistency and code reuse across Web sites by introducing "Master Pages" technology. Master Pages will support the creation of layout templates that place controls, menu bars, headers, and footers at set locations. The application server will allow that template information to be inherited by multiple pages on the site, so that changes to a Master Page will replicate throughout a site.

Finally, Whidbey will introduce Framework services that simplify the provision of functionality on the application server such as authentication, Web site navigation, administration, and personalization. This next generation of the development environment will thus directly contribute to making the .NET application server in Windows Server 2003 even robust, secure, and efficient.

New and upcoming features of server processors from Intel will extend the benefits of .NET and other application servers from their already considerable level. The future of the Itanium processor includes multiple processor cores on a single die, a higher-speed front-side bus, and support for PCI Express and double data-rate (DDR2) memory. The Intel Xeon processor line will also expand to include multi-core technology, which is expected to generate very high performance by decreasing the latency associated with intercommunication between the cores, relative to that between separate processors. New tools for virtualization and workload management [PDF 139KB] enable Intel architecture-based servers to support 20 or more operating systems and application stacks on a single server.

Continuing work by Intel and Microsoft to enable the .NET platform to take full advantage of the latest processor features in Intel architecture will pay dividends to the enterprise IT departments that use this winning combination of software and hardware platforms.

The .NET application server provides robust support for enterprise applications, including interoperability with J2EE application servers and applications, full Web services support, the ability to incorporate legacy components and to offer .NET assemblies to legacy applications, and a world-class development environment.

Web services support in the .NET application server is complete, in terms of standards compliance to allow interconnectivity of multi-platform components over the Internet. Developers can make use of internal .NET classes and third-party tools to provide interoperability with Java application servers, even within a single application. Runtime Callable Wrappers and COM Callable Wrappers allow the application server to operate transparently across the managed/unmanaged code boundary, which allows very efficient reuse of existing legacy components.

Microsoft Visual Studio .NET provides a robust and flexible development environment that makes creating, testing, and deploying on the .NET application server extremely efficient. The upcoming release, code-named Whidbey, will build on those advantages, making the .NET application server an even better choice for enterprise application environments.

The .NET application server and related tools are highly opt imized for both 32-bit and 64-bit Intel® architecture. The ongoing strategic alliance between Microsoft and Intel promises to maintain that optimization, making best use of the silicon in future releases of the application server.

Intel platforms provide winning value and performance, and the .NET application server provides a particularly strong showcase for its success. Enterprises that deploy .NET on Intel architecture will continue to reap the benefits of flexibility, performance and low cost of ownership.

Matt Gillespie is an independent technical author and editor specializing in emerging hardware and software technologies. Before going into business for himself, Matt developed training for software developers at Intel Corporation and worked in Internet Technical Services at California Federal Bank. He spent his early years as a writer and editor in the fields of financial publishing and neuroscience. You can reach him at spanningtree@comcast.net.

The following resources from Microsoft provide more information about the .NET application-server environment and the code-name "Whidbey" release of Visual Studio:

• Windows Server 2003: Technical Overview of Application Services*
• Simon Guest. Microsoft .NET and J2EE Interoperability Toolkit (Redmond, WA: Microsoft Press, 2003).

• ClickOnce - Reduce the Challenges of Mobilized Software Deployment
• Overview of Enterprise-Class Application Servers
• Java* and .NET* Both Bring Something to the Party
• MRTEs Add Both Functionality and Complexity

• .NET Platform
• Java*