Dwight Peltzer

Subscribe to Dwight Peltzer: eMailAlertsEmail Alerts
Get Dwight Peltzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


IBM's WebSphere Application Server vs. Microsoft's .NET Framework

Part 1

The data evolution has completely changed how businesses conduct transactions on the Web. The business environment has evolved rapidly from presenting static data to consumers and businesses alike, to a new world, something we can only describe as the era of application integration and data evolution.

Interoperability, today's buzz word, is meaningful because it describes a process in which legacy systems are being integrated with new, interactive business software solutions. Both IBM's WSAD and Microsoft's.NET Framework v1.1 are component based and contain a large collection of interfaces.

This article focuses on the internal structure of .NET, whereas the second article will examine WSAD's layered architecture. The remaining articles will demonstrate how both infrastructures interact with their respective Web components, i.e., ASP.NET, ADO.NET, Java servlets, JavaServer Pages, and Enterprise JavaBeans.

Web Services Provide the Glue that Binds Disparate Systems
Web services represent the main force driving the Internet today. Recently, Sun Microsystems decided to provide support for Web services. Their release of the .NET Framework represents the company's attempt to enter the enterprise distributed application arena.

The Framework consists of several components, all supporting Web services. WebSphere Application Server's architecture also supports Web services, something we'll discuss in the next article.

A dizzying array of integrated business solutions is available on both platforms. Learning new technologies is a major challenge facing developers who are accustomed to building enterprise applications exclusively in one programming language or another, but not both. Rarely does a developer know both platforms, especially since Microsoft .NET technology is relatively new. Understanding .NET's Web Services and Functionality

The Internet has leveled the business playing field. Small companies can appear to be much larger than they are. Large corporations can cut costs significantly by conducting business transactions on the Web.

So, how does the .NET Framework and its components meet the needs of consumers today? The same question can be asked of IBM's WSAD container and its diverse technologies. The answer to both questions requires detailed explanations.

Let's begin by exploring the .NET Framework and its layered architecture, followed by an examination of IBM's WSAD and how it supports Web services. Cross-platform interoperability is the key to providing insights on how to achieve application integration.

.NET's Infrastructure: Component Based The .NET platform consists of several components:

  • Common Language Runtime (CLR)
  • Common Type Specification (CTS)
  • Common Language Specification (CLS)
  • Web Forms

At the lowest layer lies the operating system, which can be a variety of Windows platforms, ranging from Windows XP to Windows Server 2003. Residing on top of the OS is a series of Enterprise Server products such as Application Center 2000, BizTalk Server 2000, Host Integration Server 2000, and SQL Server 2000. The top layer comprises the Web services layer, namely the .NET Framework v1.1. The Framework is a new development and runtime structure that includes the CLR, the CTS, the CLS, and a common set of libraries and namespaces providing language independence and multi-language interoperability.

You can think of the CLR, the most important component of the .NET Framework, as the equivalent of Java's JVM. The main difference is that the JVM supports only the Java language, while the CLR supports all languages targeting the .NET Framework. This interoperability is provided courtesy of the Common Intermediate Language (CIL). Java's JVM executes bytecode by interpreting it, so it can support many different languages. However, unlike bytecode, the Microsoft Intermediate Language (MSIL) is compiled rather than interpreted.

The layer residing on top of the CLR contains a set of classes that support fundamental input and output functionality, network communications, thread management, text management, reflection, collections functionality, and security management.

On top of the Framework base classes is a collection of classes that support data management and XML functionality. They also include the Structured Query Language (SQL) interface to SQL Server 2000. .NET Component ADO.NET allows you to manipulate persistent data in a disconnected mode. We will talk more about this later.

The three Web-oriented technologies - Web services, Web Forms, and Windows Forms - extend the Framework. Web services play a major role in the development of distributed components. Web Forms include a set of classes that allow the developer to create Graphical User Interface (GUI) applications, which provide a drag-and-drop experience similar to building GUIs in Visual Basic.NET. You can drag a control onto the Web form, double-click on the control, and respond to the related event. Windows Forms offer a supporting collection of classes that facilitate development of native Windows GUI applications.

Understanding CLR Management's Functionality
The CLR, similar to WSAD, provides low-level services such as automatic memory management, garbage collection, connection pooling, and security. This means you can inherit from classes, catch exceptions, and support object-oriented polymorphisms across numerous programming languages and platforms.

The Common Type Specification facilitates the common concept of interfaces, classes, reference types, value types, and delegates that support callbacks. The Framework base classes offer support for the base system types such as integers, strings, and file manipulation. Last but not least, the Framework designates Simple Object Access Protocol (SOAP) as its primary method of transport using the ubiquitous HTTP protocol.

Exploring the CLR's Environment
The CLR manages all aspects of code execution within the Framework. At this stage, we introduce two key terms, the Manifest and the Assembly. The Manifest provides metadata about the Assembly, including a list of externally referenced assemblies required for application execution. The CLR utilizes a tool included within Visual Studio.NET called ildasm.exe to display the Manifest and the Assembly. Consider the code shown in Listing 1.

The Assembly is the basic unit containing its name, version, and culture. A public key provides assembly verification. This permits assemblies to reside side-by-side without conflict. Significantly, .NET no longer registers DLLs in the system registry, thereby eliminating a lot of problems we have all experienced with DLL versioning. The CLR examines the assembly for its version number. All assemblies shared by more than one assembly must be constructed with a public/private key. At build time, the compiler generates a hash of the assembly, then signs the hash with a private key and subsequently stores the digital signature in a specified section of the Program Executable file (PE). We will examine the PE file in a moment. The CLR verifies the assembly's public key by decrypting the assembly's digital signature. Finally, the CLR uses the assembly's information to generate a hash and compare it with the original hash. If the comparison is valid, the assembly is loaded by the Class Loader, another important CLR component. Its sole task is locating and loading .NET classes using Reflection. However, before the loader loads the assembly, the CLR examines the PE file for application validity.

Examining the Program Executable File (PE)
Let's examine a PE file using a tool called dumpbin.exe, also included within Visual Studio.NET. The command line format is dumpbin.exe filename; its type is either .exe or .dll. (see Listing 2).

The PE file lists the MS-DOS and Common Object File Format (COFF) headers. The overall file structure is the same for all Windows files. Microsoft has extended the PE file by adding headers to accommodate the Framework. Notice that it supports 32-bit Windows programs. The FILE HEADER values segment indicates there are three sections in this file. The SECTION HEADER #1 stores the CLR header and data. The next segment, Code and Execute Read, informs the OS Loader the file contains code to be executed by the CLR at runtime. The rest of the PE file holds individual segments for .rdata, .rscr, and .text, as demonstrated above in the header file. When the CLR locates the header, it executes 0_-CorDLLMain.

The CLR header and data section include both metadata and MSIL code. These describe in detail how CustomerClient executes. MSIL code is similar to Java's bytecode, but MSIL is compiled rather than interpreted. If the file is an executable, it executes o_CorEXEMain.

The PE file hosts the application code whereas the Manifest (metadata about the assembly) describes all references to external libraries, methods, classes, and types in binary format.

Examining the CLR Core Entities
The CLR contains two core entities: runtime engine mscoree.dll and base class library mscorlib.dll. Notice how the binary example listed above begins with assembly extern mscorlib.dll. Since the Assembly was generated in Visual Basic, the manifest reflects this as well. All assemblies have a public key token indicating that the assembly can be shared by other assemblies. We notice that the manifest references other external assemblies such as System, System.Data, System.xml, System.CLSCompliantAttribute, and System.Reflection. Reflection allows you to examine MSIL Code and assemblies. It also supports dynamic creation of assemblies. System.Reflection facilitates late binding and permits you to load the assemblies at runtime.

The second section of the Manifest enumerates each module within the assembly:

.custom instance void [mscorlib] System.Reflection.AssemblyDescriptionAttribute::.ctor (String) = ( 01 00 00 00 00 ).

Two kinds of assemblies exist: static assemblies and dynamic assemblies. Static assemblies are stored somewhere on your hard drive, while a dynamic assembly is generated by System.Reflection.Emit. This namespace creates the dynamic assembly in memory at runtime. Once the assembly exists, it reverts back to a static status. Furthermore, it is possible to add new types dynamically to the runtime assembly. For example, Web-enabled languages generate raw code, emit IL code, and store it dynamically to the assembly.

The CLR can generate both single- and multi-file assemblies. The first type represents a single binary. The second contains more than one binary, called a module. Modules allow you to partition a multi-file assembly, thereby facilitating the creation of an easy deployment model.

Managed code is the term used to describe instances of objects you create managed by the runtime. The container holding the IL code is the assembly.

Understanding the Verification Process
Before running MSIL code, you must convert it utilizing the just-in-time (JIT) compiler, called affectionately the Jitter. MSIL is CPU-specific code that runs on the same computer as the JIT compiler. The CLR provides a JIT compiler for each CPU-specific architecture.

The JIT compiles only code required for execution rather than loading all MSIL code existing in the PE file. Once the code is loaded, JIT stores the native code for subsequent calls. The loader creates a stub and attaches it to each of a type's methods. With the initial call, the stub relinquishes control to the JIT compiler. The compiler then modifies the stub to provide CPU-specific execution instructions. Subsequent calls go directly to the identified native code rather than repeating the process just described here. This substantially reduces the time required to run native code.

Another mode of compilation is called install-time code generation. This compilation method converts the MSIL code the same way as the standard mode previously described above. However, the JIT converts larger chunks of code at compile time and stores the native code with consideration for what it already knows about other already installed assemblies. This file loads and starts more quickly than the standard JIT method.

The verification process validates the code before the JIT compiles the MSIL code. It employs reflection to examine both the metadata and MSIL to ensure the code is type safe. The compiler subsequently accesses only the portions of memory containing the type-safe code. Additionally, the verification process guarantees and enforces security restrictions defined by the CLS.

The CLR depends on the following criteria to ensure it is processing type safe code:

  • Identities must be validated.
  • Only type-safe operations are invoked on an object.

If the JIT receives nonverified code, it generates an exception.

Now that we have explored the .NET Framework, my next article will examine IBM's WSAD infrastructure. We will expose similarities and differences between the two technologies. Once that task is accomplished, we can discuss how both the .NET's CLR and WSAD manage their respective technologies.

More Stories By Dwight Peltzer

Dwight Peltzer is a professor of computer science, developer, lecturer, and author on Microsoft and J2EE software solutions. Presently, he is a faculty member at the School of Engineering and Computer Science at the C.W. Post campus of Long Island University. He teaches seminars on C++, Visual Basic, .C#, .NET, SQL, ASP.NET, and J2EE-related technologies such as JAXP, JavaServer Pages, and XML.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.