An Analysis of Component-based Software Development -Maximize the reuse of existing software

An Analysis of
Component-based
Software Development
-Maximize the reuse of existing software

by

Mohammad Salah Uddin

ID: 0857146

Supervised by

Dr. Nigel Kermode

IN PARTIAL FULFILMENT OF THE REQUIREMENT FOR THE AWARD OF MASTERS
OF SCIENCE (MSC) DEGREE IN INFORMATION TECHNOLOGY

Acknowledgements

I would like to express my gratitude to my dissertation supervisor Dr. Nigel Kermode, whose
expertise, understanding, and patience, added considerably to accomplish this achievement. I
appreciate his vast knowledge and skills of supervising. He always helped and guided me.

Also, I would like to thank my friends specially Devangkumar Patel, Xuan Tuyen and Edgar
Aguirre who have always helped and advised me during my entire dissertation.

Above all, I would also like to thank my family for the support they provided me through my
entire life. In particular, I must acknowledge my father and mother, without his love,
encouragement and financial assistance; I would not have finished this Dissertation.

Mohammad Salah Uddin/0857146 Page 2

Abstract

Component- based software development is the most promising way of controlling the
soaring complexity and cost of business information systems. It is also the best way to
architect, design, implement, and deploy scalable systems that provide the flexibility and
agility required by today‘s enterprise environment (Herzum, 1999).

The main role of component-based software engineering is to address the development of
systems as an assembly of parts ―components‖, the development of parts as reusable entities,
and the maintenance and upgrading of systems by customising and replacing such parts.
However, the component-based development is still a process with many problems, it is not
well defined either from theoretical or practical point of view. This dissertation gives a brief
overview of Component-Based Software development and starts with brief historical
evolution followed by a general explanation of the method. This dissertation also describes
the importance of reusable software and its architecture.

A detailed discussion of the underlying principles like components, component frameworks
and component system architectures are then presented. Some real world component stand
CORBA (Common Object Request Broker Architecture), CCM (CORBA component Model)
and EJB (Enterprise Java Beans) are given in detail. Finally, simple file-sharing-program
based on Apache's Avalon framework is developed as a case study.


Contents
Abstract ................................................................................................................................................... 3
1. Introduction ..................................................................................................................................... 6
1.1 Aims and Objectives................................................................................................................ 8
1.2 Initial Review ........................................................................................................................... 9
1.3 Method of Approach ............................................................................................................. 10
2. Component .................................................................................................................................... 11
2.1 Component definition ................................................................................................................. 11
2.2 Component Characteristics ......................................................................................................... 12
2.3 Relation between Component and Object ................................................................................... 13
2.4 Difference between Component and Object ............................................................................... 14
2.5 Differences between CBSE and Traditional SE ............................................................................ 15
2.6 The most significant benefits of using CBSE ............................................................................... 16
2.7 Importance of Reusability ........................................................................................................... 16
2.7.1 Why is reuse important? ...................................................................................................... 16
2.7.2 Is reuse really going to happen this time around? .............................................................. 18
2.7.3 How do we measure reuse? ................................................................................................ 19
2.8 Compromises for reuse components .......................................................................................... 19
2.9 Component Technologies ........................................................................................................... 21
2.9 Component Modelling Languages .............................................................................................. 21
3. Component Frameworks .............................................................................................................. 22
3.1 Component Framework Definition ............................................................................................. 22
3.1.1 Java 2 Platform, Enterprise Edition (J2EE) ........................................................................... 22
3.1.2 Microsoft .NET ..................................................................................................................... 23
3.2 .NET Framework.......................................................................................................................... 24
3.2.1 Common Language Infrastructure ....................................................................................... 25
3.2.2 Common Language Runtime ................................................................................................ 26
3.3 Enterprise JavaBeans, the Sun way............................................................................................. 27
3.3.1 EJB Component Types .......................................................................................................... 29
3.4 CORBA Architecture .................................................................................................................... 31
3.4.1 CORBA Component Model................................................................................................... 32
2.4.2 Component Object Model (COM) and Distributed COM (DCOM) ....................................... 32
3.4.3 CCM components ................................................................................................................. 33


3.4.4 Component Implementation Definition Language (CIDL).................................................... 34
4. Case Study Based on Avalon Framework ...................................................................................... 35
4.1 Introduction of Avalon Framework ............................................................................................. 35
4.2 Problem Statement ..................................................................................................................... 35
4.3 Phases of Component development........................................................................................... 36
4.5 System requirements .................................................................................................................. 36
4.6 Design the component ................................................................................................................ 37
4.6.1 Design Tools ......................................................................................................................... 37
4.6.2 Component design ............................................................................................................... 37
4.6.3 Design Documentation ........................................................................................................ 37
4.7 Component Development........................................................................................................... 38
4.7.1 Develop the component ...................................................................................................... 38
4.8 Tests and Result .......................................................................................................................... 40
4.8.1 Testing Types........................................................................................................................ 40
5. Discussion and Evaluation............................................................................................................. 42
5.1 Architectures’ Comparison ......................................................................................................... 42
5.3 Similarities ................................................................................................................................... 43
5.4 Assessment of the major component technologies ................................................................... 44
5.2 Case Study Assessment ............................................................................................................... 47
5.2.1 Assessment of Avalon Framework ....................................................................................... 47
5.3 Assessment of the Approach ...................................................................................................... 49
5.3.1 Component Security ............................................................................................................ 49
5.3.2 Language Independence ...................................................................................................... 50
5.4 Component designing methods for Reuse.................................................................................. 51
5.5 Component Search...................................................................................................................... 52
6. Conclusion ..................................................................................................................................... 54
Analysis of component-based software engineering ....................................................................... 54
Maximize the reuse of existing software .......................................................................................... 54
7. Achievements................................................................................................................................ 56
References ............................................................................................................................................. 57
Appendix A ............................................................................................................................................ 61


1. Introduction

The world of software development has evolved quickly in the last decade. Over the decades,
software has entered all domains that make up the necessary functions of our civilization.
Virtually all domains have incorporated Software to achieve better functionality that could
not be achieved earlier. Some examples are telecommunication, electricity generation and
distribution, logistic systems, modern cars and airplanes. Software is becoming more and
more an integrated part of the society. For instance, software has allowed new organizational
forms, such as business process reengineering and virtual organizations which allow
organizations to operate at efficiency levels that are an order of magnitude better than earlier
models. In addition all kinds of devices, which increase efficiency, would not be available
without software -for example current mobile phones.

Nowadays, organizations are realizing the need for explicit software architecture for their
systems. And software engineers are faced with the challenge of developing multiple, inter-
related systems from the scratch while pressured by financial and time constraints. It is
therefore essential to establish a well-defined design method in order to build high-quality,
reliable, and easily maintainable component or families of systems -the question is now how
to approach this?

The last decade has shown that object-oriented technology is not enough to cope with the
rapidly changing requirements of present-day applications. One of the reasons is that
although object-oriented methods develop rich models that reflect the objects of the problem
domain, this does not necessarily yield software architectures that can be easily adapted to
changing requirements. In particular, object-oriented methods do not lead to designs that
make a clear separation between computational and compositional aspects; this separation is
common in component-based systems.

On the other hand, Component-based systems achieve flexibility by clearly separating the
stable parts of the system (i.e. the components) from the specification of their composition.
Components are black box entities that encapsulate services behind well-defined interfaces.
These interfaces tend to be very restricted in nature, reflecting a particular model of plug-
compatibility supported by a component-framework, rather than being very rich and
reflecting real-world entities of the application domain.

Building new solutions by combining existing and made components improves and supports
rapid development, leading to a shorter time to market. At the same time, quick edition to
changing requirements can be achieved by only in key changes of a component-based


solution, rather than undertaking a major release change. That‘s why civil engineers have
established standardized, time-tested engineering principles to building bridges using
reusable parts, component-based software engineers must define and describe processes to
assure timely completion of high quality, complex software systems that are composed of a
variety of pre-built software components.

(Heineman , 2001)

Bringing the levels of reuse of software up to that of other engineering disciplines has long
been sought but not yet achieved. In the last few years however, new development paradigms
have emerged which promise to radically change this situation, and allow software
engineering to claim its rightful place in the family of engineering disciplines, that is the
component-based software.


1.1 Aims and Objectives

In this section the aims of the research are identified. The primary objectives of the research
are to study the current state of component technology. How to use them in the design,
implementation and maintenance of software systems? How to maximize the reuse of
existing software? In detail, the following objectives were set.

 What are the most significant benefits of using CBSE?
 What are the principal activities in the CBSE process?
 Why one may have to make requirements compromises so that components can be
reused?
 What component technologies are available from component vendors?
 What are the main criteria when designing components intended for reuse?
 How to identify components needed for particular purpose, (component search)?


1.2 Initial Review

Component-based software development (CBSD) has its roots originating in the late sixties.
Software development back then was, and still remains today, a very young discipline
contrasting its counter parts such as civil, mechanical and electrical engineering. As demand
for software increased such as usability, robustness, reliability, flexibility and adaptability,
major problems in software development were ran into: Bad software quality, very low
productivity and cost explosion.

As a result, In 1968 NATO called a conference for constant failure of system developers to
deliver software systems within budget, on time, and of satisfactory quality for use. In that
conference NATO deal with the so-called ―Software Crisis‖. A report written by Doug
McIllroy in 1969 on ―mass-produced software components‖ first introduced the idea of
―software component‖. He proposed a software industry that supplied off-the-shelf standard
software components. He predicted that developers would build software solutions from
existing software components instead of building them from scratch.

Brad Cox introduced the idea of ―software integrated circuit‖, which are pieces of software
that can be ―plugged‖ or ―unplugged‖ from a system and are as well replaceable and
reconfigurable. Just like an electrical integrated circuit, or a computer hardware component,
the software equivalent will provide a fixed function and an interface specification without
informative any of its internal implementation. Cox also mentioned the fact that these circuits
or components can be sold on the open market.

(Cox, 1986)

Nowadays, many people argue that cost minimization is one of the main factors for designing
software. For that reason reuse-based software engineering is becoming the important
development approach for business and commercial systems. CBSE emerged in the late
1990s as a reuse-based approach to software systems development. Its creation was
motivated by designer frustration that object-oriented had not led to extensive reuse, as
originally suggested. Single object-oriented were too detailed and specific and often had to be
bound with an application at compile-time. This made marketing object as reusable
components difficult. In spite of early optimistic prediction, no significant market for
individual objects has ever developed.

CBSE is the process of defining, implementing and integrating or composing loosely coupled
independent into system. It has becomes as an important software development approach


because software systems are becoming larger and more complex and customers are
demanding more dependable software that is developed more quickly and less expensive.

1.3 Method of Approach

This primary part of the research will be conducted based on a case study on the Avalon
Framework. The main focus from these case studies will be as bout following parts-

 Problem Statement
 Design Decisions
 Server Component Development
 Tests and Result
 Implementation

After implemented the component, an assessment and analysis has been presented for
successful the primary part of the research.

This Secondary part of the research has been conducted based on journals, published books
and articles and the internet.


2. Component

This chapter considers about the component‘s definition, characteristics, difference between
Components and object, differences between CBSE and Traditional SE, significant benefits
of CBSE, importance of reusability, compromises for reusability and finally shows some
importance component technologies and different component modelling languages.

2.1 Component definition

A component is an independent software unit that can be composed with other components to
create a software system. However, different people have definitions of a software
component. In 2001, Council and Heineman define a component as:

A software element that conforms to a component model and can be independently deployed
and composed without modification accordingly to a composition standard.

This definition essentially based on standard-a software unit that conform to these standards
is a component (Szyperski, 2002).

However in this definition it does not mention standards of a component but focuses instead
on the key characteristics of components:

A software component is a unit of composition with contractually specified interfaces and
explicit context dependencies only. A software component can be deployed independently and
is subject to composition by third parties.

Szyperski also states that a component has no externally observable. This means that copies
are impossible to differentiate. However, some component models, such as Enterprise Java
Beans model, allow stateful components. So these clearly do not correspond with Szyperski‘s
definition of a component. While stateless component are certainly simpler to use, but
Somerville think that CBSE should accommodate both stateless and stateful components.


2.2 Component Characteristics

Standardised Component standardisation means that a component used in a CBSE process
has to conform to some standardised component model. This model may define component
interfaces, component metadata, documentation, composition and deployment.

Independent A component should be independent- it should be possible to compose and
deploy it without having to use other specific components. In situations where the component
needs externally provided services, these should be explicitly set out in a ‗requires‘ interface
specification.

Composable Component have to be composable it means that all external interactions must
take place through publicly defined interfaces. Also, it should provide external access to
information about itself such as its methods and attributes.

Deployable A component has to be self-contained and must be able to operate as a stand-
alone entity on some component platform that implements the component model. This means
that the component is a binary component that does not have to be compiled before it is
deployed.

Documented Components have to be fully documented so that potential users of the
component can decide whether or not they meet their needs. The syntax and, ideally, the
semantics of all component interfaces have to be specified.

These formal component definitions are rather abstract. These definitions not really give us a
clear Picture of what a component does? One of the most useful ways to consider a
component is as a standalone service provider. When a system needs some service, it calls on
a component to provide that service without caring about that component is executing or the
programming language used to develop the component.

Viewing a component as service provider emphasises two critical characteristics of a reusable
component are shown below-

1. The component is an independent executable entity. Before using the component with
other component it does need to compile because source code is no available for
component.


2. All interaction of component does through interface because Components are made
through an interface. The component interface is expressed in terms of parameterised
operations and its internal state is never exposed.

Most general case components thought of as having two related interfaces

Provides interface

Defines the component services to other components.

Requires interface

Defines the services that specifies what services must be made available for the
component to execute as specified

2.3 Relation between Component and Object

There is a strong relation between object-oriented programming OOP and components.
�� _

Component models also called component standards COM/ DCOM, .NET, Enterprise Java
_

Beans EJB and CORBA Component Model (CCM) relate Component Interface to Class
��

Interface. Components adopt object principles of unification of functions and data
encapsulation. Cheessman and Daniels considerthat a component can exist in several forms
during its lifecycle:

 Component Specification: component characteristics, component function _

 Component Interface: a part of its specification, a definition of a component‘s
behaviour.
 Component Implementation: A realisation of a Component Specification.
 Installed Component: deployed instance of a Component Implementation.
 Component Object: an instance of Installed Object.


2.4 Difference between Component and Object

Component:

 Component does not define types.
 Component implementations are difficult.
 Component is stateless and is a unit of deployment.
 Components are language-independent.
 Components are standardized.
 Component is as parts of a system which can be reused, but are not necessarily well
defined with explicit interfaces.
 A component can be an amorphous part of a system, the adaptation of which may
require much effort. Such components (or rather reusable entities) are of extreme
importance, as the larger the components, the greater the productivity which can be
achieved by their reuse.
 Component standards are mostly concentrated on the interface definition, while non-
functional properties are specified (if specified at all)informally in separate
documentation.

Object:

Instantiation, identity, and encapsulation lead to the properties of objects. In addition the
Characteristic of an object are given follows:

Object has a unique identity
An object may have state and which is observable
state and behaviour of an object is encapsulated;

Moreover, There e are some properties which are directly related to object characteristics. A
number of object properties directly follow these characteristics. Because an object is a unit
of instantiation, it cannot be partially instantiated. Since an object has individual state, it also
has a unique identity that is enough to identify the object despite state changes for its entire
lifetime. As objects are instantiated, there needs to be construction plan that describes the
state space, initial state, and behaviour of a new object. Also, that plan needs to exist before
the object can come into existence. Such a plan may be explicitly available and is then called
a class. Alternatively, it may be implicitly available in the form of an object that already exist
that is, sufficiently close to the object to be created, and can be cloned. Such a pre-existing
object is called a prototype object.


Component act through objects and therefore normally consist of one or more classes. In
addition, it might contain a set of immutable objects that capture default initial state and other
component resources.

However, there is no need for a component to contain classes only, or even to contain classes
at all. Instead, a component could contain traditional procedures and even have global (static)
variables, or it may be realized in its entirety using a functional programming approach, or
using assembly language, or any other programming approach.

2.5 Differences between CBSE and Traditional SE

 CBSE views the system as a set of off-the-shelf components integrated within an
appropriate architecture.
 SE seeks to create a system from scratch.
 CBSE Life Cycle is shorter and less expensive

Fig 2.1: differences between CBSE & tradition SE (Crnkovic, 2003)

 CBSE does not have any standard development models like UML for SE.
 CBSE is young; therefore long term maintainability is largely unknown.

(Wang, 2000)

 SE can fulfill requirements more easily.
 CBSE fulfillment of requirements is based on the available components.


2.6 The most significant benefits of using CBSE

Now a day‘s software systems are becoming larger and more complex. In addition, customers
are demanding more dependable software that is developed more quickly and less expensive.
CBSE is trying to fulfil the customer demand.

The most significant benefits of using CBSE are-

 Management of Complexity
 Reduce Development Time
 Increased Productivity
 Improved Quality

(Crnkovic, 2003)

2.7 Importance of Reusability

2.7.1 Why is reuse important?

Reuse is important because it yields software economies of scale. If software organizations
wish to survive in an increasingly competitive world, then they need to acknowledge the
increasing economies of scale achieved by their competitors, and respond appropriately to it.

However nowadays reusability is the most important for industry manufacturing industry. A
component is a type, class of objects or any other work product that has been specifically
engineered to be reused. CBD appears to be the best development approach, mainly because
of its capacity for reusability and, therefore, it‘s potential for saving time and effort.
Consequently, market for CBD tools and frameworks is rising rapidly (Lefebvre, 2005).

Since reusability is the most important for industry, a brief history for reusability is illustrated
in following figure and its summary description is as follows (Bellur, 2005):

Reusability came when programmers discovered that they spent much time to reprogram
existing data-structures and class libraries. Several commercial class libraries began to appear
and the popularity of these libraries paid people‘s attention to the promise of the reuse of
software. These class libraries provided some set of related classes, which one could use
directly via composition or could specialize via inheritance to develop software. Then
frameworks were introduced providing solution to a problem via an abstract design, which
one then had to specialize and tune. The difficulty with frameworks was that they were


abstract reusable ―designs‖ which had to be embodied by expert programmers. The solution
was to combine the advantages of reusable designs with those of reusable implementations.
These are components, the state-of-the-art in software world. A component can be defined as
reusable software artefact, which is the unit of software distribution and manageability at
design and runtimes.

Fig 2.2: Reusability through development techniques (Bellur, 2005)

Some business goals are provided with the help of reusability as follows (Kozak, 2002):

 Increase productivity: After an initial investment, reuse of existing assets will enable
projects to decrease the cost of developing and maintaining software.
 Shorten time-to-market: Design time is hugely reduced because key architectural
decisions have been made and are embodied in the component model and framework
(Bachman, 2005).
 Improve software quality: Software that has been used multiple times will possess
fewer defects than freshly coded components.
 Reduce risk: It automatically reduce costs when available reusable components
already include the desired functionality and have standard interfaces to facilitate
integration, so it has less risk compare to create new software.


 Provide consistency and interoperability across products: Standard interfaces and
common use of components across products facilitate ease of use and interoperability.
For example, when several software products reuse the same user interface scheme,
terms and conventions are used consistently. Reuse also contributes to
interoperability. For example, when a component that contains an error-message
handling routine is reused by several systems, these systems can expect consistent
behaviour.
 Ensure product/system conformance with user requirements through prototyping:
Because the availability of reusable components facilitates prototyping, user
requirements may be more easily validated. This prototyping will also enable
detection and resolution of defects earlier in the software life cycle - avoiding more
costly fixes later in the life cycle.
 Leverage technical skills and knowledge: Reuse enables specialists to optimize
software architectures and assets which may then be reused by others who are
focusing on meeting product features and market needs.
 Improve functionality and/or performance: Reuse allows for the investment of time
to improve functionality and/or performance. Because this time can be amortized over
multiple uses of the assets, this investment for such improvements is more
economically justified than the case where they would only be for single product.

2.7.2 Is reuse really going to happen this time around?

CBD offers a multiple focus of reuse

 External component libraries
 In-house component infrastructure
 Mining components from legacy systems

Of these, it is the legacy mining that seems to offer the greatest chance of genuine
economies of scale.


2.7.3 How do we measure reuse?

There are at least three possible ways of defining software reuse:

 Static reuse can be defined in terms of the number of source code references to
component, or the number of software items that refer to component. Static reuse
generates application benefit, in terms of faster development and/or easier
maintenance
 Deployment reuse can be defined in terms of the number of consumers with access to
services provided directly or indirectly by component.
 Dynamic reuse can be defined in terms of the frequency of execution of component.

Business benefit comes from high levels of deployment reuse and dynamic reuse. This can
often be achieved without high levels of static reuse. However, a lot of software engineering
is focused on static reuse.

2.8 Compromises for reuse components

Over the years, software reusability has become a research area in its own right – and more
recently has emerged into what is now known as CBSE. It‘s a process that aims to design and
construct software systems using reusable software components. Early approaches to
reusability have been adhoc. There hasn‘t been any standards adopted by the industry as a
whole, and without standards, it has been difficult for developers to be motivated to design
with reusability in mind.

Increasingly, complex systems now need to be built with shorter amounts of time available.
The ―buy, don‘t build approach‖ is more important and popular than ever.

The business and organizational context within which applications are developed, deployed,
and maintained has changed. There is an increasing need to communicate with legacy
systems, as well as constantly updating current systems. This need for new functionality in
current applications requires technology that will allow easy additions.

CBSE has changed most of the part of these situations. The reason is it‘s easy to assemble as
well as cheaper to build. Although this cannot be guaranteed, the limited experience of
adopting this strategy has shown it to be true. The software systems built using CBSE are not
only simpler to assemble and cheaper but also turn out to be more robust, adaptable and
updateable.


Over the past decade, many people have attempted to improve design techniques and more
expressive notations for a software development. And also encouraging reuse of pre-
developed system pieces rather than building from scratch. Each approach has had some
notable success in improving the quality, flexibility, and maintainability of application
systems, helping many organizations develop complex, mission-critical applications deployed
on a wide range of platforms.

Despite this success, many organization still facing lots of problems for developing and
maintain a large-scale software-intensive system. Mainly, when it comes to test and update
the system. Unless carefully designed, it can be very expensive (in time as well as cost) to
add further functionality to a system effectively. Furthermore, in recent years, the
requirements, tactics, and expectations of application developers have changed significantly.
They are more aware of the need to write reusable code – even though they may not always
employ this practice.

All Though CBSE allows software systems to be more easily assembled, and less costly to
build. But this cannot be guaranteed, the limited experience of adopting this strategy has
shown it to be true.

CBSE allows use of predictable architectural patterns and standard software architecture
leading to a higher quality end result. Moreover the main benefit or advantage CBSE is,
failure of developing a reusable component is less expensive (in time as well as cost) than
developing a new system. So the organizations are compromising to use the CBSE for
avoiding the risk.


2.9 Component Technologies

There are some different technologies which are used for component development. Such as
Microsoft's Component Object Model (COM) and Sun's JavaBeans which are the more
popular component model. These component models have recently been extended to allow
for distributed execution across multiple machines in, e.g. Microsoft's COM+, .NET for the
Sun's Enterprise Java Beans (EJB) and the OMG's CORBA Component Model (CCM). The
availability of these technologies, as enabled an approach to software development that is
often referred to as component based development (CBD). CBD involves the construction
and deployment of software systems that have been assembled from components. CBD
includes activities such as the discovery, engineering, procurement of components, as well as
the re-engineering of legacy software for component assembly. Component deployment
denotes the activities that are related to the transfer of components into a run-time
environment and the configuration and customization of components without changing their
implementation.

(Emmerich, 2002)

2.9 Component Modelling Languages

For all software engineering approaches, both analysis and design phases are common. To
perform these steps successfully, they need some tools and modelling utilities; such as UML
(Kruchten) called often with ―object-orientation‖, UML has yet been inevitable for software
projects whether they are based on components or objects. There are plenty of tools for UML
such as PowerDesigner, Rational Rose, etc.

There is another new modelling language which is designed only foe developing component-
oriented systems it is known as COSE Modeling Language (COSEML). There is only one
immature tool for COSEML. It is COSECASE (Özyurt, 2003)


3. Component Frameworks

This chapter enlightens the important concepts of component framework and detail overview
of three major frameworks such .NET, EJB (Enterprise Java Beans) and CORBA (Common
Object Request Broker Architecture) Component Framework.

3.1 Component Framework Definition

A component framework is a set of rules and interfaces that regulate the interaction of
components plugged into the framework. A component framework enforces the more
important rules of interaction by encapsulating the required interaction mechanisms. The
concept is applied sometimes hierarchically, such that component frameworks are themselves
components plugging into higher-tier component frameworks. The key contribution of
component framework is partial enforcement of architectural principles. A good framework
can reduce the cost of developing an application a lot because it lets you reuse both design
and code.

Component-based development (CBD) has received much attention in the software
engineering community. Using CBD, large software systems can be assembled from
independent, reusable components. Two component frameworks that support this model are
the Java 2 Platform, Enterprise Edition (J2EE), and Microsoft .NET.

3.1.1 Java 2 Platform, Enterprise Edition (J2EE)

Developed by Sun Microsystems, the J2EE defines a standard for developing component-
based multi-tier enterprise applications. J2EE provides a set of APIs (Application Program
Interfaces) to implement availability, security, reliability, and scalability into applications
developed under this component framework. Components are mainly developed using the
Java language and deployed in containers that transparently provide services to those
components, such as lifecycle management, transaction management, access control, and
others.

There are several technologies and APIs that are a part of J2EE:

Java Server Pages (JSP) and servlets
Enterprise JavaBeans (EJB)
Java Messaging Service (JMS)
Java Database Connectivity (JDBC)
Java Transaction API (JTA)


3.1.2 Microsoft .NET

Microsoft .NET is a development environment for creating distributed enterprise
applications. The main component of .NET is the .NET Framework, which consists of two
main parts: the common language runtime (CLR) and the .NET Framework class library. The
CLR allows programs to be written in many different programming languages because it
translates them into Intermediate Language (IL). IL is the syntax used to send, receive, and
manage .NET signals. The .NET Framework class library includes ASP.NET for developing
Web applications and Web services, Windows Forms for user interface development, and
ADO.NET for connection to databases.

Other components of Microsoft .NET include

Visual Studio .NET development system
Windows Server 2003
Active Directory directory services
Windows Server system components such as SQL Server 2000 and Exchange Server
2003

Unfortunately, developing a good framework is expensive. A framework must be simple
enough to be learned, yet must provide enough features that it can be used quickly and
catches for the features that are likely to change. It must explain the theory of the problem
domain, and is always the result of domain analysis, whether explicit and formal, or hidden
and informal (Szypeski, 98). Therefore, frameworks are most likely developed only when
many applications are going to be developed within a specific problem area, allowing the
time savings of reuse to get back the time invested to develop them.

Today, there are only few component frameworks on the market, but their number is growing
fast.

There are a few technologies that are trying to capture their share of the emerging component
technology. In the following, given detail description about presents the three major
technologies and approaches followed today.


3.2 .NET Framework

The .NET Framework is an integral Windows component that supports building and running
the next generation of applications and XML Web services. It has two main components: the
Common Language Runtime (CRL) and the .NET Framework Class Library (FCL). The FCL
is built on top of the CLR and provides services needed by modern applications. While
applications targeting the .NET Framework interact directly with the FCL, the CLR serves as
the underlying engine. The CLR is the foundation of the .NET Framework.

The .NET Framework can be hosted by unmanaged components that load the common
language runtime into their processes and initiate the execution of managed code, thereby
creating a software environment that can exploit both managed and unmanaged features. The
.NET Framework not only provides several runtime hosts, but also supports the development
of third-party runtime hosts.

The following illustration shows the relationship of the common language runtime and the
class library to your applications and to the overall system. The illustration also shows how
managed code operates within a larger architecture.

(Microsoft, 2009)


This section gives an overview of Microsoft's .net technology. It specially focuses on
component related parts of .Net such as Common Language Infrastructure and Common
language Runtime

3.2.1 Common Language Infrastructure

The Common Language Infrastructure (CLI) is developed by Microsoft that describes the
executable code and runtime environment that form the core of the Microsoft .NET
Framework and the free and open source implementations Mono and Portable.NET. It is a
language neutral platform. CLI Something like CORBA. Unlike CORBA, though, CLI also
defines an intermediate language (IL) and deployment file format (assemblies), such as Java
byte code, class and JAR files. Unlike CORBA and Java, CLI include support for extensible
metadata (Thai, 2001).

CLI provides a virtual execution environment comparable to the one provided by Sun
Microsystems for Java programs. In both environments, CLI and Java use a compiler to
process language statements (also known as source code) into a preliminary form of
executable code called bytecode. Later, when a program is run, its bytecode is compiled on
the fly into the native code required by the machine architecture of a given computer. CLI is
designed to make it easier to develop programs that can be used as Web services.

Common Language Infrastructure specifies:

A common language (the Common Language Specification - CLS)
A common set of data types that any language must support (the Common Type
System - CTS)
An introduction to the component structure
How the machine state is managed
How exceptions are handled

Any programming language that conforms to CLI criteria can access a common class library
and can be compiled into a common intermediate language (bytecode). Once compiled into
the common intermediate language, any program can then be further compiled into the
machine code understood by the specific system it is running on.

Within the Common Language Infrastructure, a component called the Common Type System
(CTS) defines the programming types and operations supported by the .NET runtime engine.


A subset of CTS, the Common Language Specification (CLS) determines whether an
application is in compliance with specified criteria.

Common Language Infrastructure programs can be written in a variety of programming
languages, including ASP+, C++, and C#. These are compiled into Microsoft's Common
Intermediate Language (CIL), which the Common Language Runtime (CLR) then compiles
into machine code for processing.

3.2.2 Common Language Runtime

Common Language Runtime (CLR) lives at the core of .NET. IT is a platform for software
development that provides services by consuming metadata. CLR is standards-based and
component-oriented. Like any platform, the important pieces are the runtime, the libraries
that provide access to them, and the languages that can target the platform.

(Craig, 2004)

The CLR is a component-oriented platform. Every piece of CLR functionality that runs must
belong to a component - an assembly in CLR parlance. Further, this component-orientation is
deeply rooted in the mechanisms of the CLR, to the point where the security subsystem and
the loader (among others) have the notion of component baked in.

CLR engine is divided into modules that contain code, metadata, and resources. The code is
stored in common intermediate language (CIL) format. The module's metadata includes the
types such as names, inheritance relationships, method signatures, and dependency
information. The module's resources consist of static read-only data such as strings, bitmaps,
and other aspects of the program that are not stored as executable code.

Component development using CLR has numerous attractive benefits such as code reuse,
proper maintenance of all components by allowing independent bug fixes to each. In
addition, the CLR helps developers in managing both allocation and deallocation of memory.
This removes two of the largest sources of programmer error: leaks and memory corruption.

CLR is also helpful for security purposes. IT provides permissions to a component based on
what process it runs in, validates the code based on evidence such as information about code
at load time and the website from which component was obtained to assign permissions on a
component-by-component basis. Moreover, CLR checks the code to see if it has been
manipulated. The metadata in a CLR component can contain a digital signature that can be


used to verify that the component was written by genuine person and that it has not been
modified. You can verily identify if anyone has tried to modify with the code. For example, if
someone tries to change the code of transferring money from the intended recipient to himself
the CLR will prevent the altered code from running.

Finally, CLR is an implementation of common language infrastructure (CLI) specification,
adding COM+ interoperation and Windows platform access services. In particular, CLR
offers dynamic loading and unloading, garbage collection, context interception, metadata
refection, remoting, persistence, and other runtime services that are fully language
independent (Thai, 2001). Presently, Microsoft supports four languages on CLR - C#, J#,
Managed C++, and Visual Basic.net - that is they are the .net software components.

3.3 Enterprise JavaBeans, the Sun way

Enterprise JavaBeans (EJB) technology is the server-side component architecture for Java
Platform. This technology enables rapid and simplified development of distributed,
transactional, secure and portable applications based on Java technology. And EJB
architecture is uses for the development and deployment of robust, world class component-
based distributed application using the java language.

(SDN, 2009)

Different people have defined EJB in different way. In 2003, Hayden Marchar defines EJB as

“Enterprise JavaBeans (EJB) is an architecture for setting up program components, written
in the Java programming language, that runs in the server parts of a computer network that
uses the client/server model.”

The Enterprise JavaBeans architecture is component architecture for the development and
deployment of component-based distributed business applications. Applications written using
the Enterprise JavaBeans architecture is scalable, transactional, and multi-user secure. These
applications may be written once, and then deployed on any server platform that supports the
Enterprise JavaBeans specification.


Fig 3.1: Remote invocation in EJB (Monson-Haefel, 2001)

Enterprise JavaBeans is built on the JavaBeans technology which is used for code reuse from
GUI development to server-side, middle-tier business application development. It delivers the
speed, simplicity and reusability of JavaBeans component development, along with the added
scalability and security needed for enterprise server applications. This technology is also used
for distributing program components (which are called Beans, using the coffee metaphor) to
clients in a network. Enterprise JavaBeans offers enterprises the advantage of being able to
control change at the server rather than having to update each individual computer with a
client whenever a new program component is changed or added. EJB components have the
advantage of being reusable in multiple applications. To deploy an EJB Bean or component,
it must be part of a specific application, which is called a container.

One of the main goals of the Enterprise JavaBeans is to make complex mission-critical
issues, such as persistence, security and transactions transparent to the component developer


3.3.1 EJB Component Types

There are different types of EJB that can be applied to these different requirements:

Session EJB—A Session EJB is useful for mapping business process flow (or equivalent
application concepts). The EJB architecture contains two types of session beans - stateful and
stateless. Session EJBs commonly represent "pure" functionality and are created as needed.

(Martin, 2004)

The difference between the two is the way in which the bean handles client information. The
stateful session bean maintains client conversational state information, while the stateless
session bean does not. A stateless session bean is a bean that holds conversations that span a
single method call (Roman, 2002).

Fig 3.2: Stateless Session bean life cycle

A stateful session bean is a bean that is designed to service business processes that span
multiple method requests or transactions (Roman, 2002). Scaling is a major advantage of
stateless beans. Because stateless beans don't keep "per-client" state information, different
clients can share them at different times.

Stateful beans don't scale as well as stateless beans do, because stateful beans are assigned to
an individual client. However, the container can passivate a stateful bean to disk to reduce the
working set of objects running on the server (Roman, 2002). The container will re-activate
the bean when it's needed, providing some scaling benefits to the system

Entity EJB—An Entity EJB maps a combination of data (or equivalent application concept)
and associated functionality. Entity EJBs are usually based on an underlying data store and
will be created on the data within that store (Martin, 2004).


The idea behind entity beans is to use objects corresponding to database entities and
encapsulate access to actual database records (Roman, 2002). An entity bean can correspond
to a single row in relational table. The mapping of entity beans to and from database rows is
called persistence.

Entity beans can manage their own persistence by directly using JDBC to operate over
databases. Alternatively, they can use container-managed

Persistence driven by object-to-table mappings defined during the deployment process
(Roman, 2002).

Message-Driven EJB—A Message-driven EJB is very similar in concept to a Session EJB,
but is only activated when an asynchronous message arrives (Martin, 2004). Like entity and
session beans, md-beans reside inside an EJB container. But unlike session and entity beans,
they don't have remote or local interface or home interface. The only way to instantiate and
use an md-bean is to register it for particular message queue or topic.

Fig 3.3: RMI vs Message-driven bean

Message-driven bean is an alternative to remote method invocations (see above figure 3.3).
The idea behind md-bean is that middleman sits between the client and the server (Roman,
2002). This middleman receives messages from one or more message producers and
broadcasts those messages to one or more message consumers.


3.4 CORBA Architecture

Common Object Request Broker Architecture (CORBA) is an architecture and specification
for creating, distributing, and managing distributed program objects in a network (Hewitt,
2006). It allows applications to communicate with one another despite of the different
locations and designers through an "interface broker." CORBA is widely used in Object-
Oriented distributed systems including component-based software systems because it offers a
consistent distributed programming and run-time environment over common programming
languages, operating systems, and distributed networks (Xia, Michael).

The most important and essential concept of CORBA is the Object Request Broker (ORB)
which is the middleware that establishes the client-server relationships between components.

Figure 3.4: illustrates the architecture of remote invocation with ORB. (Özyurt, 2003)

In a network, ORB supports clients and servers on different computers. It means that a client
program can request services from a server program or object without having to understand
where the server is in a distributed network or what the interface to the server program looks
like.


3.4.1 CORBA Component Model

The specification for the CORBA Component Model (CCM) is written to address
complexities in the CORBA object model. The CCM is part of the CORBA 3.0 specification,
which is released 2001(Dave, 2001). The CCM extends the CORBA object model by
defining features and services that enable application developers to implement, manage,
configure, and deploy components that integrate commonly used CORBA services, such as
transaction, security, persistent state, and event notification services, in a standard
environment. It is a server-side component model for building and deploying CORBA
applications. It is very similar to Enterprise Java Beans (EJB) because it introduces several
new features, promises a fully compatible embedding of existing EJB solutions and aims to
maintain the original CORBA principle of being both language and platform independent.

(Siegel, 2000)

This also allows system services to be implemented by the container provider rather than the
application developer. The benefit and need for these types of containers can be observed
through the growth of Application Server software.

2.4.2 Component Object Model (COM) and Distributed COM (DCOM)

Component Object Model (COM) is a general architecture for component software. It allows
application and systems to be built from different software providers (Microsoft, 2000). It is
platform dependent, that is, Microsoft platforms Windows and Windows NT but language-
independent component based applications. Its language independency is restricted with the
number of languages that are supported by Microsoft for example Java is not there.

COM simply defines how components and their clients interact. This interaction is defined
such that the client and the component can connect without the need of any intermediate
system component. Specially, COM provides a binary standard that components and their
clients must follow to ensure dynamic interoperability. This enables on-line software update
and cross-language software reuse (Damani, 1997).

Distributed COM (DCOM) defines the distribution of COMs over a network. It is a protocol
that enables software components to communicate directly over a network in a reliable,
secure, and efficient manner.


DCOM is designed for use across multiple network transports, including Internet protocols
such as HTTP.

When a client and its component reside on different machines, DCOM simply replaces the
local inter-process communication with a network protocol. Neither the component nor its
client is aware of the network protocols lying between them.

3.4.3 CCM components

CCM describes a standard application framework for CORBA components. It is language-
independent. Though not dependent on "language independent Enterprise Java Beans (EJB)",
it is a more general form of EJB. The important part of the CCM specification is a CORBA
container for hosting EJBs. This provides the mechanics for two-way interoperability
between EJBs in Java and CCM components in any CORBA programming language.

It provides an abstraction of entities that can provide and accept services through well-
defined named interfaces called ports.

Ports are classified into facets, receptacles, event sources, and event sinks (Siegel, 2000).

Facets are the potentially multiple interfaces that a component provides to its clients.

Receptacles are the client stubs that a component uses to invoke other components.

Fig 3.5: CCM components with their many features (Dave, 2001)


Event sources are the named connection points that emit events of specified type to one or
more interested consumers, or to an event channel.

Event-sinks are the named connection points into which events of a specified type may be
pushed a supplier or an event channel.

A component can also incorporate client stubs used to invoke other (non-component)
CORBA objects - for example, the naming or trader service. Other features of the model
include:

Primary keys, which are values that instances of entity components provide to allow
client identification of the instances.
Attributes and configuration, which are named values exposed via accessory and
mutators.
Home interfaces, which provide factory functionality to create new instances.

3.4.4 Component Implementation Definition Language (CIDL)

The CCM extends the CORBA Interface Definition Language (CIDL) to support all the
above features. CIDL, like IDL, relieves developers from having to provide much of the
"plumbing" needed to include components within a container. To be exact, CIDL is a
superset of the Persistent State Definition Language (PSDL), which itself is a superset of
IDL. Since CIDL is a language to emphasize the description of components, it has many new
keywords. All of these keywords have been added to support the features introduced above


4. Case Study Based on Avalon Framework

This chapter presents a component-based case study. It explains how a component-based file-
sharing program was developed. This program is based on the Avalon framework and EJB as
component technology. The requirements and design decision are first stated and finally the
development approach discussed.

4.1 Introduction of Avalon Framework

Avalon framework is a java based open source software which consists of interfaces that
define relationships between commonly used application components and several lightweight
implementations of the generic components. Avalon‘s focus is server side programming and
easy to maintain and design of server focused projects. In this chapter, as a case study,
Apaches Avalon framework is used to design, develop, deploy and assemble a component.

This framework is used as a case study because it is free released under the terms of the
Apache Public License (APL).

For this research a file-sharing-program is implemented using Avalon framework. This
system allows its users to share files over the Internet or Intranet. It is chosen because Avalon
frame is suitable for server-side applications. This will hopefully give some perception about
component-oriented programming based on open software framework.

This research uses the connection-oriented TCP/IP and it‘s a client-server paradigm.

In the following subsection presents the requirement specification and the design decisions
that are used for make the system.

4.2 Problem Statement

Create a client-server system that allows multiple users to share files over the Internet or
Intranet. The server-side of the system should be a component which is ―pluggable‖ to
Avalon framework.

The Client

Implement simple GUI client software to interact with the server. When the client is executed
the software, it prompts the user for their user name and server's host name. The system
authenticates the user and retrieve, from the user list of her shared files.


The user will be able to issue queries and view search results or view a list of all available
files. Users will also be able to download files direct from other users to their local machine.

The Server

The server part of the system is a component hosted by Avalon framework. Users are able to
connect to a ―Well-known‖ server when they want to share files. At this stage the client have
to know the server address. It is possible to make preconfigured server address if have
dedicated server such us Napster server. If the users want to share files with other users then
they need to send files to the server. Then the server keeps all the share files together and
makes it available to the clients to make search on it.

The users are able to stay connected to the server as long as they want. When a user
disconnects from the server he/she will be removed from the combined list.

4.3 Phases of Component development

The following phases are used to develop the client-Server component

 System requirements
 Design the component
 Develop the component
 Testing

4.5 System requirements

It is needed to download some essential software to develop the component. Like

 Avalon framework- on which the component is developed
 IBM Rational- it is used to design the component
 Apache Ant- it is used to build the component


4.6 Design the component

4.6.1 Design Tools

IBM Rational Rose Software is used to design the Client-server system

4.6.2 Component design

The component design is done using IBM Rational software. Details component design is
given in Appendix

4.6.3 Design Documentation

4.6.3.1 Client Application Interface

The GUI is used as a client application for logging in and issuing query. It also shows
progress bar while downloading files. The application has a pop-up window with the server
name and user name textbox. The users have to enter the server name and user name when
they start the application for connecting with the server.

If the connection fails, for unauthorised access or invalid server address or invalid user
name, the same window will pop up again, otherwise the program starts a new larger with
menu-bar and textbox for search.

Though, the primary design goal of the system is to verify reusability, performance and
robustness of component-based system. Therefore, the GUI design is intentionally kept
simple.

4.6.3.2 Functional Design

The server is multi-threaded. For this reason multiple clients can make search at the same
time through the server where all clients are connected to. The server is a Java application
that can be run under any JVM-compliant platform. Users using different platforms are able
to share files, as long as they are connected to the internet (or the same intranet). Two client
applications are able to run from the same physical machine. The shared files can be any sort
of media such as text, sound or graphic with any size.


4.6.3.3 Download Files

Once a client receives a query result from the server, user can initiate to download one of the
files in the query result. Files are downloaded out-of-network i.e. a direct connection between
the source and target client is established in order to perform the data transfer. File data are
never transfer over the server.

4.7 Component Development

Building Avalon-compliant component (or a component in general), the following is a typical
order of operation.

4.7.1 Develop the component

4.7.1.1Coding the Component

Coding the component is obviously main task compare to code normal java files. It needs to
follow all syntax for coding a standard Avalon component. For this case study, initially two
interface files like, FileSharingServer and FileSharingServerMBean were created to declare
what this component is offering to the host system. After that FileSharingSeverImpl class
which extends AbstractLogEnabled was created. It is a logging class in Avalon framework.
The class also implements the two interfaces and some of Avalon's interfaces which the
component needs. These interfaces are Serviceable, Configurable, Initializiable, Disposable
and ConnectionHandlerFactory. The FileSharingServerImpl class makes the component
Avalon-compliant. After that, FileSharingHandler, Search and Item have been created to do
the business purpose:

FileSharingHandler handles all incoming connections from client, such as in login, out login
and enquiries.

Search is responsible for searching files. The search algorithm is kept simple. It uses Vector
for keeping the all file names.

Item defines the file format as well as the incoming and outgoing package format.

After that all the classes have build, package, deploy and run the component in a framework.
After running it, all the errors have been fixed. This is one of the difficulties of developing
component, because every time I needed to go back to fix the error.


4.7.1.2 Assemble

a) Writing config.xml, assembly.xml and environment.xml

In Avalon, each component must contain the following three files:

config.xml: It provides configuration data to each of the components that require
configuration data.

assembly.xml: It defines how the Server Application is assembled from its components. This
requires naming each component, specifying the implementation class for each component
and wiring together components.

environment.xml: It configures environmental or Server Application wide settings. This
means being able to set the security policy and configure logging settings. This file is written
in XML and the end-user can view what sort of security policy the component requires. The
end-user (assembler) can alter the permissions in the security policy if so is desired.

b) Build Tool

Apache Ant (Another Neat Tool) software tool is uses for building the component. It is open
source software, and is released under the Apache Software License. Ant is designed to be as
cross platform as Java. Ant uses Java classes and XML scripts to provide an automated way
to build applications and to be available on every Java compatible platform. (Paul)

Apache Ant is uses to packing the component into JAR and SAR archives. The SAR (Server
Archive) file format is the standard distribution format of Server Applications. It is a standard
Jar file with a specific directory layout. The config.xml, environment.xml and assembly.xml
file must be stored in SAR-INF/ directory of the archive. All jar files, including both those
that contain components and those that contain support classes are stored in the SAR-INF/lib/
directory. Avalon has a template Ant build.xml file. This template is used to create the final
build.xml file for component.


4.7.1.3 Deploy

Currently deploying a server application under Avalon is simply a matter of dropping the .sar
file into the directory phoenix/apps/, where the framework looks to load the .sar file, and
starting the server. After restarted the Avalon it confirmed that the component was loaded.
Now the server component is up and running. Then a simple client is created to test the
server. Please refer to the Appendix for client design.

4. Start or restart the framework phoenix/bin/run.[bat|sh]

5. Create optional standalone test client.

4.8 Tests and Result

Software testing is a fundamental component of software quality assurance and represents a
review of specification, design and coding. Testing could find out the bugs and logical errors
of the system. It is best if someone outside the development group carries out the tests. The
objectives of Testing are as follows:-

• Testing is a process of executing a program with the aim of finding errors.

• A good test case will have a good chance of finding an undiscovered error.

• A successful test case uncovers a new error.

4.8.1 Testing Types

There are two types of testing:

1. Functional or Black Box Testing,
2. Structural or White Box Testing.

White Box Testing

White Box testing concerned with checking of system representations such as the design
diagrams and source code.

Using white box testing methods, we can derive test cases that:

1) Guarantee that all independent paths within a module have been exercised at least once,


2) Exercise all logical decisions on their true and false sides,

3) Execute all loops at their boundaries and within their operational bounds, and

4) Exercise internal data structures to ensure their validity.

Black Box Testing

Black box testing approaches concentrate on the fundamental requirements of the software.
Black box testing allows producing groups of input situations that will fully exercise all
functional requirements for a program.

Black box testing tries to find errors in the following categories:

 Incorrect or missing functions
 Interface errors
 Performance errors
 Initialisation and termination errors

To satisfy the objectives, both white box and black box testing are used. The design diagrams
and source code have been tested as white box testing. Please refer to Appendix A for design
diagrams.

Black box test is done to find out the unexpected system outputs or behaviour. Then during
the implementation phase testing has been carried out. The errors were encountered during
the implementation have been located and repaired. After completion of the implementation,
two tests were particularly interesting:

To see that the server component hasn‘t created any problem after it is been deployed
to a system.
To test that the communication between server and clients works correctly. Such as
queries and file transfers.

For the security purpose, two ports scanning were accepted one is before the server was
started and second one while the server was in operation. Then the two results were compared
to see if the server system opened any new ports to the outside world in the later scanning.
Avalon is an open source and any one can easily download the source code and see what
these ports are for.


5. Discussion and Evaluation

This chapter evaluates the component-based software and the thesis as whole. It starts with
comparison among the three major component architectures presented early in this thesis,
CORBA, EJB and COM/DCOM. This chapter also presents the similarities and difference,
and among these three technologies. After that Case study assessment has presented. Finally,
presents a brief discussion about component-based software development and the possible
advantages and disadvantages of adapting to this approach.

5.1 Architectures’ Comparison

The architectural comparison based on component-based approach, and also their strengths
on specific features are illustrated in the following table. This comparison is based on
environment, interface, maintenance etc. among the three major component architectures.

CORBA EJB COM/DCOM
Development underdeveloped emerging Supported by a wide range
environment of strong development
environments
Binary Not binary standard Based on COM; A binary standard for
Interfacing java specific component interaction is
Standard the heart of COM
Compatibility Particularly strong in Portable by java Not having any concept of
and portability standardizing language language specification; source-level standard of
bindings; but no so but not very compatible standard language binding.
portable
Modification & CORBA IDL for defining Not involving IDL files, Microsoft IDL for defining
maintenance component interfaces, defining interfaces component interfaces,
need extra modification & between component & need extra modification &
maintenance container. Easier maintenance
modification &
maintenance.
Service A full set of standardized Neither standardized nor Recently supplemented by
provided service ; lack of implemented a number of key services
implementations
Platform Platform independent Platform independent Platform dependent
dependency
Language Language independent Language dependent Language independent
dependency
implementation Strongest for traditional Strongest on general Strongest on the traditional
enterprise computing Web clients desktop applications


5.3 Similarities

It is clear that all component technologies have the share characteristics which cannot help to
make decisions as to which approach to follow. However, the rich sharing of characteristics
move the decision in favour of using component software technology in the first place,
whatever the concrete approach is. All approaches rely on dynamic polymorphism (some
books call inclusion polymorphism or sub typing), encapsulation and late binding
mechanisms. In addition, all approaches support interface inheritance. Also all technologies
used as on some sort of object model.

Most approaches support:

 A specialized component model for application servers - EJB, COM+,CCM;
 Uniform data transfer, JAR files, CLI assemblies;
 Some form of persistence or serialization. Deployment descriptors or attribute-based
programming.


5.4 Assessment of the major component technologies

This section assesses the different component technologies with respect to the different areas
as listed below.

 Programming languages

CORBA supports multiple programming languages and used on heterogeneous platforms and
operating systems there is an ORB implementation for the platform and a language mapping
for the programming language. DCOM also supports multiple programming languages since
it is a binary standard. But EJB is language dependent on java and JVM specific.

 Development support or process

CCM provides 4 step component development process i.e. design, develop, assemble and
deploy which provides flexibility over 3-steps (design, develop and deploy) component
development process defined by EJB.

Integrated Development Environments (IDE) for CORBA is quite poor compared to the
Microsoft development tools.

 Interface definition

Both CORBA and DCOM offer an interface definition language (IDL) to describe the
interfaces for their respective component. For both cases, the IDL is language neutral and is
used to define mappings between different programming languages. It is however some
differences in both syntax and semantics between the interfaces notions. Whereas EJB is not
involves with IDL files. It defining interfaces between component & container which is easy
to modification & maintain. .The Microsoft Interface Definition Language (MIDL) is not like
the CORBA Interface Definition Language. DCOM support multiple interfaces for a
component, each representing a different view or behaviour of the component. CORBA 3.0
specification supports this concept where as CORBA 2.0 specification doesn‘t.


 Garbage collection

Both Java and DCOM relies totally on garbage collection, Java also defines distributed object
model and supports distributed garbage collection. CORBA does not attempt to perform
general purpose garbage collection (zypeski, 2002). CLR performs garbage collection and
lease-based invalidation of remote references. A COM server object keeps track of the clients
by using reference counting. Java objects have a built-in reference counting where a separate
process within the JVM, the garbage collector releases instances when no other object has
references to the object. The DCOM method for garbage collection has been criticised due to
increased network traffic.

 Hardware support

DCOM is mainly supported on the Windows platform, but it has been attempts to provide
COM on other hardware platforms without being very successful (for instance SOLARIS);
CORBA and Java/RMI are supported on nearly all hardware platforms.

The main advantage with Java middleware is that the same version of an application can with
few changes run on any platform with a compatible JVM.

 Security

CORBA has defined an own security service to handle authentication of clients. It provides
security in two levels where level 1 comprises user authentication, authorisation, data
encryption and integrity. Level 2 provides a stronger security model where applications are
security aware. Java/RMI uses the built-in Java security mechanisms

The security model of DCOM is based mainly on the NT LAN Manager security. This causes
complications for the security of DCOM components if other security protocols or LAN‘s
like for instance Novell NetWare are used. DCOM expects the user to be authenticated and
authorised as a user in the Windows NT domain to control access to the components. If
Novell NetWare takes care of user authentication and authorisation on the client side and the
user is not defined as a Windows NT user, this causes authorisation problems on the DCOM
server. It is however possible to avoid these problems by not using the built-in DCOM server
security, with the possible consequences this may have on malicious use. Another problem
with the Windows NT security is scalability and the missing support of delegation. Windows
2000 has implemented the Kerberos security model, which is more scalable, and supports


delegation and mutual authentication between the server and the client. The EJB architecture
encourages the Bean Provider to implement the enterprise bean class without hard-coding the
security policies and mechanisms into the business methods. In most cases, the enterprise
bean's business method should not contain any security-related logic.

 Component Models

At present, it is true that there are only two competing component models, Microsoft and the
others. While EJB and CCM are fully object-oriented, COM+/MTS is component based.
They all provides services like transactions, security, concurrency and multithreading.
Scalability is well supported by all models through application server products.

Both EJB and CCM provide XML descriptors to label components with packaging and
deployment information. Also CCM provides assembly descriptors to show how CORBA
components should be interconnected. Windows NT uses Registry information and type
libraries to deploy DCOM components. For DCOM installation in Windows 2000
deployment scripts are automatically created for the specific server. These deployment scripts
can either be installed manually, or be downloaded.

Most of the application servers products support of all three component models, even if the
core architecture often is build on top of CORBA architecture. DCOM components are
normally extended with a CORBA bridge when installed on an application server.

Object identity and the life cycle are the biggest difference among the component model.
COM normally does not implicitly handle state together with the object identity. After the
COM objet creation the state must be loaded separately. The lifetime of a COM object is
bounded to the lifetime of its clients and ultimately by the lifetime of the process in which it
exist (Rosen, 98). A COM object may over its lifetime load and store several distinct,
identifiable states, and be used by several clients. Client programs are usually responsible for
explicitly managing states and its associations with COM objects. Client programs to CCM
(CORBA) and EJB objects do not have any notion of state with a separate identity, apart
from the object that encapsulates it.


5.2 Case Study Assessment

In chapter four, a file-sharing case study is developed using Avalon framework which serves
as a prototype that illustrates various component-oriented concepts and technologies.
Following presents discussion about the implementation.

5.2.1 Assessment of Avalon Framework

Avalon framework is a java based open source software which consists of interfaces that
define relationships between commonly used application components and several lightweight
implementations of the generic components. Avalon‘s focus is server side programming and
easing the maintainability and design of server focused projects.

Currently Avalon is a parent of five sub-projects: Framework, Excalibur, LogKit, Phoenix,
and Cornerstone. Avalon began as the Java Apache Server Framework that had the
framework, utilities, components, and a server's kernel implementation all in one project.

(AAP, 2004)

Avalon provides some useful components and utilities that are included into the client-server
system. After analysis of Avalon framework, the component and Services are implemented to
that make the file sharing system.

Utilities in Avalon framework is divided into seven main categories: Configuration, Context,
Activity, Service, Logger, Parameters, Thread, and Miscellany. It is common for a
component to implement several interfaces of these utilities to identify all the concern areas
that the component is worried about.

Following steps are required for the process of implementing and using a server component
based on Avalon framework.

Coding the Component It is the main task that takes the most of the time. The component
must follow all the syntax of writing a standard java classes and a standard Avalon
component design such as separation of concern and inversion of control

Associate Metadata with the Component Avalon components have associated metadata that
declares what resources they are capable of providing to other the components and what
resources they need to be provided by other the components or the host framework. The
Avalon metadata specification is an extensible mechanism to attach metadata to components.


Package the component and related resources into a SAR file The final step is packaging up
the implementation files, Meta descriptors and other resources into a .sar file.

To implement the client-server case study, some interfaces are used from in the main class
(FileSharingServer) which taken from the Avalon. Those interfaces are given below-

public class FileSharingServerImpl
extends AbstractLogEnabled
implements Contextualizable, Serviceable, Configurable,
Initializable, Disposable,
ConnectionHandlerFactory
{ ..

The system is kept as secure as possible and explicitly tracks whether the component is fully
initialized or not. Since specific information about the environment may change, or may need
to be customized. Configurable interface is also implemented for the system. The component
makes use of other components, and the method that Avalon provides to get instances of the
required component is by using a ServiceManager. The system needed to implement the
Serviceable interface to get an instance of the ServiceManager.

After implementing these interfaces and other support classes system needed to write the
configuration files. Avalon has configuration files, and they allow an administrator to alter
vital configuration information. Avalon can read a configuration file in XML format, and
build the components in a system from it.

Source modules

The file-sharing server comprises of the following main modules, all contained within the src/
directory:

 FileSharingServer Contains the Java source for server component.
 Conf/assembly.xml contains the assembly instructions for the resulting server archive
(SAR) file.
 Conf/config.xml contains the configuration for the resulting server archive (SAR)
file.
 Conf/environment.xml Contains instructions about the environment and logging.


Component Deployment

Currently deploying a server application under Avalon is simply a matter of dropping the .sar
(Server ARchive) file into the appropriate directory (apps/). Avalon supports hot deployment;
applications can be added, removed and updated in the application directory without
restarting the framework.

5.3 Assessment of the Approach

Component-based framework requires both component systems that support the approach and
component developers that follow its core principles and its discipline. Nevertheless, it is
hard to tell the difference between a true core principle and a mere feature of a component
framework.

There is a single common key feature of component technology that seems to cause most
technical difficulties: Components come from separate sources and are deployed by third
parties. Even if a component fails to function, it must not violate system-wide rules. For that
reason, component safety and language independency are important core principles.

The following subsection presents the discussion about the important core principles
component technologies and compare how Avalon framework put them into practice.

5.3.1 Component Security

In component-based programming, components are developed independently from the client
applications that will use them. Component developers have no knowledge of how end user
or client application will try to use their work. The component could have been used
maliciously to corrupt data or to hack to a system without proper authentication or
authorization. Similarly, a client application has no knowledge of how the component it is
interacting with is internally implemented. It could well be a malicious component that
abuses the credentials the client provides. In addition, even if both the component and the
client have no bad intent, the end user could still try to hack into the host system or do some
other damage (even by accident). To minimize the danger, a component framework needs to
provide a security infrastructure to deal with such scenarios.


Avalon Framework Security

Security in Avalon framework is mainly based on Java security model. Avalon's Guardian
Component is used to manage permissions based on properties of the code and who is
running the code. The Guardian loads its permission sets from a database or configuration
file. It uses the standard Java security model to enforce access to the resources which a
specific component may request.

The Guardian component uses a security policy to decide which individual access
permissions are granted to running code. These permissions are based on the code's
characteristics, such as where it is coming from, who is running it, whether the code is
digitally signed, and if so by whom. Attempts to access protected resources raise security
checks that compare the needed permissions for the attempted access with the granted
permissions. If a security policy is not explicitly given, the default policy is used which is the
classic ―sandbox‖ policy as implemented in JDK 1.0 and JDK 1.1.

The sandbox is customizable Java security model which allows each restricted piece of
software to run within its own restricted ―sandbox‖. The program must ―play ―only inside its
sandbox. It can do anything within the boundaries of its sandbox, but it cannot take any
action outside these boundaries.

Java security model is one of the language's key architectural features which make it a proper
technology for networked environments.

5.3.2 Language Independence

In CBSE the client interacts with the server independently so the client is developed
independently of the server. It interacts with the server component only at runtime.
Consequently the programming languages that implement the client and server components
should not affect their ability to interact with each other at runtime. Language independence
means exactly that programming language should be irrelevant to develop a component.
Programming language independence promotes the interaction of components and their
adoption and reuse in general.


Avalon programming language

Avalon framework is basically Java Apache Server Framework. It has the own framework,
components, utilities, and a server's kernel implementation all in one project. It is the basis
for all Java server code at Apache. Since then Java is the only programming language used in
Avalon framework.

Java is platform independent and is widespread programming language. So might be this is
the main reason why Avalon architects preferred and targeted Java as the Avalon
programming language.

5.4 Component designing methods for Reuse

The main purpose of designing component methods for reuse is to increase higher
productivity, taking advantage of best-in-class solutions and the consequent improved quality
of the component. In reality, to achieve significant levels of reuse component is not so easy.
It must be carefully analyzed, designed before developed.

CBSE follows two kinds of methods for designing reusable components. These are given
below-

Designing with reuse It‘s a new designing solution by combining existing reusable
components. Search and retrieval are the main activities here. For example, copying source
code from the existing is the lowest level of software reuse. Function libraries are better form
of reuse than copying source code, but it is not extensible. Class libraries are improved form
of reuse, and they are extensible. Nevertheless, it requires deep knowledge before classes can
be reused. The client code will be affected if internals of classes changed. For example, in an
object-oriented language such as Java or C++, extended classes are coupled to the parent
class implementation. Changes in any of the parent classes in the hierarchy of the inheritance
would break extended classes (Wang, 2005).

Reusing component supports highest level of software reuse because it allows various types
of reuse including black-box reuse and white-box reuse. White-box reuse means that the
source code of a component is made available and can be studied, modified, adapted and
reused. Black-box reuse is the highest level and it is based on the principles of information
hiding. The component interface defines the services client software may request from the
component (Wang, 2005). The client software has no knowledge about the component


An Analysis of Component-based Software Development -Maximize the reuse of existing software

An Analysis of Component-based Software Development -Maximize the reuse of existing software

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (18)

Similar to An Analysis of Component-based Software Development -Maximize the reuse of existing software

Similar to An Analysis of Component-based Software Development -Maximize the reuse of existing software (20)

Recently uploaded

Recently uploaded (20)

An Analysis of Component-based Software Development -Maximize the reuse of existing software