Checklist of Things to check when investigating .

NET Products

1. Introduction

The .NET technologies can require a number of ancillary products. Those products may not be available as part of
the .NET implementation in the Shared Services Infrastructure. This checklist helps to clarify what is required to
run .NET products and, in identifying potential incompatibilities.

2. Standard Dependencies for .NET Products

Most .NET products will have been built on, tested for, certified for and documented for use on Win32 platforms
(usually Windows 2000 or the newer Windows .NET Server). There are a number of standard dependencies that
should be verified.
• Which version of which operating system has the product been tested for, certified for and documented for?
Standard responses would include Windows 2000 Server with Service Pack 3 or Windows .NET Server
Release Candidate 2.
• Which version of the .NET Framework has the product been tested for, certified for and documented for?
Standard responses would include version 1.0 of the .NET Framework Redistributable with Service Pack 2
(for Windows 2000) or the .NET Framework Service Pack 2 for Windows .NET Server Release Candidate
2.
• Presuming that the package uses browser-based clients the solution will require a web server. Which
version of which web servers has the product been tested for, certified for and documented for? Standard
responses would include version 1.0 of the .NET Framework Redistributable with Service Pack 2 (for
Windows 2000) or the .NET Framework Service Pack 2 for Windows .NET Server Release Candidate 2.
 .NET Overview for Project Managers and Solution Evaluators

1. Introduction

The .NET Framework is a new computing platform developed and led by Microsoft that attempts to simplify
application development and interoperability in the highly distributed environment of the Internet. The .NET
Framework is designed to fulfill the following objectives:
• To provide a consistent object-oriented programming environment whether object code is stored and
executed locally, executed locally but Internet-distributed, or executed remotely.
• To provide a code-execution environment that minimizes software deployment and versioning conflicts.
• To provide a code-execution environment that guarantees the safe execution of code, including code
created by an unknown or semi-trusted third party.
• To provide a code-execution environment that eliminates the performance problems of scripted or
interpreted environments.
• To make the developer experience consistent across widely varying types of applications specifically
including Windows-based applications and Web-based applications.
• To build all communication on industry standards to ensure that code based on the .NET Framework can
integrate with any other code.

1.1. The Importance of .NET

.NET is, first and foremost, Microsoft's implementation of the web services standards. By integrating a supporting
framework into their operating systems (Windows 2000, Windows XP and the forthcoming Windows .NET Servers)
Microsoft makes it easier to support web services functionality than, for example, an application server that sits on
top of the OS. The price for this simplicity - integration - is that web services built for .NET are essentially limited
to Microsoft operating systems.
Why is .NET important? As the Microsoft implementation of a very important technology the Bank needs to
understand how it can and should be used to provide services to employees, partners, customers and prospects. The
'very important technology' - web services - is expected to become a predominant component of applications both
developed and purchased. Since Microsoft operating systems power the bulk of the client systems in the Bank and at
our partners, prospects and customers it should be well understood to allow us to best benefit from it.

1.2. Audience

Project managers and/or solution evaluators intend this document for the use. It is targeted primarily at those who
will look to integrate a SSI application with either a bespoke .NET application or one purchased with intent to run on
or integrate with the SSI.

2. .NET Description

Microsoft .NET is a platform for building, deploying, and running web services and applications. It provides a
standards-based, multi-language environment for integrating existing applications with applications and services
based on next-generation technologies. In addition, it addresses many of the challenges of deployment and operation
of distributed applications. It consists of:
• a programming model that enables developers to build web services and applications;
• a set of pre-built XML Web services, such as Microsoft .NET My Services (formerly code-named
'Hailstorm'), that helps developers deliver a simple and integrated user experience;
• a set of servers, including Windows 2000, SQL Server and BizTalk Server, that integrates, runs, operates
and manages XML Web services and applications;
• client software, such as Windows XP and Windows CE, that helps developers deliver a rich and consistent
user experience across supporting devices; and
• tools, such as Visual Studio .NET, to develop XML Web services, native Windows and web-based
applications.
3. Introduction to .NET Framework

The .NET Framework is the programming model of the .NET platform. It is designed to manage much of the
application infrastructure, enabling solution developers to focus on writing the business logic code for their
applications. The .NET Framework is comprised of:
• the common language runtime (aka, the common language infrastructure or CLI)
• a hierarchical set of unified class libraries
• a re-architected version of Active Server Pages called ASP.NET
The .NET Framework includes native support for XML Web services. XML Web services is the preferred
communications vehicle for
Some fundamental components of the .NET framework have been submitted and accepted as standards. This has
allowed third parties (non-Microsoft) to implement the technologies for non-Microsoft operating systems. The most
prominent non-Microsoft implementations are Mono from Ximian, Rotor from Corel and Portable .NET (part of the
DotGNU project). Note that all of these are open source projects.

4. Details of .NET Framework

4.1. Common Language Runtime

The common language runtime is responsible for run time services such as language integration, security
enforcement, memory, process, and thread management. In addition, it has a role at development time when features
such as life-cycle management, strong type naming, cross-language exception handling, dynamic binding, and so on,
reduce the amount of code that a developer must write to turn business logic into a reusable component.

4.2. Class Libraries

Base classes provide standard functionality such as input/output, string manipulation, security management, network
communications, thread management, text management, user interface design features, and other functions. The
Microsoft ADO.NET data classes support persistent data management and include SQL classes for manipulating
persistent data stores through a standard SQL interface. XML classes enable XML data manipulation and XML
searching and translations. The Microsoft ASP.NET classes support the development of Web-based applications and
XML Web services. The Windows Forms classes support the development of Windows-based smart client
applications. Together, the class libraries provide a common, consistent development interface across all languages
supported by the .NET Framework.

5. Microsoft's Web services initiatives

Microsoft's .NET platform was introduced almost two years ago at their developer conference (PDC), along with
their Visual Studio .NET preview release. Currently, the .NET Framework is available for download at... The .NET
platform supports the XML Web services architecture, and also incorporates more features and advances (such as
ASP+, the new programming language C#, the .NET framework, CLR, and so forth). Note the term "XML" in front
of Web services. This was added recently, probably to put an emphasis on XML as the underlying universal
language. Microsoft also now offers the SOAP Toolkit, Version 2.0 (gold release) as a download (MSDN). This
article does not provide a detailed overview of the .NET platform, and it does not provide a tutorial for Visual
Studio .NET. This information is already provided as online documentation bundled with the .NET framework tools,
and there are a variety of tutorials, articles and other resources on MSDN and the Web that address this topic. At this
time, the ECMA has finished the standardization of the common language infrastructure of the .NET Framework
and the C# programming language. Also, a beta version of Microsoft Visual J#™ .NET, a Java compatible language
for the .NET platform, is available for download and testing. On the operating system side, Microsoft is working on
a .NET server (currently beta 3), which integrates native support for the Web services stack, including UDDI.
Microsoft distinguishes between a set of baseline specifications that provide the foundation for application
integration and aggregation (XML, SOAP, WSDL, UDDI), and the Global XML Web Services Architecture, a
collection of specifications that build on the baseline specifications. IBM and Microsoft co-presented this framework
at the W3C Workshop on Web Services in April 2001. A set of technical previews and proposals are available:
 • WS-Inspection (this can be used for assisting in the inspection of a site for available services).
• WS-License (this describes how to encode X.509 certificates and Kerberos tickets, as well as arbitrary
binary credentials).
• WS-Referral (this provides a mechanism to dynamically configure SOAP nodes in a message path to define
how they should handle a SOAP message).
• WS-Routing (this enables SOAP-based protocol for routing SOAP messages in an asynchronous manner
over a variety of transports like TCP, UDP and HTTP).
• WS-Security (this describes enhancements to SOAP messaging providing three capabilities: credential
exchange, message integrity and message confidentiality).
• XLANG (business orchestration language).
In addition to these specifications, Microsoft is planning to continue releasing additional specifications in the Global
XML Web Services Architecture.
 . NET Detailed Guide for Architects, Designers and Senior Developers

1. Introduction

The .NET Framework is the programming model of the Microsoft .NET platform for building, deploying and
running Web applications, smart client applications and Extensible Markup Language (XML) Web services that
expose their functionality programatically over a network using standard protocols such as SOAP, XML, and HTTP.

1.1. The Importance of .NET

.NET guidelines are important in understanding the concepts for how .NET services and applications can and should
be leveraged in the context of the Shared Services Infrastructure.

1.2. Document Scope

This document describes concepts, guidelines and best practices for how .NET managed solutions should be
constructed, discovered and used in the Shared Services Infrastructure. The issues discussed pertain to:
• Building .NET Services
• Discovering and Using .NET Services
• Recommend Tools, Tutorials and Other Resources

1.3. Audience

This document is intended for the use by anyone developing or integrating solutions for the SSI platform. The
intended audience is solution developers (including both component and user interface developers), project
managers or anyone involved in the activities of designing and developing solutions to run on the SSI. The
document assumes a working knowledge of web-based applications.

2. Building .NET Services

2.1. CLR Fundamentals

The .NET Framework provides a run-time environment called the common language runtime, which manages the
execution of code and provides services that make the development process easier.
The common language runtime (CLR) manages memory, thread execution, code execution, code safety verification,
compilation, and other system services. These features are intrinsic to the managed code that runs on the common
language runtime.
The runtime loads and runs code written in any runtime-aware programming language. Code that targets the runtime
is called managed code. Managed code simply means that there is a defined contract of cooperation between
natively executing code and the runtime itself. Responsibility for tasks like creating objects, making method calls,
and so on is delegated to the runtime, which enables the runtime to provide additional services to the executing code.
The runtime features cross-language integration, self-describing components, simple deployment and versioning,
and integrated security services. Let's take a quick look at each of these features.

2.1.1. Cross-language integration

The runtime makes use of a new common type system capable of expressing the semantics of most modern
programming languages. The common type system defines a standard set of types and rules for creating new types.
The runtime understands how to create and execute these types. Compilers and interpreters use runtime services to
define types, manage objects, and make method calls instead of using tool or language-specific methods.
The primary design goal for the type system is to enable deep Multilanguage integration. Code written in one
language can now inherit implementation from classes written in another language; exceptions can be thrown from
code written in one language and caught in code written in another; and operations such as debugging and profiling
work seamlessly regardless of the languages used to write the code. This means that developers of reusable class
libraries no longer need to create versions for each programming language or compiler, and developers using class
libraries are no longer limited to libraries developed for the programming language they are using.

2.1.2. Self-describing components

Self-describing components, which are now possible on the Microsoft .NET Framework, simplify development and
deployment and improve system reliability. Many services provided by the runtime are driven by metadata,
information that supplements the executable code. Since all the information is stored together, the executables are
referred to as self-describing components.
A key advantage of self-describing components is that no other files are needed to use the components. Separate
header files are not required for class definitions; the definitions can be obtained from the component itself by
inspecting the metadata. Separate IDL files, type libraries, or proxy/stubs are not required to access a component
across language or process boundaries; the necessary information is located in the component's metadata. Separate
configuration information does not need to be deployed to identify developer requested service attributes. Since the
metadata is generated from the source code during the compilation process and stored with the executable code, it is
never out of sync with the executable.

2.1.3. Simple deployment and versioning

In addition to improvements in deploying individual components, the Microsoft .NET Framework defines an
application deployment model that addresses customer issues with the complexities of application installation and
DLL versioning (commonly known as "DLL Hell"). Services to support this model are provided by the runtime.
The Microsoft .NET Framework introduces the notion of an assembly. An assembly is a group of resources and
types, along with metadata about those resources and types, that is deployed as a unit. The metadata is called an
assembly manifest and includes information such as a list of types and resources visible outside the assembly. The
manifest also includes information about dependencies, such as the version of the assemblies used when the
assembly was built. Developers can specify versioning policies to indicate whether the runtime should load the latest
version of a dependent assembly installed on the system, a specific version, or the version used at build time.
It has always been possible for multiple copies of a software component to reside on the same system. In general,
however, only one of these copies can be registered with the operating system or loaded for execution. The policy
for locating and loading components is global to the system. The .NET Framework common language runtime adds
the infrastructure necessary to support per-application policies that govern the locating and loading of components,
which is generally referred to as side-by-side deployment.
Assemblies can be private to an application or shared by multiple applications. Multiple versions of an assembly can
be deployed on a machine at the same time. Application configuration information defines where to look for
assemblies, thus the runtime can load different versions of the same assembly for two different applications that are
running concurrently. This eliminates issues that arise from incompatibilities between component versions,
improving overall system stability. If necessary, administrators can add configuration information, such as a
different versioning policy, to assemblies at deployment time, but the original information provided at build time is
never lost.
Because assemblies are self-describing, no explicit registration with the operating system is required. Application
deployment can be as simple as copying files to a directory tree. (Things are slightly more complicated if
unmanaged components must be installed for the application to work.) Configuration information is stored in XML
files that can be edited by any text editor.

2.1.4. Integrated security services

Finally, the runtime also supplies integrated, pervasive security services to ensure that unauthorized users cannot
access resources on a machine and that code cannot perform unauthorized actions. This improves overall system
safety and reliability. Since the runtime is used to load code, create objects, and make method calls, the runtime can
perform security checks and enforce security policy as managed code is loaded and executed.
The Microsoft .NET Framework provides both code access security and role-based security. With code access
security, developers can specify the required permissions their code needs to accomplish work. For example, code
may need permission to write a file or access environment variables. This information is stored at the assembly
level, along with information about the identity of the code. At load time and on method calls, the runtime verifies
that the code can be granted the permissions it has asked for. If not, a security violation is reported. Policies for
granting permissions, known as trust policies, are established by system administrators, and are based on evidence
about the code such as who published the code and where it was obtained from, as well as the identity and requested
permissions found in the assembly. Developers can also specify permissions they explicitly don't want, to prevent
malicious use of their code by others. Programmatic security checks can be written if the permissions required
depend on information that isn't known until runtime.
In addition to code access security, the runtime supports role-based security. Role-based security builds on the same
permissions model as code access security, except that the permissions are based on user identity rather than code
identity. Roles represent categories of users and can be defined at development or deployment time. Policies for
granting permissions are assigned to each defined role. At runtime, the identity of the user on whose behalf the code
is running is determined. The runtime determines what roles the user is a member of and then grants permissions
based on those roles.

2.2. Building applications that support CLR

When building applications or re-usable types (components) for the .NET Framework, you must first select a CLR-
based programming language that you intend to write your source code in. The .NET Framework supports several
programming languages including C#, J#, C++ with Managed Extensions, Visual Basic .NET, Cobol, Perl and many
more. The language you choose will determine how you express your intentions to the .NET Framework.
Once you've written your source code, you run it through the corresponding language compiler and the compiler
produces an assembly file. An assembly file contains Microsoft Intermediate Language (MSIL) and metadata.
Normally, compilers produce binary CPU instructions specific to the CPU you intend to you run your code on.
However, MSIL is an intermediate language that is CPU- independent. That is, at runtime the CLR compiles the
MSIL code into native CPU code. If you are running the application on a Pentium machine, then the CLR produces
native x86 code. If you are running the application on an Itanium machine, then the CLR produces native IA64
code.
In addition to the MSIL, the assembly file also contains metadata. Metadata is a set of tables that are embedded in
the assembly file. These tables are produced by the compiler and contain a great deal of information about the
application. For example, metadata has tables that describe all of the types, methods, and fields that were defined by
the application's source code. In addition, metadata also includes tables that describe all of the types, methods, and
fields that are referenced by methods in the application's source code. Metadata is very complete and is always
embedded in the assembly file ensuring that the metadata and the MSIL it describes are always in sync with one
another.

2.3. .NET Services Framework

On top of the common language runtime is the services framework. This framework provides a collection (called the
.NET Framework class library) of reusable types that tightly integrate with the common language runtime. All
classes within the collection comply with a set of naming and design guidelines to further reduce the learning curve
for developers. In addition, The class library is object oriented, providing types from which your own managed code
can derive functionality. This not only makes the .NET Framework types easy to use, but also reduces the time
associated with learning new features of the .NET Framework. In addition, third-party components can integrate
with classes in the .NET Framework.
The framework includes a base set of class libraries that developers would expect in a standard language library,
such as collections, input/output, string, and numerical classes. In addition, the base class library provides classes to
access operating system services such as graphics, networking, threading, globalization, and cryptography.
The framework types enable the developer to accomplish a range of common programming tasks, including tasks
such as string management, data collection, database connectivity, and file access. The services framework also
includes a data access class library, as well as classes that development tools can use, such as debugging and
profiling services. In addition to these common tasks, the class library includes types that support a variety of
specialized development scenarios. For example, you can use the .NET Framework to develop the following types
of applications and services:
• Console applications.
• Scripted or hosted applications.
 • Windows GUI applications (Windows Forms).
• ASP.NET applications.
• XML Web services.
• Windows services.

2.4. Class Library Namespaces

The .NET Framework class library is a library of classes, interfaces, and value types that are included in the
Microsoft .NET Framework SDK. This library provides access to system functionality and is designed to be the
foundation on which .NET Framework applications, components, and controls are built.
The System namespace contains fundamental classes and base classes that define commonly used value and
reference data types, events and event handlers, interfaces, attributes, and processing exceptions.
Other classes provide services supporting data type conversion, method parameter manipulation, mathematics,
remote and local program invocation, application environment management, and supervision of managed and
unmanaged applications. You can view the complete list of public classes included in the .NET framework SDK
here.

2.5. XML Web Services

One of today's most pressing challenges for the Bank, is application reuse, interoperability and integration; taking
different applications running on different operating systems built with different object models using different
programming languages and turning them into functional services.
The Shared Services Infrastructure's vision is to address this challenge via Web Services (or XML Web Services),
which is a set of technologies based on an open set of standards such as HTTP, XML, SOAP, WSDL, UDDI, etc.
Both J2EE and the .NET Framework provide open implementations of Web Services in addition to an environment
to create, deploy, secure, scale and maintain these services.

2.5.1. Understanding XML Web Services

Broadly speaking, a Web Service is simply an application delivered as a service that can be integrated with other
Web Services using Internet standards. In other words, it's an URL-addressable resource that programmatically
returns information to clients who want to use it. One important feature of Web Services is that clients don't need to
know how a service is implemented. In this section, I'll explain how Web Services combine the best aspects of
component-based technologies and the Web, and introduce the infrastructure needed to communicate with Web
Services.
Like components, Web Services represent black-box functionality that can be reused without worrying about how
the service is implemented. Web Services provide well-defined interfaces, called contracts that describe the services
provided. Developers can assemble applications using a combination of remote services, local services, and custom
code. Unlike current component technologies, however, Web Services do not use object model-specific protocols
such as DCOM, RMI, or IIOP that require specific, homogeneous infrastructures on both the client and service
machines. While these tightly coupled component technologies may be acceptable within a controlled environment,
they become impractical for heterogeneous environments. As the set of participants in an integrated business process
changes, and as technology changes over time, it becomes very difficult to guarantee a single, unified infrastructure
among all participants. Web Services take a different approach; they communicate using ubiquitous Web protocols
and data formats such as HTTP and XML. Any system supporting these Web standards will be able to support Web
Services.
Furthermore, a Web Service contract describes the services provided in terms of the messages the Web Service
accepts and generates rather than how the service is implemented. By focusing solely on messages, the Web
Services model is completely language, platform, and object model-agnostic. A Web Service can be implemented
using the full feature set of any programming language, object model, and platform. A Web Service can be
consumed by applications implemented in any language for any platform. As long as the contract that explains the
service's capabilities and the message sequences and protocols it expects is honored, the implementations of Web
Services and Web Service consumers can vary independently without affecting the application at the other end of
the conversation.
The minimum infrastructure required by the Web Services model is purposefully low to help ensure that Web
Services can be implemented on and accessed from any platform using any technology and programming language.
The key to Web Service interoperability is reliance solely on Web standards. However, simply agreeing that Web
Services should be accessed through standard Web protocols is not sufficient to make it easy for applications to use
Web Services. Web Services become easy to use when a Web Service and Web Service consumer rely on standard
ways to represent data and commands, to represent Web Service contracts, and to figure out the capabilities a Web
Service provides.
XML is the obvious choice for defining a standard yet extensible language to represent commands and typed data.
While rules for representing commands and typed data using other techniques (such as encoding as a query string)
could be defined, XML is specifically designed as a standard metalanguage for describing data. The Simple Object
Access Protocol (SOAP) is an industry standard for using XML to represent data and commands in an extensible
way. A Web Service can choose to use SOAP to specify its message formats.

2.5.2. XML Web Services Fundamentals

There is some debate over the exact definition of Web services. At a minimum, however, a Web service is any piece
of software that makes itself available over the Internet and uses a standardized XML messaging system.
XML is used to encode all communications to a Web service. For example, a client invokes a Web service by
sending an XML message, then waits for a corresponding XML response. Because all communication is in XML,
Web services are not tied to any one operating system or programming language. For instance, Java can talk with
Perl; Windows applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and potentially desirable) properties:
• First, a Web service can have a public interface, defined in a common XML grammar or schema (XSD).
The interface describes all the methods available to clients and specifies the signature for each method.
Currently, interface definition is accomplished via the Web Service Description Language (WSDL).
• Second, if you create a Web service, there should be some relatively simple mechanism for you to publish
this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and
locate its public interface. The most prominent directory of Web services is currently available via UDDI,
or Universal Description, Discovery, and Integration.
2.5.2.1. XML Schema Definition (XSD)
XML Schema is a W3C Recommendation (a standard) as of May 2, 2001. The XML Schema definition language
(XSD) enables you to define the structure and data types for XML documents. An XML Schema defines the
elements, attributes, and data types that conform to the World Wide Web Consortium (W3C) XML Schema Part 1:
Structures Recommendation for the XML Schema Definition Language. The W3C XML Schema Part 2: Datatypes
Recommendation is the recommendation for defining data types used in XML schemas.
2.5.2.2. Web Services Description Language (WSDL)
The Web Services Description Language (WSDL) currently represents the service description layer within the Web
service protocol stack. WSDL defines an XML-based grammar for describing network services as a set of endpoints
that accept messages containing either document-oriented or procedure-oriented information. The operations and
messages are described abstractly. They are bound to a concrete network protocol and message format to define an
endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow
the description of endpoints and their messages regardless of what message formats or network protocols are being
used to communicate.
2.5.2.3. Simple Object Access Protocol (SOAP)
SOAP is a lightweight and simple XML-based protocol that is designed to exchange structured and typed
information on the Web. The purpose of SOAP is to enable rich and automated Web services based on a shared and
open Web infrastructure. SOAP can be used in combination with a variety of existing Internet protocols and formats
including HTTP, SMTP, and MIME and can support a wide range of applications from messaging systems to RPC.
2.5.2.4. Universal (SOAP)
UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web
services protocol stack. The UDDI specification defines a SOAP-based Web service for locating Web services and
programmable resources on a network. UDDI provides a foundation for developers and administrators to readily
share information about internal services across the enterprise and public services on the Internet.
2.5.3. Implementing XML Web Services in .NET

.NET natively supports XML Web Services. In other words, .NET provides the infrastructure and building blocks,
which greatly simplify development and deployment efforts, associated with XML Web Services. The .NET
framework core libraries includes the Sytem.Web.Services namespace, which component developers may use
to add web services functionality to their application.
 Overview of non-Win32 Implementations of .NET Foundations

1. Introduction

While .NET (platform / framework) originated as a commercial effort by Microsoft as it's next-generation Win32
technology, the framework is garnering interest in the non-Microsoft development community. Some of the reasons
include:
• The framework is largely based on industry standards.
• The framework promotes a well-defined, hierarchical set of APIs.
• The framework promotes contract/interface-based programming.
• The framework has support for multiple languages.
• The framework has native support for web services.
Based on the above, .NET has caught the attention of the Open Source community and efforts are underway to
create non-Win32 implementations of the .NET foundations (core runtime, class libraries, etc.) - primarily targeted
at the Lintel platform. This document will describe the most popular implementations and describe why this is
relevant to the Shared Services Infrastructure (SSI).

1.1. The Importance of this Document

It is expected that there will be an increasing need at the Bank to support web-based applications and web services
that are based on .NET (typically third party). As the SSI is composed of both Linux and Win2K servers we need to
understand the viability of hosting .NET applications in a mixed (Linux and Win2k) environment.

1.2. Document Scope

This document describes non-Win32 implementations of the .NET framework foundations. This document provides
an overview of these implementations and assumes the reader has a basic knowledge of the .NET framework.

1.3. Audience

This document is intended for use by anyone developing or integrating solutions for the SSI platform. The intended
audience is solution developers (including both component and user interface developers), project managers or
anyone involved in the activities of designing and developing solutions to run on the SSI. The document assumes a
working knowledge of web-based applications.

2. Relevance of non-Win32 Implementations to the SSI

The are two reasons why non-Win32 implementations are relevant to the Shared Services Infrastructure:
1. Adherence to Huron recommended standards.
2. Provide flexibility in the choice of platforms and, as a result, avoid vendor lock-in.
The Shared Services Infrastructure currently supports Win32-based servers (Windows 2000 Server). In the near
future it is planned to add Linux-based servers to the platform. While Java (specifically J2EE) is the preferred
application environment - in part because it is by nature cross-platform - .NET is a vendor-sponsored initiative that
will have sufficient market penetration to merit support. Thus we need to understand the implications of running
.NET-based technology solutions on non-Win32 platforms with an emphasis on Linux on Intel (Lintel).

3. Current non-Win32 Implementations of .NET

There are currently three significant efforts underway to create non-Win32 implementations of the .NET
foundations. Each have somewhat different goals in mind and are discussed in greater detail in the following
sections. The three implementations are:
• Mono,
• DotGNU and
 • Rotor.
4. Mono

The Mono Project is an initiative sponsored by Ximian. It is, at its core, an open source Linux version of the
Microsoft .NET development platform. Its objective is to enable Linux developers to build and deploy cross-
platform applications that include .NET technologies. The project will implement various pieces of the .NET puzzle
that Microsoft have now submitted to either the European Computer Manufacturers Association (ECMA), Institute
of Electrical and Electronics Engineers (IEEE) or the World-Wide Web Consortium (W3C) for standardization.
Mono is an implementation of the development framework only. This means that it while it implements features
including the common language runtime (CLR) and C# compiler it does not provide ancillary services such as
Passport or software-as-a-service.
Mono includes a compiler for the C #language, a runtime for the Common Language Infrastructure (also referred as
the CLR) and a set of class libraries. The runtime can be embedded in your application. Mono has implementations
of both ADO.NET and ASP.NET as part of its distribution.
The various pieces that will make up Mono include:
• A C# compiler.
• The Virtual Execution System that will have the Just-in-Time compiler, garbage collector, loader, threading
engine.
• A byte code interpreter will be provided for quickly porting Mono to new systems and for debugging
during the development process. It is not intended to be the ideal execution environment.
• An implementation of the .NET class library.
• Visual development tools.
• A CIL GCC front-end.

4.1. Mono and GNOME

GNOME is an umbrella project that consists of infrastructural components (GUI toolkit, XML libraries, CORBA
implementation, printing architecture, imaging system), a desktop environment, and productivity applications. The
GNOME infrastructural components can be used to quickly implement various pieces of Mono's .NET class libraries
without reinventing the wheel. All these components are licensed under the terms of the GNU LGPL. Libart will be
used to implement the Drawing.2D API; Gtk+ and the GNOME libraries will be used to implement the WinForms
API and Glib and libxml will be used in various places.

4.2. Current Plans and Status for Mono

(January 2003) Taking advantage of the standards, Mono developers have pledged to release sometime this year the
"Mono Core," which will mimic the .Net Framework for Linux and UNIX operating systems. However, even Mono
members admit that there is still much work to be done before the first version of Mono is released.
Mono developers have yet to recreate the Windows Forms, Ximian said. The group has, however, completed a JIT
(just-in-time) run-time engine, and a C# compiler that is self-hosting, which means it can automatically compile an
application written in C# to run on Linux or UNIX systems.

5. DotGNU

DotGNU is a Free Software project to create a platform for webservices that can be written in a variety of different
programming languages including Java and C#. The main objectives of DotGNU are to build a webservices platform
and a Virtual Identities system.

5.1. DotGNU and GNU

GNU is the umbrella project for DotGNU, which itself is a meta-project that will consist of several other software
development projects.
5.2. DotGNU Software Development Projects

There are two main tracks of development of DotGNU, each of which can have any number of DotGNU projects.
These tracks are:
• DotGNU Platform
• DotGNU Virtual Identities

5.2.1. DotGNU Platform

The DotGNU Platform is a loosely arranged set of components designed for the execution of webservices. At the
time of this writing it consists of the following major components:
• DotGNU Portable.NET
The goal of this DotGNU Portable.NET is to provide a runtime engine, core library and suite of free
software tools to build and execute .NET applications, including a C# compiler, assembler, disassembler.
The initial target platform is GNU/Linux, with other platforms to follow in the future.
DotGNU Portable.NET is focused on compatibility with the ECMA specifications for CLI. There are other
projects under the DotGNU meta-project to build other necessary pieces of infrastructure, and to explore
non-CLI approaches to virtual machine implementation.
• Support for Java bytecode
As an alternative to C# and CLR, DotGNU hopes to support Java and other languages that can be compiled
to Java bytecode. Plans are in the works to create a JVM implementation for the DotGNU Platform.
• DotGNU Secure Execution Environment
Portable Executables that come in one of the multiple bytecode formats supported by the DotGNU platform
will be executed in a DotGNU Secure Execution Environment (SEE). In order to facilitate remote
execution, this will probably be implemented as a daemon, and there is code for a test daemon called
Andromeda, which demonstrated how plugins could be bound to the daemon.
• DotGNU Distributed Execution Environment
DotGNU's Distributed Execution Environment will be like an operating system for a "distributed
computer" consisting of several instances of the "DotGNU Secure Execution Environment" that are running
on several computers. This system must be able to take care of replicating databases across all the parts of
this "distributed computer" and propagating updates.

5.2.2. DotGNU Virtual Identities

This will be a totally decentralized authentication / personal information system that can compete with Microsoft's
"Passport" system. This system will eventually implemented as an application that runs on the DotGNU platform.
Unlike other applications it makes sense to develop this application under the umbrella of the DotGNU meta-project,
because authentication is also an essential component of every operating system.

5.3. Current Plans and Status for DotGNU

(January 2003) DotGNU is beginning it's third year of maturation. Many of the original plans have been replaced
along with new projects being added. One of the continuing problems is the lack of developers. The other big
problem is lack of code. For the architecture projects the ground work of specification writing had to be
accomplished first before any code could be written, luckily the specs are in the final phase and coding work is
expected to begin soon.
Despite these problems the Portable.NET project reached it's most important milestone, the compiler can now
compile the baselib removing dependency on the Microsoft C# compiler.
In the fall of 2002 the organization of DotGNU was reorganized. Working Groups were created to support
cooperation between similar projects. The leaders of all the Working Groups come together in the DotGNU
Working Group, which effectively acts like a cabinet for DotGNU. The role of the Steering Committee was scaled
down a bit to that of high court. The SC still acts as the highest power in DotGNU, but it doesn't set out the course
anymore.
Last but not least the focus of DotGNU is beginning to shift from providing as much compatibility with .NET as
possible to building a webservice supporting system which is only compatible with .NET where absolutely needed.
The DotGNU system will be a bridge which applications can use to communicate with other applications regardless
of where those applications run, in what language they are written, etc.

6. Rotor

Microsoft teamed with Corel to build a shared source implementation of the C# programming language and
common language infrastructure (CLI) specifications. The project, code named "Rotor", has successfully released a
beta version of the Shared Source CLI. The Shared Source CLI consists of the following features:
• An implementation of the runtime for the Common Language Infrastructure (ECMA-335) that builds and
runs on Windows XP and FreeBSD.
• Compilers that work with the Shared Source CLI for C# (ECMA-334) and JScript
• Development tools for working with the Shared Source CLI such as assembler/disassemblers (ilasm,
ildasm), a debugger (cordbg), metadata introspection (metainfo), and many other utilities.
• The Platform Adaptation Layer (PAL) used to port the Shared Source CLI from Windows XP to FreeBSD
• The build environment tools (nmake, build, and others)
• Complete documentation for the implementation.
• Test suites used to verify the implementation.
Recently, a Linux port of Rotor was made available and has passed 94% of its tests. See Rotor for Linux.

7. Conclusion

While each of the non-Win32 implementations are not as feature-rich as their Microsoft conterpart it is within
reason to expect a modest level of cross-platform support for .NET with these frameworks. The level of support is
likely to be sufficient for most scenarios.
Of the three development frameworks (Mono, DotGnu and Rotor) Mono is considered the best fit for the Shared
Services Infrastructure, as it offers the widest support for both Linux and Windows and is expected to provide full
support for the .NET core libraries.
When extending .NET applications which are expected to run within the SSI it is important that a single
development framework and language be adopted as a standard for future development. It is our recommendation
that these extensions be written using the Mono development framework and that the choice of development
language be C#.