Component Requirements
|
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. Components must link dynamically 2. Components must hide (or encapsulate) the details of how they were implemented. 1. Dynamic Linking · 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. 2. Encapsulation · 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 doesn’t have to change. Similarly, if the client changes without changing the interface, the component doesn’t 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 doesn’t change, changing a component will have little effect on the rest of the application. Isolating the client from the component’s 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. 2. 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. 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 COM’s 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 does not provide services such as MoveWindow or the like.
- COM is not a C++ class library like the Microsoft Foundation Classes (MFC).
- 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 |
Similarities |
Differences |
|
Interfaces |
Each uses their own IDL to describe interfaces. |
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 |
|
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. |
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 stub-skeleton must be generated for each ORB/language combination. |
|
Marshaling & Unmarshaling |
COM and CORBA handle marshaling in client stubs and server stubs. Users do not need to worry about marshaling. |
COM allows automation-compatible interfaces to use type library marshaling, thus eliminating the need for customized stubs. |
|
Object Handles |
COM & CORBA support reference counted handles on object instances. |
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. |
|
Object Creation |
Both use factories to create objects instances. |
COM has a standard factory interface called IClassFactory CORBA factories are customized persistent CORBA objects. |
|
Object Invocation |
Both allow for method invocation similar to native environment method invocation. |
COM’s error-handling mechanism is based on HRESULT return values. CORBA supports user-defined exception types in IDL. |
|
Object Destruction |
COM and CORBA rely on reference counting to determine when an object can be destroyed |
COM supports distributed reference counting and garbage collection. CORBA reference counts are maintained separately in the client and server. |
DCOM Vs CORBA
|
Differences |
DCOM |
CORBA |
|
Focus |
Desktop first; enterprise second |
Enterprise first; desktop second |
|
Platforms |
Windows NT; support for Windows (all), Macintosh, UNIX, MVA |
MVS, UNIX, Windows (all), Macintosh |
|
Availability |
Single vendor; availability from other vendors expected |
Multi-vendor |
|
Service differences |
ActiveX-interactive content standard |
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 |
|
Maturity |
NT shipped in 1996; decade-long evolution of OLE and COM products; most services and facilities under construction |
Products since 1992; many services and facilities under construction |
|
Language Binding |
C, C++; working on JAVA, Visual Basic, Ada |
C++, Smalltalk, Ada95; JAVA and COBOL |
|
Interface Inheritance |
Supports aggregation but not inheritance; interfaces are not classes. |
Multiple Inheritance; interfaces are classes. |
Similarities between DCOM and CORBA
|
Similarities |
DCOM |
CORBA |
|
Object Model |
Yes |
Yes |
|
Standards body |
Recently made formal; managed by the Active Group, an Open Group affiliate |
Formal: managed by the Object Management Group |
|
Interface similarities |
Microsoft IDL allows for specification of interface and implementation and provides a repository for storage of interfaces. |
CORBA IDL allows for separation of interface and implementation and provides a repository for storage of interfaces. |
|
Language independence |
Yes |
Yes |
|
Compound document model |
Yes-OLE |
Yes-OpenDoc |
|
Location Transparency |
Yes |
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. Today’s 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 machine’s 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#.
