In this paper, we discuss the theoretical di erences between component-based and service-oriented software engineering (CBSE and SOSE). We present a conceptual comparison framework which confronts their quantitative and qualitative aspects and provides a better understanding of their use. This comparison takes the object orientation (OO) into account to illustrate changing concerns of software engineering between object, component and service.
Component-based software engineering (CBSE) [
All comparison works between CBSE and SOSE have a bottom-up approach
in which they focus on speci c technologies to identify the resulted software
qualities [5{7] (e.g. comparison of performance between technologies [
In this paper, we propose a conceptual comparison framework which can deduce the resulted software qualities. It is divided into quantitative and qualitative aspects. It takes object orientation (OO) into account to provide a global point of view about the evolution of concerns between object, component and service.
The top-level categories of our quantitative part are the product and the process. It does not intend to be exhaustive, but it aims at listing the core concepts of each paradigm to underline their theoretical stance. 2.1
A product is a software entity or a conceptual entity which is the result of an action or a process. A process is an action or a succession of actions which is used to create or modify a product and obtain a speci c one.
The product category is divided into two sub categories (Figure 1): { Basic architectural element - basic building blocks of each paradigm; { Composite architectural element - complex products built from existing architectural elements. Their structure clearly identi es the reused architectural elements and their relationships.
Each sub categories is also divided into two groups according to two abstraction levels: the design-time and the runtime (Figure 1).
The process category focuses on the reusability principle shared by OO, CBSE and SOSE, i.e how to reuse existing software entities, the constituent, to build new ones, the composite. A constituent is a basic or a composite architectural element. These notions of constituent and composite de ne two description levels (Figure 1). The process category is divided into three sub categories according to abstraction and description levels.
{ Inside description level - gathers processes which target products from the same description level (Figure 1 white arrows) at the two abstraction levels; { Between description levels - gathers processes which target a product from a di erent description level than the produced one (Figure 1 hatched arrows). This category is divided into design-time and runtime; { Between abstraction levels - gathers processes which target a product from the design-time and then produce a product of the runtime (Figure 1 black arrows). 2.2
We want to emphasize two main di erences illustrated by the Table 1. First, SOSE relies on the dynamic service provisioning (discovery and selection) between abstraction levels to produce a concrete service from an abstract service. On the contrary, OO and CBSE rely on the instantiation process between class and object, and component type and component. Then, SOSE relies on additional runtime processes to support the self-adaptation of composite elements. Even if some similar processes are proposed by CBSE, they are not required to specify a component model. 3
Existing works about software quality [
We identify six main features:
Loose coupling - measures the dependencies between entities.
Expressiveness - based on the number of concepts and processes provided by the paradigm to specify and manipulate its products.
Abstraction of communication - ability of a paradigm to abstract the communication layer which drives the execution of the application.
Explicit architecture - ability of a paradigm to provide a clear architectural view of the application which follows its principles.
Evolutionary ability - ability of a paradigm to provide a powerful set of concepts and processes to evolve its products.
Ownership - allocation of responsibilities (development, QoS, maintenance, deployment, execution, management, use) among the provider of the reused products and its clients. It expresses the level of liberty granted by the provider to the client.
Loose coupling - typically, an Object-based system is built from a set of
classes which are tightly coupled while a Component-based or a Service-based
system intends to be more loosely coupled. In fact, related topics such as the
selfadaptation or the management of heterogeneities are deeply studied by CBSE
and SOSE. We set that existing researches reach the same level of maturity.
However, our previous work [
Expressiveness - OO manipulates a huge number of concepts such as granularity, re exion, template, inheritance, abstraction level, description level and so forth. CBSE's expressiveness mainly relies on OO's researches. However, some advanced concepts such as re exion or inheritance and polymorphism do not reach the same level of maturity. SOSE has the weaker expressiveness of the three. In fact, it shares the lack of CBSE and adds some others (e.g. the abstraction levels and the distinction between type and instance are still unclear).
Abstraction of communication - SOSE provides the best abstraction of communication. In fact, the global collaboration pattern between constituent services is located inside a single entity: the composition schema which expresses the overall behavior in terms of work ows and data ows. In CBSE, the communications are located inside the connectors which split the global behavior. The work ow is not explicit. Therefore, the overall collaboration is harder to understand and manipulate. In OO, the ne granularity of the class and the association link accentuates this drawback of CBSE.
Explicit architecture - typically, an Object-based system lacks an explicit architecture which is easily understandable. CBSE was rst introduced to enhance this aspect and develop the concept of software architecture. SOSE directly uses this experience and its di erence with CBSE is not signi cant.
Evolutionary ability - dependent on the architectural graph and the
evolution processes which target its nodes, edges, or the overall graph. Typically,
OO does not provide an explicit architecture and thus, its community only
focuses on the evolution of the nodes and edges. Both CBSE and SOSE handle an
explicit architecture. Their communities also study the evolution of the overall
graph. However, some works of the CBSE community such as [
Ownership - SOSE has taken the concept of ownership to the extreme and thus, the provider of services is responsible for the development, the quality of service, the maintenance, the deployment, the execution, the management. On the contrary, CBSE splits the responsibilities at the deployment level. In fact, the client is responsible for the instantiation of the component inside his application and its execution and management. Typically, the object orientation de nes the class as a glass box entity and provides some powerful processes to easily manipulate it. 3.3
Our six features represent the main elements of a software development paradigm which impact on the software quality. However, the importance of their impact can vary according to the chosen quality and the user's point of view about this quality. In the gure 3, we act as users and de ne three quality criteria: reusability, composability and dynamicity. We express our understanding about these qualities and divide the features into three groups, from the group which has the weaker impact to the group which has the stronger impact.
Then, we de ne a set of formula (e.g. for the reusability(1)) which combine our vision of these qualities dropped to our six features and the previous classi cation of the three paradigms following these features (Figure 2). Each level (low, medium and high, Figure 3) is associated with a weight (respectively 1, 2 and 3).
Reusability =Object : (4) + (3) + (1)
Component : (5) + (6) + (2)
Service : (3) + (7) + (3) (1)
From our qualitative perspective, CBSE has a better reusability than SOSE or OO. The same work can be done for other quality criteria ( exibility, robustness and so forth). The de nition of the impacts of each feature on each quality depends on the user's expertise. In fact, each quality represents a particular perspective on our six features and this perspective has to be de ned by the user. The following formula Quality = f ( ; ; ; ; ; ) emphasizes the user role which has to provide: { the di erent coe cients ( to ) which de ne the respective importance of each feature according to the chosen quality perspective; { the function f which de nes the way to combine these features. 4
This paper presents a conceptual comparison between CBSE and SOSE divided into quantitative aspects and qualitative aspects. The quantitative aspects classify products and processes which are used to develop some new applications. The qualitative aspects compare the three paradigms following six features which are reused to speci ed any software quality such as reusability, composability and dynamicity. We show how a user can exploit these features and combine them to evaluate some quality criteria according to their own expertise.
For now, measures of each feature presented in Figure 3 only confront the
three paradigms at a conceptual level to provide a hierarchy between them. This
hierarchy is based on our own expertise. This approach is su cient for a direct
comparison between theories at a paradigm level, however it is not precise enough
to descend to implementation and technological level. In [