Component Requirements

The advantage of using components result directly from their ability to dynamically plug into and unplug from an application. In order to achieve this capability , components must meet two requirements. 1. 2. 1. Components must link dynamically Components must hide (or encapsulate) the details of how they were implemented. The ultimate goal of this is to have an end user replace components in an application while that application is running. Support for changing components at run time requires the ability of dynamically link components together. In distributed environment there is no assurance that the component will be idle for modification. So, components should have facility to update or replace them while it is used by other system in the network. A program or a component that uses another component is called the client. A client is connected to a component through an interface. If the component changes without changing the interface, the client doesnt have to change. Similarly, if the client changes without changing the interface, the component doesnt have to change. However, if changing either the component or the client changes the interface, the other side of the interface must also change. Therefore, to take advantage of dynamic linking, components and clients must strive not to change their interfaces. They must be encapsulated. The more the interface is isolated from implementation details, the less likely the interface will change as a result of changing the client or the component. If the interface doesnt change, changing a component will have little effect on the rest of the application.

Dynamic Linking

2.

Encapsulation

Isolating the client from the components implementation puts some important constraints on the component. The following is a list of these constraints. 1. The component must hide the computer language used for its implementation. Exposing the implementation language creates new dependencies between the client and the component. Components must be shipped in a binary form. If components are to hide their implementation language, they must be shipped already compiled, linked and ready to use.

2.

3.

Components must be upgradable without breaking existing users. New versions of a component should work with both old and new clients.

4. Components must be transparently relocatable on a network. A component and the program that uses it should be able to run in the same process, in different processes, or on different machines. The client should be able to treat a remote component the same way it treats a local component.

COM : Fundamentals
COM

COM is a specification It specifies how to build components that can be dynamically interchanged. COM provides the standard that components and clients follow to ensure that they can operate together. The COM specification is a document that sets the standard for the component architecture.

What are COM Components? COM component consists of executable code distributed either as Win32 dynamic link libraries (DLLs) or as executables (EXEs). Components written to the COM standard meet all requirements for component architecture. COM components link dynamically using DLLs. COM components can be encapsulated easily because: o COM components are fully language independent. They can be developed using almost any procedural language Ada to C to Java to Modula-3 to Oberon to Pascal. o Any language can be modified to use COM components, including Smalltalk and Visual Basic. o COM components can be shipped in binary form. o COM components can be upgraded without breaking old clients. Because it provides a standard way to implement different versions of a component. o COM components can be transparently relocated on a network. A component on a remote system is treated the same as a component on the local system. COM components announce their existence in a standard way. Using COMs publication scheme, clients can dynamically find the components they need to use. COM components are a great way to provide object-oriented APIs or services to other applications. COM components are also great for building language-independent component libraries from which applications can be rapidly built.

COM is not COM is not a computer language. COM does not compete with computer languages. COM tells how to write components.

COM also does not compete with or replace DLLs. COM uses DLLs to provide components with the ability to dynamically link. COM is not primarily an API or a set of functions like the Win32 API. COM provides a way to develop language-independent component libraries, but COM does not provide any implementation.

The COM Library COM has an API, the COM library, which provides component management services that are useful for all clients and components. Most of the functions in the API are not too difficult to implement when developing COM-style components on a non-Windows system. The COM library was written to guarantee that the most important operations are done in the same way for all components. The COM library also saves developers time implementing their own components and clients. Most of the code in the COM library is support for distributed or networked components. The Distributed COM (DCOM) implementation on Windows System provides the code needed to communicate with components over a network. This reduces to write the networking code.

COM and CORBA Side by Side

Trait
Interfaces

Similarities
Each uses their own IDL to describe interfaces.

Differences
CORBA IDL is simpler an elegant than COM IDL COM has better tool support for creating and managing IDL than CORBA

Datatypes

Both support a rich set of data types Both also support constants, enumerated types, structures and arrays.

COM has automation types. Automation compatible interfaces are supported in more client environments than non-compatible interfaces. Because the non-compatible interfaces are not guaranteed to work other than C++. Any CORBA interface can be used from any CORBA client COM client & server stubs are called as Proxy & Stub and in CORBA called as Stub & Skeleton. COM proxy-stub DLLs are used by all language environments. In CORBA, a separate stubskeleton must be generated for each ORB/language combination.

Proxies, Stubs & Skeletons

COM and CORBA rely on client stubs and server stubs to handle remoting issues. COM & CORBA generate client stubs and server stubs from IDL.

Marshaling & Unmarshali ng Object Handles

COM and CORBA handle marshaling in client stubs and server stubs. Users do not need to worry about marshaling. COM & CORBA support reference counted handles on object instances.

Object Creation

Both use factories to create objects instances.

Object Invocation

Both allow for method invocation similar to native environment method invocation. COM and CORBA rely on reference counting to determine when an object can be destroyed

Object Destructio n

COM allows automationcompatible interfaces to use type library marshaling, thus eliminating the need for customized stubs. COM calls object handles as interface pointers and CORBA calls as object references. CORBA supports multiple inheritance in the interface hierarchy. COM supports single inheritance only; however a COM object supports more than one distinct interface. COM has a standard factory interface called IClassFactory CORBA factories are customized persistent CORBA objects. COMs error-handling mechanism is based on HRESULT return values. CORBA supports user-defined exception types in IDL. COM supports distributed reference counting and garbage collection. CORBA reference counts are maintained separately in the client and server.

DCOM CORBA Comparison DCOM Vs CORBA

Differences Focus Platforms Availability Service differences DCOM Desktop first; enterprise second Windows NT; support for Windows (all), Macintosh, UNIX, MVA Single vendor; availability from other vendors expected ActiveX-interactive content standard CORBA Enterprise first; desktop second MVS, UNIX, Windows (all), Macintosh Multi-vendor Significant number of additional services, including query, trader, transactions, as well as facilities in the areas of information management and system management. Lastly, services in areas such as finance, distributed simulation, and computer integrated manufacturing Products since 1992; many services

Maturity

NT shipped in 1996; decade-long

Language Binding Interface Inheritance

evolution of OLE and COM products; most services and facilities under construction C, C++; working on JAVA, Visual Basic, Ada Supports aggregation but not inheritance; interfaces are not classes.

and facilities under construction

C++, Smalltalk, Ada95; JAVA and COBOL Multiple Inheritance; interfaces are classes.

Similarities between DCOM and CORBA

Similarities Object Model Standards body Interface similarities Language independence Compound document model Location Transparency DCOM Yes Recently made formal; managed by the Active Group, an Open Group affiliate Microsoft IDL allows for specification of interface and implementation and provides a repository for storage of interfaces. Yes Yes-OLE Yes CORBA Yes Formal: managed by the Object Management Group CORBA IDL allows for separation of interface and implementation and provides a repository for storage of interfaces. Yes Yes-OpenDoc Yes

Marshaling and Remoting

The days of integrated programs all running in a single process on a single machine are, if not dead, at least seriously wounded. Todays programs consist of complex components running in multiple processes, often across the network. 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. 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. A process is essentially a running application. If an object in your word processor wants to interact with an object in your spreadsheet, they must communicate across process boundaries. 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. 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.

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; the platform is language-agnostic. A key fact about the CLR is that it is common: the same runtime supports development in C# as well as in VB.NET. 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 machines processor. 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 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#.

The .NET Framework

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 The

official languages: C#, VB.NET, Managed C++, and JScript.NET

CLR, an object-oriented platform for Windows and web development that all these languages share of related class libraries, collectively known as the FCL

A number

Figure breaks down the .NET Framework into its system architectural components.

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.) In Figure 1, 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. 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. Above this level is a tier of classes that extend the base classes to support data management and XML manipulation. 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. 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. Web Forms and Windows Forms allow you to apply Rapid Application Development techniques to building web and Windows applications. Simply drag and drop controls onto your form, double-click a control, and write the code to respond to the associated event.

Introduction to .NET
The .NET Platform
The .NET platform is a new development framework that provides a fresh application programming interface (API) to the services and APIs of classic Windows operating systems (especially the Windows 2000 family), while bringing together a number of disparate technologies. This includes COM+ component services, the ASP web development framework, a commitment to XML and object-oriented design, support for new web services protocols such as SOAP, WSDL, and UDDI, and a focus on the Internet, all integrated within the DNA architecture. The platform consists of four separate product groups: A set of languages, including C# and Visual Basic .NET, 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. For a fee, developers can use these services in building applications that require knowledge of user identity, etc. New .NET-enabled non-PC devices, from cell phones to game boxes.