dot NET Framework

Unit - 5 Roy Antony Arnold G Lecturer Panimalar Engineering College Chennai, India

The .NET platform is a development framework that provides a new application programming interface (API) to the services and APIs of classic windows operating systems while bringing together a number of disparate technologies This includes COM+ component services , a commitment to XML and object-oriented design, support for new web services protocols such as SOAP , WSDL (Web Service Definition Language), and UDDI (Universal Description, Discovery, and Integration) and a focus on the Internet, all integrated within the Distributed interNet Applications ( DNA ) Architecture.

The platform consists of four product groups: Development tools A set of languages, including C# and VB A set of development tools including Visual Studio .NET, a comprehensive class library for building web services and web and Windows applications As well as the Common Language Runtime (CLR) to execute objects built within this framework. A set of .NET Enterprise Servers , formerly known as SQL Server 2000, Exchange 2000, BizTalk 2000, and so on, that provide specialized functionality for relational data storage, email, B2B commerce, etc. An offering of commercial web services , called .NET My Services. New .NET enabled non-PC devices , from cell phones to game boxes.

Microsoft .NET supports not only language independence , but also language integration . This means that you can inherit from classes, catch exceptions, and take advantage of polymorphism across different languages. The .NET Framework makes this possible with a specification called the Common Type System (CTS) that all .NET components must obey. For example, everything in .NET is an object of a specific class that derives from the root class called System.Object . The CTS supports the general concept of classes, interfaces, delegates (which support callbacks), reference types, and value types .

Additionally, .NET includes a Common Language Specification (CLS), which provides a series of basic rules that are required for language integration. The CLS determines the minimum requirements for being a .NET language. Compilers that conform to the CLS create objects that can interoperate with one another. The entire Framework Class Library (FCL) can be used by any language that conforms to the CLS.

The .NET Framework sits on top of the operating system, which can be any flavor of Windows, and consists of a number of components, currently including: Four official languages: C#, VB.NET, Managed C++, and JScript.NET The CLR, an object-oriented platform for Windows and web development that all these languages share A number of related class libraries, collectively known as the FCL

Web Services Web Forms Windows Forms

The most important component of the .NET Framework is the CLR, which provides the environment in which programs are executed. The CLR includes a virtual machine, analogous in many ways to the Java virtual machine. At a high level, the CLR activates objects, performs security checks on them, lays them out in memory, executes them, and garbage-collects them. (The Common Type System is also part of the CLR.)

Framework Class Library The layer on top of the CLR is a set of framework base classes, followed by an additional layer of data and XML classes, plus another layer of classes intended for web services, Web Forms, and Windows Forms. Collectively, these classes make up the FCL, one of the largest class libraries in history and one that provides an object-oriented API for all the functionality that the .NET platform encapsulates. With more than 4,000 classes, the FCL facilitates rapid development of desktop, client/server, and other web services and applications.

Framework Base Classes The set of Framework base classes, the lowest level of the FCL, is similar to the set of classes in Java. These classes support rudimentary input and output, string manipulation, security management, network communication, thread management, text manipulation, reflection and collections functionality, etc.

Data & XML Classes The data classes support persistent management of data that is maintained on backend databases. These classes include the Structured Query Language (SQL) classes to let you manipulate persistent data stores through a standard SQL interface. Additionally, a set of classes called ADO.NET allows you to manipulate persistent data. The .NET Framework also supports a number of classes to let you manipulate XML data and perform XML searching and translations.

Technologies Extending the Framework base classes and the data and XML classes is a tier of classes geared toward building applications using three different technologies: Web Services, Web Forms, and Windows Forms. Web services include a number of classes that support the development of lightweight distributed components, which will work even in the face of firewalls and NAT software. Because web services employ standard HTTP and SOAP as underlying communications protocols, these components support Plug and Play across cyberspace.

Compilation and the MSIL In .NET, programs are not compiled into executable files, they are compiled into Microsoft Intermediate Language (MSIL) files, which the CLR then executes. The MSIL (often shortened to IL) files C# produces are identical to the IL files that other .NET languages produce. C# code is compiled into IL when you build your project. The IL is saved in a file on disk. When you run your program, the IL is compiled again, using the Just In Time (JIT) compiler (a process often called JITing). The result is machine code, executed by the machine's processor. The CLS means that all .NET languages produce very similar IL code. As a result, objects created in one language can be accessed and derived from another. Thus it is possible to create a base class in VB.NET and derive from it in C#.

JIT Compiler The standard JIT compiler runs on demand . When a method is called, the JIT compiler analyzes the IL and produces highly efficient machine code, which runs very fast. The JIT compiler is smart enough to recognize when the code has already been compiled, so as the application runs, compilation happens only as needed. As .NET applications run, they tend to become faster and faster, as the already compiled code is reused.

The Web has facilitated distributed applications in a way that was unthinkable even a few years ago, and the trend is toward distribution of responsibility A second trend is toward centralizing business logic on large servers . Although these trends appear to be contradictory, in fact they are synergistic : business objects are being centralized while the user interface and even some middleware are being distributed . The net effect is that objects need to be able to talk with one another at a distance. Objects running on a server handling the web user interface need to be able to interact with business objects living on centralized servers at corporate headquarters.

Definitions The process of moving an object across a boundary is called remoting . Boundaries exist at various levels of abstraction in your program. The most obvious boundary is between objects running on different machines. The process of preparing an object to be remoted is called marshaling . On a single machine, objects might need to be marshaled across context, app domain, or process boundaries.

Application Domains & Contexts Processes are divided into application domains (often called app domains); these in turn are divided into various contexts . App domains act like lightweight processes , and contexts create boundaries that objects with similar rules can be contained within. At times, objects will be marshaled across both context and app domain boundaries, as well as across process and machine boundaries.

Formatter When an object is remoted, it appears to be sent through the wire from one computer to another The actual transmission of your message is done by a channel . The channel works with a formatter . The formatter makes sure the message is in the right format. The formatter can translate your message into a right format which can be understand by the remote system. The formatter is silently facilitating the communication.

Application Domains Each process is subdivided into one or more application domains . An app domain acts like a process but uses fewer resources. App domains can be independently started and halted. They are secure, lightweight, and versatile. An app domain can provide fault tolerance ; if you start an object in a second app domain and it crashes, it will bring down the app domain but not your entire program. You can imagine that web servers might use app domains for running users' code; if the code has a problem, the web server can maintain operations.

Methods and properties of the AppDomain class Method or property Details CurrentDomain Public static property that returns the current application domain for the current thread CreateDomain( ) Overloaded public static method that creates a new application domain GetCurrentThreadID( ) Public static method that returns the current thread identifier Unload( ) Public static method that removes the specified app domain FriendlyName Public property that returns the friendly name for this app domain DefineDynamicAssembly( ) Overloaded public method that defines a dynamic assembly in the current app domain

Contd… App domains also support a variety of events—including AssemblyLoad, AssemblyResolve, ProcessExit, and ResourceResolve —that are fired as assemblies are found, loaded, run, and unloaded. Method or Properties Details ExecuteAssembly( ) Public method that executes the designated assembly GetData( ) Public method that gets the value stored in the current application domain given a key Load( ) Public method that loads an assembly into the current app domain SetAppDomainPolicy( ) Public method that sets the security policy for the current app domain SetData( ) Public method that puts data into the specified app domain property

Context App domains themselves are subdivided into contexts . Contexts can be thought of as boundaries within which objects share usage rules . These usage rules include synchronization, transactions , and so forth. Context-Bound and Context-Agile Objects Objects are either context-bound or they are context-agile. If they are context-bound, they exist in a context, and to interact with them, the message must be marshaled. If they are context-agile, they act within the context of the calling object: their methods execute in the context of the object that invokes the method and so marshaling is not required.

Contd… An object has three choices. The first option is to be context-agile. A context-agile object operates in the context of its caller. Option two is to be context-bound (accomplished by deriving from ContextBoundObject but having no attributes, and thus operating in the context of the creator). Option three is to be context-bound with context attributes, and thus operate only in the context that matches the attributes . Which you decide upon depends on how your object will be used.

Marshaling Across Context Boundaries No proxy is needed when accessing context-agile objects within a single app domain. When an object in one context accesses a context-bound object in a second context, it does so through a proxy, and at that time the two context policies are enforced . It is in this sense that a context creates a boundary ; the policy is enforced at the boundary between contexts. when you mark a context-bound object with the System.EnterpriseServices.Synchronization attribute, you indicate that you want the system to manage synchronization for that object. All objects outside that context must pass through the context boundary to touch one of the objects, and at that time the policy of synchronization will be applied.

Contd… Objects are marshaled differently across context boundaries, depending on how they are created: Typical objects are not marshaled at all; within app domains they are context-agile . Objects marked with the Serializable attribute are marshaled by value across app domains and are context-agile. Objects that derive from MarshalByRefObject are marshaled by reference across app domains and are context-agile. Objects derived from ContextBoundObject are marshaled by reference across app domains as well as by reference across context boundaries.

Remoting In addition to being marshaled across context and app domain boundaries, objects can be marshaled across process boundaries, and even across machine boundaries. When an object is marshaled, either by value or by proxy , across a process or machine boundary, it is said to be remoted .

Understanding Server Object Types There are two types of server objects supported for remoting in .NET: well-known and client-activated. The communication with well-known objects is established each time a message is sent by the client . There is no permanent connection with a well-known object, as there is with client-activated objects. Client-activated objects are typically used by programmers who are creating dedicated servers , which provide services to a client they are also writing. In this scenario, the client and the server create a connection, and they maintain that connection until the needs of the client are fulfilled .

Types of Well-Known Object Well-known objects come in two varieties: singleton and single-call. With a well-known singleton object , all messages for the object, from all clients, are dispatched to a single object running on the server . The object is created when the server is started and is there to provide service to any client that can reach it . These objects must have a parameterless constructor . With a well-known single-call object , each new message from a client is handled by a new object . This is highly advantageous on server farms , where a series of messages from a given client might be handled in turn by different machines depending on load balancing.

dot NET Framework

More Related Content

What's hot

Viewers also liked

Similar to dot NET Framework

More from Roy Antony Arnold G

Recently uploaded

dot NET Framework