Component Requirements

March 15, 2008 at 10:05 am (COM, Unit 5) (COM)

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.
<!--[if !supportLists]-->1. <!--[endif]-->Components must link
dynamically
<!--[if !supportLists]-->2. <!--[endif]-->Components must hide (or
encapsulate) the details of how they were implemented.
<!--[if !supportLists]-->1. <!--[endif]-->Dynamic Linking
<!--[if !supportLists]-->• <!--[endif]-->The ultimate goal of this is to
have an end user replace components in an application while that
application is running.
<!--[if !supportLists]-->• <!--[endif]-->Support for changing
components at run time requires the ability of dynamically link
components together.
<!--[if !supportLists]-->• <!--[endif]-->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.
<!--[if !supportLists]-->2. <!--[endif]-->Encapsulation
<!--[if !supportLists]-->• <!--[endif]-->A program or a component
that uses another component is called the client. A client is
connected to a component through an interface.
<!--[if !supportLists]-->• <!--[endif]-->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.
<!--[if !supportLists]-->• <!--[endif]-->However, if changing either
the component or the client changes the interface, the other side of
the interface must also change.
<!--[if !supportLists]-->• <!--[endif]-->Therefore, to take advantage
of dynamic linking, components and clients must strive not to change
their interfaces. They must be encapsulated.
<!--[if !supportLists]-->• <!--[endif]-->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 !supportLists]-->• <!--[endif]-->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.
<!--[if !supportLists]-->1.<!--[endif]-->The component must hide
the computer language used for its implementation. Exposing the
implementation language creates new dependencies between the
client and the component.
<!--[if !supportLists]-->2. <!--[endif]-->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.
<!--[if !supportLists]-->3.<!--[endif]-->Components must be
upgradable without breaking existing users. New versions of a
component should work with both old and new clients.
<!--[if !supportLists]-->4. <!--[endif]-->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.

Permalink Leave a Comment

COM : Fundamentals
March 15, 2008 at 9:21 am (COM, Unit 5) (COM)

COM

• <!--[if !supportLists]--> <!--[endif]-->COM is a specification

• <!--[if !supportLists]--> <!--[endif]-->It specifies how to build components that can be
dynamically interchanged.
• <!--[if !supportLists]--> <!--[endif]-->COM provides the standard that components and
clients follow to ensure that they can operate together.
• <!--[if !supportLists]--> <!--[endif]-->The COM specification is a document that sets the
standard for the component architecture.

What are COM Components?

 • <!--[if !supportLists]--> <!--[endif]-->COM component consists of executable code
distributed either as Win32 dynamic link libraries (DLLs) or as executables (EXEs).
• <!--[if !supportLists]--> <!--[endif]-->Components written to the COM standard meet all
requirements for component architecture.
• <!--[if !supportLists]--> <!--[endif]-->COM components link dynamically using DLLs.
• <!--[if !supportLists]--> <!--[endif]-->COM components can be encapsulated easily
because:

<!--[if !supportLists]-->o <!--[endif]-->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.
<!--[if !supportLists]-->o <!--[endif]-->Any language can be modified to use COM
components, including Smalltalk and Visual Basic.
<!--[if !supportLists]-->o <!--[endif]-->COM components can be shipped in binary
form.
<!--[if !supportLists]-->o <!--[endif]-->COM components can be upgraded without
breaking old clients. Because it provides a standard way to implement different
versions of a component.
<!--[if !supportLists]-->o <!--[endif]-->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.

• <!--[if !supportLists]--> COM components announce their existence in a standard way.

Using COM’s publication scheme, clients can dynamically find the components they
need to use.
• <!--[endif]-->COM components are a great way to provide object-oriented APIs or
services to other applications.
• <!--[if !supportLists]--> <!--[endif]-->COM components are also great for building
language-independent component libraries from which applications can be rapidly built.

COM is not…

• <!--[if !supportLists]--> <!--[endif]-->COM is not a computer language.

• <!--[if !supportLists]--> <!--[endif]-->COM does not compete with computer languages.
• <!--[if !supportLists]--> <!--[endif]-->COM tells how to write components.
• <!--[if !supportLists]--> <!--[endif]-->COM also does not compete with or replace DLLs.
• <!--[if !supportLists]--> <!--[endif]-->COM uses DLLs to provide components with the
ability to dynamically link.
• <!--[if !supportLists]--> <!--[endif]-->COM is not primarily an API or a set of functions
like the Win32 API.
• <!--[if !supportLists]--> <!--[endif]-->COM does not provide services such as
MoveWindow or the like.
• <!--[if !supportLists]--> <!--[endif]-->COM is not a C++ class library like the Microsoft
Foundation Classes (MFC).
 • <!--[if !supportLists]--> <!--[endif]-->COM provides a way to develop language-
independent component libraries, but COM does not provide any implementation.

The COM Library

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

Permalink Leave a Comment

COM and CORBA Side by Side

March 14, 2008 at 11:31 am (COM, CORBA, Unit 5) (COM, CORBA)

Trait Similarities Differences

Interfaces Each uses their own CORBA IDL is simpler an elegant

IDL to describe than COM IDL
interfaces. COM has better tool support for
creating and managing IDL than
CORBA
Datatypes Both support a rich set COM has automation types.
of data types Automation compatible interfaces
Both also support are supported in more client
constants, enumerated environments than non-compatible
types, structures and interfaces. Because the non-
arrays. compatible interfaces are not
guaranteed to work other than C++.
Any CORBA interface can be used
 from any CORBA client

Proxies, COM and CORBA rely COM client & server stubs are called
Stubs & on client stubs and as Proxy & Stub and in CORBA called
Skeletons server stubs to handle as Stub & Skeleton.
remoting issues. COM proxy-stub DLLs are used by all
COM & CORBA language environments. In CORBA, a
generate client stubs separate stub-skeleton must be
and server stubs from generated for each ORB/language
IDL. combination.
Marshaling & COM and CORBA COM allows automation-compatible
Unmarshaling handle marshaling in interfaces to use type library
client stubs and server marshaling, thus eliminating the
stubs. Users do not need for customized stubs.
need to worry about
marshaling.
Object COM & CORBA support COM calls object handles as
Handles reference counted interface pointers and CORBA calls
handles on object as object references.
instances. CORBA supports multiple
inheritance in the interface
hierarchy. COM supports single
inheritance only; however a COM
object supports more than one
distinct interface.
Object Both use factories to COM has a standard factory
Creation create objects interface called IClassFactory CORBA
instances. factories are customized persistent
CORBA objects.
Object Both allow for method COM’s error-handling mechanism is
Invocation invocation similar to based on HRESULT return values.
native environment CORBA supports user-defined
method invocation. exception types in IDL.
Object COM and CORBA rely COM supports distributed reference
Destruction on reference counting counting and garbage collection.
to determine when an CORBA reference counts are
object can be maintained separately in the client
destroyed and server.

Permalink 1 Comment

DCOM – CORBA Comparison

March 11, 2008 at 3:39 pm (COM, CORBA, Slides, Unit 5) (COM, CORBA, Slides)
Click here to view the SlideShow

DCOM – CORBA Comparison

DCOM Vs CORBA

Permalink Leave a Comment

DCOM Vs CORBA
March 10, 2008 at 3:35 pm (COM, CORBA, Unit 5) (COM, CORBA)

Differences DCOM CORBA

Focus Desktop first; Enterprise first; desktop
enterprise second
second
Platforms Windows NT; MVS, UNIX, Windows (all),
support for Macintosh
Windows (all),
Macintosh,
UNIX, MVA
Availability Single vendor; Multi-vendor
availability from
other vendors
expected
Service ActiveX- Significant number of
differences interactive additional services, including
content standard 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 Products since 1992; many
1996; decade- services and facilities under
long evolution of construction
OLE and COM
products; most
services and
facilities under
construction
Language C, C++; working C++, Smalltalk, Ada95; JAVA
Binding on JAVA, Visual and COBOL
Basic, Ada

Interface Supports Multiple Inheritance;

Inheritance aggregation but interfaces are classes.
not inheritance;
interfaces are not
classes.

Permalink Leave a Comment

Similarities between DCOM and CORBA

March 10, 2008 at 3:29 pm (COM, CORBA, Unit 5) (COM, CORBA)

Similarities DCOM CORBA

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

Permalink Leave a Comment

Marshaling and Remoting

March 4, 2008 at 5:33 pm (.NET, Unit 5) (.NET)
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.

Permalink Leave a Comment

Compilation and the MSIL

March 4, 2008 at 5:25 pm (.NET, Unit 5) (.NET)

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#.

The .NET Framework

March 4, 2008 at 5:21 pm (.NET, Unit 5) (.NET)

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:

<!--[if !supportLists]-->• <!--[endif]-->Four official languages: C#, VB.NET, Managed C++,

and JScript.NET

<!--[if !supportLists]-->• <!--[endif]-->The CLR, an object-oriented platform for Windows

and web development that all these languages share

<!--[if !supportLists]-->• <!--[endif]-->A number of related class libraries, collectively

known as the FCL

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.

Permalink 1 Comment

Introduction to .NET
March 4, 2008 at 5:15 pm (.NET, Unit 5) (.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.