Method Engineering: A Service-Oriented Approach - Intentional Perspectives on Information Systems Engineering - page 331

Ta b l e 1 Moving from components to services

Criteria CBSE SOE

Finality Software reuse by components

integration

Software interoperability by services
invocation

Interface orientation Product-oriented interface Client-oriented interface

Lifecycle Deployment/Research Publication/Discovery

Organization Assembly and organization

with static links

Static and dynamic composition

way of designing software systems to provide services to either end-user applica-
tions or to other services distributed over a network, via published and discoverable
interfaces [ 19, 20] . Table 1 provides a summary of major differences between the
component-oriented view and the service-oriented one.
CBSE and SOE introduce different points of view about software engineering:
CBSE focuses on software reuse and components integration while SOE focuses on
software interoperability and services invocation. SOE emphasizes aspects such as
autonomy, communication, etc.
Both approaches introduce the notion of interface. However, CBSE and SOE
don't consider this notion in the same way: usually, in software components, inter-
face is a set of inputs and outputs while, in services, interface usually is a functional
description of what the service can do. Components' interface is a specification
of components' behavior that consists of names of semantically-related operations,
their parameters and valid parameter types. So interface specification focuses on the
product that the component delivers. Components' modeling emphasizes engineer-
ing information about components, i.e. information required for implementation,
configuration and deployment. For instance, information about communication and
data exchange among components is rather relevant for supporting implementation
of components. Components access is available when components are deployed,
i.e. installed and configured, in a component infrastructure. The interface of ser-
vices specifies the need a consumer may request from the service. Additionally, an
interface may include constraints on the usage of the service that must be consid-
ered by both the service and its consumer. Models of services emphasize usage
concern, which is what the service is intended to do for a particular consumer.
Service providers publish services and make them available (often on the web).
Nevertheless, let's note that some advanced components models introduce high-
level description of the components [ 25, 39] while some models of services only
consider low-level data [ 40] .
Components and services lifecycles can't be considered in the same way: once
produced, components must be deployed by their customers who then have the
ability to research in their own components library the one or ones they need; on
the contrary, once produced, services are published by their providers. Then, con-
sumers have the ability to discover (dynamically) available services relevant to their
requirements. So, usage of components and services is very different; we make use