|
Component and Service
orientation
Definitions, comparison and ways to combine these two approaches March 2004 |
 |
|
Component and Service
orientation
Definitions, comparison and ways to combine these two approaches March 2004 |
|
|
The following discussion is based on the paper by H. Cervantes and R. S. Hall entitled "Autonomous Adaptation to Dynamic Availability Using a Service-Oriented Component Model," which was accepted at the International Conference on Software Engineering 2004. Component orientationComponent orientation promotes the construction of applications as compositions of reusable building blocks called components. Although there is no universal agreement on the definition for this term, the definition formulated by Szyperski [Szyperski1998] is widely referenced in literature: “A software component is a binary 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.” Component orientation makes a
distinction between component developers and assemblers, which are the
third parties referenced in the definition above. Since component
developers and assemblers may reside in different companies, it is
necessary to deliver components as binary units to avoid source code
release. A fundamental assumption of this approach is that the
construction of an application is based on components that are
physically available to the assemblers when composing (i.e.,
assembling) the application.  Figure 1. A component In the majority of industrial
component models, such as EJB [Sun2001],
CCM [OMG1999], and COM [Box1998], components are similar to
object-oriented classes in the sense that they can be instantiated and
that their instances can be stateful. A composition is created by an
actor that instantiates some component instances, usually from a
component factory, and then customizes and connects these instances to
each other in some appropriate fashion.
To support composition, a
component must provide information that describes the external
structure of its instances, such as provided and required functional
interfaces, and configuration properties (see figure 1). The
description of the external structure, or external view, is used by the
application assembler to connect and customize the various component
instances that form a composition. Composition is performed using
either a standard programming language or a specialized one.
Hierarchical composition is achieved when the external view of a
component is itself implemented by a composition. Figure 2 represents a
component composition as a series of component instances that are
connected to each other and whose configuration properties are set; in
the composition, component instances are seen from their external view
only as implementation details are irrelevant  Figure 2. A component composition Components are delivered and deployed independently in package as binary code along with their required resources, such as images and libraries. When installed, a component may require some deployment dependencies to be fulfilled before it can be instantiated. Finally, component instances
require an execution environment that provides run-time support,
normally through what is known as a container [Conan2001].
Run-time support includes life-cycle management and handling of
non-functional characteristics such as remote communication, security,
persistence, and transactions. The container usually interacts with a
component instance through control interfaces following the inversion
of control pattern [Fowler2004]
(see figure 3).  Figure 3. A component instance inside a container Service OrientationService orientation shares the
component-oriented idea that applications are assembled from reusable
building blocks, but in this case the building blocks are services. A
service is functionality that is contractually defined in a service description, which contains
some combination of syntactic, semantic, and behavioral information. In
service orientation, application assembly is based only on service
descriptions; the actual service providers are located and integrated
into the application later, usually prior to or during execution. As a
result, service orientation focuses on “how services are described and organized
in a way that supports the dynamic discovery of appropriate services at
run time.” [Burbeck2000].  Figure 4. Service-oriented interaction pattern To support dynamic discovery,
service orientation is based on an interaction pattern between three
different actors; these actors are service providers, service
requesters, and one or more service registries (see figure 4). Service
providers publish their service descriptions into a service registry so
that clients can locate them. Service requesters interrogate the
service registry to find service providers for a particular service
description. If suitable service providers are present in the service
registry at the moment the request is made, the registry returns a
reference to one or more service providers so that the service
requester can select and bind to any of them. When the service
requester binds to the service provider, the provider returns a
reference to a service object that implements the service functionality. Service orientation promotes the
idea that a service requester is not tied to a particular provider;
instead, service providers are substitutable as long as they comply
with the contract imposed by the service description. Another
fundamental characteristic of service orientation is that services
exhibit dynamic availability,
since they can be added or removed from the service registry at any
time. Consequently, running applications must be capable of releasing
departing services or of incorporating newly arriving services.  Figure 5. Flow-based service composition Since a service-oriented
application is built by composing service descriptions, it is an
abstract composition that only becomes concrete at run time. Service
composition can be realized through standard programming languages,
although a flow-based approach (e.g., processes) is favored in the
domain of web services [Curbera2001].
Figure 5 depicts a flow-based service composition; service invokations
are based on service descriptions and data and control and data flow
are managed by a coordinator. Hierarchical service composition is
achieved when a service composition itself implements a service
description. Finally, some service platforms provide notification
mechanisms used to inform service requesters of the arrival or
departure of the services, others use the concept of a service lease,
which means that service availability is guaranteed only for a
determined time period after which the lease must be renewed. A service-oriented platform
provides an infrastructure that enables applications to be built
following service-orientation principles. Examples of such platforms
include the CORBA Trader [Stratton1998],
Jini [Arnold1999], OSGi [OSGi2003] and more recently web
services [Curbera2001]. Comparing component and service orientationThe two previous sections present
two different approaches for constructing applications from reusable
building blocks. These two approaches promote reuse by creating a
separation between building block development and application assembly. Two fundamental differences
exist, however, between these two approaches. The first one concerns
the fact that in component orientation, applications are assembled from
building blocks that are integrated at the moment of assembly, while in
service orientation integration occurs prior to or during execution,
since only service descriptions are available during assembly. As a
consequence of this, service orientation places a stronger emphasis on
service description and the separation between description and
implementation; this enables better support for run-time discovery and
substitution. Run-time component discovery and substitution are not
primary concerns in component orientation, so a separation between the
component's external view and its implementation is less strictly
enforced. The second difference is that in
service orientation building blocks exhibit dynamic availability, since
services can be registered or unregistered from the service registry at
any time. This is not the case for component orientation, where the
hypothesis that components may arrive or depart during execution is
typically not supported. This results in the fact that service
composition has a more dynamic nature than component composition.
Dynamism in service composition includes explicit support for
incorporating new services that become available during execution or
releasing departing services that are unregistered from the service
registry. Of course, a certain degree of dynamism is possible in
component orientation, but this is not explicitly supported and must be
done programmatically. Another difference concerns the
fact that in component orientation, the separation between component
and instance is explicit. This separation requires that component
instances are explicitly created. In service orientation, service
object creation is implicit and not even considered by service
requesters. Finally, packaging is an
important activity in component orientation, since it is required that
a component, along with its required resources, is independently
deliverable and deployable. Service orientation does not consider
delivery and deployment aspects since it is supposed that these
activities occur prior to service registration and lookup. Combining components and servicesComponent and service orientation are two non-exclusive approaches that can be combined. Figure 6 depicts how a possible combination of these two approaches can be achieved. In this figure, a flow-based service composition is used as a component implementation. Instances from such a component can then be used to build an application using component composition.  Figure 6. Service composition used as component implementation Introducing service concepts to a
component model introduces creates new challenges for component
orientation, including
dealing with aspects such as dynamic discovery and adaptation to
dynamic availability. The benefit of such an approach is that it is a
way to introduce dynamic availability in a component model [Cervantes2004a].
These ideas are the foundations for the Service
Binder. References
|
|
||
|
