Autonomous Adaptation to Dynamic Availability Using a Service

Document Sample
Autonomous Adaptation to Dynamic Availability Using a Service Powered By Docstoc
					Autonomous Adaptation to Dynamic
Availability Using a Service-Oriented
Component Model
Humberto Cervantes and Richard S. Hall

International Conference on Software
Engineering (ICSE) 2004 pp. 614-623

           Poster by
           Sankar Vaikuntapathi
n   This paper describes a project called
    Gravity,founded on the concept of service-
    oriented component model.
n   Supports the construction and execution of
    component-based application that are capable of
    autonomously reacting to the changes in the
    service availability at runtime.
n   Component orientation and service orientation
    are the foundations of the project Gravity
Component Orientation
n   Construction of applications as compositions of
    building blocks called component.
n   “A software component is a binary unit of composition with
    contractually specified interfaces and explicit context
    dependencies only.”

    q   This approach makes a distinction between component
        developers and assemblers.
    q   Components are physically available to the assemblers
        when composing the application.
    q   Component instances require an execution environment
        that provides run-time support such as life-cycle
        management, communication through a container.
    q   Examples of component model: EJB, CCM and COM
Service Orientation
n   Applications are assembled from reusable building blocks, where
    building blocks are services.
    q A service is a functionality that is contractually defined in a

       service description, which contains some combination of
       syntactic, semantic, and behavioral information.
    q only service descriptions are available during assembly

    q building blocks exhibit dynamic availability, since services can be

       registered or unregistered from the service registry at any time.
Combining services and components
n   A service is characterized by a contract.
n   Components implement a contract and provide the
    described service.
n   Services provided are published into a registry.
n   Service registry is used to dynamically discover
    services at run time.
n   A composition is a set of contracts used to select the
    concrete component to instantiate.
n   Any component that implements a given contract
    can be substituted with any alternative component
    that implements the same contract.
What is Gravity?
n   Java based execution environment that implements the
    service-oriented component model.
n   Follows a two-level approach that manages instances at a
    local level and compositions at a global level.
n   Manages dynamic availability of services.
    q Arrival of a new component

    q Departure of a new component – Example: A component
       may provide Bluetooth printer service which has
       dependency on the physical printer.
    q Arrival of a new component instance is published into the
    q Removal of a component instance is removed from registry.

n   Gravity simplifies the construction of an application that
    supports dynamic availability of its constituent services.
Instance level management-local
n   Manages particular component
    instance independent of the
    application it resides.
n   Component descriptor
    represents a contract.
n   Component description contains
    q a list of provided services

    q A set of service properties

    q A set of service
    q Name of the class that
       implements the component.
Composition level management
n   Composition-level
    management guides
    instance creation and
    manages the changes due
    to dynamic availability.
    Global view of the
n   Composition description
    defines set of provided and
    required services called
n   Each placeholder
    represents a contract.
Execution scenario
n   An application launcher allows the user to create
    instances of the components that provide an
    application service.
n   Application launcher provides a menu to select the
    application, in this case web browser.
n   Web browser is created inside the applications
n   Initially there are no components that offers browser
    plug-in service.
n   If the plug-in component is installed the browser
    displays the link that needs the plug-in is displayed
Execution scenario

                     n   The Gravity prototype and
                         demonstration is available.
n   Strengths:
    q   This paper introduces an environment that supports the
        dynamic availability of services where as other component
        models currently existing component models do not support
        the dynamic availability.
    q   Provides an effective platform for further experimentation.
n   Weaknesses:
    q   Execution scenario is not explained in detail.
n   Problems yet to be explored:
    q   This paper still leaves the ambiguity in resolving multiple
        instances that provide the same service even though it
        provides some filtering mechanism.

Shared By: