AILEEN H. BANAGUAS Ph.D StudentCavite State University, Indang, CaviteEMGT 340 – MANAGEMENT INFORMATION SYSTEMDR. MARILYN M. ESCOBAR

LEARNING ACTIVITY 3

Component-Based Development As Another Approach for Information Systems Development

I. History of Component-Based Development

The idea that software should be componentized - built from prefabricated

components - first became prominent with Douglas McIlroy's address at the

NATO conference on software engineering in Garmisch, Germany, 1968,

titled Mass Produced Software Components. The conference set out to

counter the so-called software crisis. McIlroy's subsequent inclusion of pipes

and filters into the Unix operating system was the first implementation of an

infrastructure for this idea. Brad Cox of Stepstone largely defined the modern

concept of a software component. He called them Software ICs and set out to

create an infrastructure and market for these components by inventing the

Objective-C programming language. IBM led the path with their System

Object Model (SOM) in the early 1990s. Some claim that Microsoft paved the

way for actual deployment of component software with OLE and COM. As of

2010 many successful software component models exist.

II. Component Software Proposed by different Industries

Because the potential impact of reuse and CBSE on the software industry

is enormous, a number of major companies and industry consortia3 have

proposed standards for component software:

a) OMG/CORBA: The Object Management Group has published a common

object request broker architecture (OMG/CORBA). An object request broker

(ORB) provides a variety on services that enable reusable components

(objects) to system. When components are built using the OMG/CORBA

standard, integration of those components (without modification) within a

system is assured if an interface definition language (IDL) interface is created

for every component. Using a client/server metaphor, objects within the client

application request one or more services from the ORB server. Requests are

made via an IDL or dynamically at run time. An interface repository contains

all necessary information about the service’s request and response formats.

b) Microsoft COM:

Microsoft has developed a component object model (COM) that provides a

specification for using components produced by various vendors within a

single application running under the Windows operating system. COM

encompasses two elements: COM interfaces (implemented as COM objects)

and a set of mechanisms for registering and passing messages between

COM interfaces. From the point of view of the application, “the focus is not on

how [COM objects are] implemented, only on the fact that the object has an

interface that it registers with the system, and that it uses the component system

to communicate with other COM objects.”

c) SUN JavaBeans Components: The JavaBean component system is a portable,

platform independent CBSE infrastructure developed using the Java

programming language. The JavaBean system extends the Java applet4 to

accommodate the more sophisticated software components required for

component-based development. The JavaBean component system

encompasses

a set of tools, called the Bean Development Kit (BDK) that allows developers

to

(1) analyse how existing Beans (components) work, (2) customize their

behaviour

and appearance, (3) establish mechanisms for coordination and

communication.

(4) Develop custom Beans for use in a specific application, and (5) test and

evaluate Bean behaviour.

15. Common Object Request Broker Architecture:

The Common Object Request Broker Architecture (CORBA) is a standard

defined by

the Object Management Group (OMG) that enables software components

written in

multiple computer languages and running on multiple computers to work

together

(i.e., it supports multiple platforms).

CORBA is useful because it enables separate pieces of software written in

different

languages and running on different computers to work together like a single

application or set of services. More specifically, CORBA is a mechanism in

software

for normalizing the method-call semantics between application objects residin

either in the same address space (application) or remote address space

(same host,

or remote host on a network). Version 1.0 was released in October 1991.

CORBA

uses an interface definition language (IDL) to specify the interfaces which

objects

present to the outer world. CORBA then specifies a mapping from IDL to a

specific implementation language like C++ or Java. Standard mappings exist

for Ada, C, C++,

Lisp, Ruby, Smalltalk, Java, COBOL, PL/I and Python. There are also non-

standard

mappings for Perl, Visual Basic, Erlang, and Tcl implemented by object

request

brokers (ORBs) written for those languages.

The CORBA specification dictates there shall be an ORB through which an

application

would interact with other objects. In practice, the application simply initializes

the

ORB, and accesses an internal Object Adapter, which maintains things like

reference

counting, object (and reference) instantiation policies, and object lifetime

policies.

The Object Adapter is used to register instances of the generated code

classes.

Generated code classes are the result of compiling the user IDL code, which

translates the high-level interface definition into an OS- and language-specific

class

base for use by the user application. This step is necessary in order to

enforce CORBA

semantics and provide a clean user process for interfacing with the CORBA

infrastructure.

Some IDL language mappings are "more hostile" than others. For example,

due to

the nature of Java, the IDL-Java Mapping is rather straightforward and makes

usage

of CORBA very simple in a Java application. The C++ mapping is less

straightforward,

but it accounts for all CORBA features (e.g., exception handling). The C

mapping is

even stranger (since C is not an object-oriented language), but it does make

sense

and properly handles the RPC semantics.

A language mapping requires the developer ("user" in this case) to create

some IDL

code that represents the interfaces to his objects. Typically, a CORBA

implementation comes with a tool called an IDL compiler which converts the

user's

IDL code into some language-specific generated code. A traditional compiler

then

compiles the generated code to create the linkable-object files for the

application.

This diagram illustrates how the generated code is used within the CORBA

infrastructure:This figure illustrates the high-level paradigm for remote

interposes communica

http://arxiv.org/ftp/arxiv/papers/1011/1011.2163.pdf

END… A small step of obedience is a giant step to blessing