Microsoft .NET Fundamentals for JavaJ2EE Developers

Microsoft .NET Fundamentals for Java/J2EE Developers

The .NET Framework is Microsoft's initiative to deliver a new way of building and deploying applications and services. As .NET becomes accepted in the programming community, this vision is starting to encompass many products, ideas, and other services.

For the Java developer, the .NET Framework really does promote interoperability. The foundations of .NET have been built from the ground up, with standards such as HTTP and XML embedded within the classes of the framework itself. Java developers who have tried to create a Java-to-COM interface or call an existing Win32 API by using Java Native Interface (JNI) often will welcome the implementation of these standards with open arms.

The .NET Framework is the platform that contains the classes, APIs, and tools on which .NET applications can be built. Although I usually shy away from direct comparisons because they tend to draw out the religious side of developers, it is possible to compare some elements of the .NET Framework to the corresponding Java counterpart , although they sometimes work in very different ways. The .NET Framework is required to build and run any .NET application and is available today as a download via Windows Updatea system from which the Microsoft Windows operating system can download new patches and driversor directly from the Microsoft .NET Web site ( ).

At the core of the .NET Framework lies the common language runtime (CLR). Some roles of the CLR can be likened to those of the Java Virtual Machine (JVM). The CLR is responsible for the many tasks that are involved in running and hosting .NET applications.

The CLR can work with only one type of code: Intermediate Language (IL). This code also is known as Microsoft Intermediate Language (MSIL) and often is referred to as managed code . The CLR contains a just-in-time (JIT) compiler to compile the IL into native code. (This is currently x86 code for the Windows operating system.) Managed code running in the CLR is inherently type safe and provides support for garbage collectionterms that should be familiar to Java developers with a C/C++ background. In addition, the CLR runs managed code applications in the context of application domains, which allows multiple applications to run within a single process on the machine.

Because IL is a pseudomachine language code, writing in IL isn't an intuitive experience for most developers. To write to the .NET Framework, you'll need to choose one or more languages. These languages include Microsoft Visual Basic .NET, C#, J#, Managed C++ from Microsoft, and third-party languages such as Perl, Python, Eiffel, and COBOL. Each of these languages compiles down to IL and is then compiled again by the CLR when the application is run. In this book, I'll use C#. This is purely a personal preference; any of the previously mentioned languages would be suitable. Feel free to convert any of the C# sample code in this book to the language of your choice.

Building a .NET Application

You can access the compiler of choice installed within the .NET Framework in one of two ways. Each of the compilers can be called from the command line, and they are normally located in the Microsoft.NET\Framework\v1.1.4322 subdirectory (for version 1.1 of the .NET Framework) of your Windows installation directory. (From now on, I'll refer to this as C:\WINDOWS, which is the installation directory for Microsoft Windows XP.) The executable for the C# compiler is CSC.EXE, and the compiler for Visual Basic .NET is VBC.EXE; both are located in this directory.

Alternatively, you can build applications by using Microsoft Visual Studio .NET, Microsoft's integrated development environment (IDE) for the .NET Framework. As with many IDEs for the Java platform, Visual Studio .NET provides the developer with a comprehensive set of tools to enable productivity. The majority of the code in this book is built and run using the command-line compiler (making it easy to switch between the Java compiler and the C# compiler to build and run the samples), while Visual Studio .NET is used when it offers additional functionality.

When you successfully compile an application by using either the command-line compiler or Visual Studio .NET, one or more assemblies are produced. An assembly is the module that's designed to be executed by the CLR. Assemblies usually take the form of an .EXE or .DLL file and can be examined by using the MSIL Disassembler tool that comes with the .NET Framework. Every assembly contains metadata that describes it, including the Windows Portable Executable Header, dependencies on other assemblies, and version information. Java has no direct equivalent of an assembly. However, Java developers can think of an assembly as a Java Archive (JAR) file that contains a number of classes that can store additional metadata and has the ability to make cross-references to other JAR files without referencing a CLASSPATH .

Locating and Sharing Other Assemblies

Assemblies have the ability to make cross-references to other assemblies with information stored in metadata, but this still doesn't solve the problem of dynamic binding or locating an assembly when an application is running. Instead of using an environment variable in these scenarios, the .NET Framework uses a global assembly cache (GAC), a machine-specific store that contains assemblies to be shared between applications. Assemblies stored within the GAC can be found in the C:\WINDOWS\ASSEMBLY directory and can be added or removed by using the GACUTIL tool.

In addition, the GAC can hold multiple versions of the same assembly. (Recall how the version number was stored in the metadata of the assembly itself.) Using this metadata, applications that reference an assembly in the GAC can ask for a specific version at run time.


Attributes are a key element of the CLR. They're important to understand because they do not appear in the current version of the Java 2 platform, yet they're common in many of the .NET samples in this book.

Attributes are keywords that utilize a tag syntax within a source code file. They can be used to annotate classes, types, fields, and methods at design time to specify runtime information and behavior. The attribute information is saved within the metadata of an assembly. Attributes can be widely found in many of the namespaces in the .NET Framework. You also can create custom attributes for your applications.

The WebMethod attribute is a good example of an attribute in action. WebMethod is used to indicate that a method within a class is callable as an XML Web service, which we'll look at in more detail starting in Chapter 5, "Connectivity with XML Web Services, Part 1." Prefixing the WebMethod tag at the start of the method automatically instructs the compiler to generate the additional information required to expose the method as a Web service:

 [WebMethod] public String HelloWorld() {      } 

Attributes can also accept parameters in a way similar to a constructor invocation. For example:


This line of code will assign the namespace property of the WebMethod attribute to the URL that was passed.

For developers with an understanding of J2EE, some functionality that attributes provide can be achieved using the configuration settings found within deployment descriptors.

Because attributes are CLR specific, they're supported in all CLR-compliant languages, including C#, Visual Basic .NET, and J#. The way in which the tags are prefixed, however, differs slightly with each language's syntax.

Creating Applications for the Web

.NET applications that are designed for the Web are built using ASP.NET, which is Microsoft's next -generation development of Active Server Pages (ASP). Although not strictly tied to a Web server, Microsoft Internet Information Services (IIS) is typically used as the foundation for hosting ASP.NET-based applications.

To developers with a background in JavaServer Pages (JSP), ASP.NET is more than a .NET equivalent. Within the .NET Framework, ASP.NET contains certain features (such as code-behind and event-driven Web controls) that to achieve similar functionality in J2EE would require both JSP v1.2 and additional tools.

Because of their graphical nature, pages that make up ASP.NET applications are normally developed using Visual Studio .NET. Another alternative for developing ASP.NET solutions is to use the Web Matrix IDE. This IDE is best suited for developers who want to build visual applications but don't require the power of Visual Studio .NET. You can use any language the CLR supports to create ASP.NET Web applications.

Hosting Components

For better or for worse , the .NET Framework and the Windows platform have no direct equivalent to Enterprise Java Beans (EJBs). However, because hosting components is key for many enterprise applications, three alternatives to sharing a component with multiple clients exist:

  • Run as a Windows Service Windows Services (also known as NT Services) are system-level processes that run on the machine independent of the user who is logged in. Typical services include functions of the operating system, schedulers , virus scanners , database engines, and network components. Using templates supplied with Visual Studio .NET, it is possible to take a .NET assembly and run it as a service; however, the assembly will need to handle its own networking if it will be called remotely. This capability can be useful for applications that must be active for the lifetime of the machine.

  • Host through IIS Building a custom framework to host assemblies can be relatively complex. This process can include creating custom network sockets and listeners, caching, performing connection pooling for multiple clients, and so on. Many of these features are also found in products that host Web applications, such as IIS. One way of hosting an assembly is to take advantage of these features. IIS allows an assembly to be deployed and will handle incoming connections, protocols, pooling, and security via a configuration file located with the assembly.

  • Use Component Services Although hosting an assembly via IIS provides an easy and convenient way of sharing components, certain functionality that exists in EJBs might be required. This functionality can include recycling, state, transactions, method-level security, logging, impersonation, and message queue support. You can achieve this functionality with a .NET assembly by using Component Services. Also known as COM+ Services, Component Services enable you to apply this functionality to hosted components through either an administration tool or the use of attributes. I'm frequently asked whether a Microsoft equivalent of Container Managed Persistence (CMP) EJBs existsin other words, whether the ability to provide objecttorelational database mapping exists. As of this writing, this capability does not exist within the .NET Framework; however, a number of third-party implementations are available. In addition, Visual Studio .NET contains many tools that can auto-generate SQL statements and that even allow database tables to be dragged and dropped into the IDE itself.

Where's the Application Server?

Because I came from a J2EE background, this was certainly one of my first questions when learning .NET. Although I had done some COM programming, I was used to the concept of building and deploying for an application server that ran independent of the operating system.

As explained earlier, all the functionality found in a commercial J2EE application server (such as security, messaging, transactions, and logging) can be found in Windows and can be accessed by the classes in the .NET Framework. However, in contrast with a typical J2EE application server, this .NET functionality tends to be distributed across various parts of the operating system rather than being stored in one place. Many of these distributed parts have their own interface, configuration, and store; as a J2EE developer, you'll find that learning where this application server functionality lies is one of the challenges of learning about .NET. A lot of this design stems from historical reasons (providing backward compatibility with existing Win32 APIs and Windows DNA applications) and the way that the components have evolved over the years .

Throughout this book, I'll address these parts of the Windows application server as they relate to the interoperability areas being covered. Because many Java developers will have little knowledge of these components, I'll make these explanations and instructions clear and precise.

References and Resources

I have found the following list of references and resources useful for introducing Microsoft .NET and various elements of the framework.

Microsoft .NET Product Page

Go to to download the .NET Framework SDK and find links to .NET- related information and products.

GotDotNet Community

GotDotNet at is a community resource that contains sample downloads, tools, forums, links, and guides for the .NET Framework and related technologies.

ASP.NET Community

The site contains a collection of tools, community resources, samples, and tutorials specifically for ASP.NET application development. A rich component library is also available for building and extending your own ASP.NET applications.

Windows Forms Community

The site is similar in nature to but is focused solely on Windows Forms development using Microsoft .NET.

Microsoft. NET and J2EE Interoperability Toolkit
Microsoft .NET and J2EE Interoperability Toolkit (Pro-Developer)
ISBN: 0735619220
EAN: 2147483647
Year: 2003
Pages: 132
Authors: Simon Guest © 2008-2017.
If you may any questions please contact us: