TAPAS Architecture

From TAPAS Wiki

Jump to: navigation, search

Contents

TAPAS architecture properties

The architecture properties are classified as general properties and adaptability properties. The general properties are defined as follows:

1) There must be a a flexible and common way of modeling services independent of the type of the service system,

2) The service models must be based on mechanisms appropriate for the type of functionality,

3) The software implementation mechanisms must be flexible and powerful,

4) There must be easy mapping of the conceptual service system models to the physical computing and communication platform.


The adaptability properties are grouped in three classes:

A): Rearrangement flexibility

B): Failure robustness, and

C): Resource load awareness and control

Adaptability Propterties
Enlarge
Adaptability Propterties

Rearrangement flexibility means that the system structure and the functionality are not fixed. Nodes, users, services, service components, capabilities, can be added, moved, removed according to needs. Mobility of persons, sessions, nodes, terminals is further seamlessly handled. New nodes and capabilities are found automatically when introduced, and needed information about changes is propagated. There is a continuous adaptation to changed environments and operation strategies/policies.

Robustness and survivability means that the architecture is dependable and distributed, and that the system can reconfigure itself in the presence of failures. Resources and functionality are duplicated, hardware and software component failures must be detected and reconfiguration and re-initialization must take place during system operation.

QoS awareness and resource control means that there is functionality for negotiation about QoS and optimum resource allocation, monitoring of resource utilization, and actions for reallocation of resources.

Property A defines the basic flexibility features of the architecture. Property B and C set requirements to concepts and features that are needed as a foundation for the specification and implementation of functionality that can provide these properties.


TAPAS architecture solution - Features and concepts

Service and computing architecture dimensions

TAPAS Service Functionality and Computing Architectures
Enlarge
TAPAS Service Functionality and Computing Architectures

To meet the general properties, the TINA architecture principle [1] is followed. The TAPAS architecture is constituted by a computing architecture and a service functionality architecture. While the service architecture has focus on the service functionality independent of imple-mentation, the computing architecture has focus on the modeling of functionality with respect to implementation, but independent of the nature of the service functionality. The service functionality architecture shows the structure of services and service components. The computing architecture is a generic architecture for the specification and execution of any service. The properties of the computing architecture, however, are the fundament for the creation of services with needed adaptable networking services properties. So the adaptability properties are realized by a mixture of the features and concepts of the computing architecture and the functionality of the service architecture.


QoS related concepts

The QoS-related concepts are: capability, capability performance, service performance and service level agreements (SLA).

A capability is an inherent physical property of a node, which is used as a basis for implementing services. Capabilities can be classified into resources, functions and data. Examples are CPU, memory, transmission links, special hardware, and special programs and data. Capability is needed to meet all the three adaptability properties. Performance concepts, however, are needed to meet the failure robustness as well as resource load awareness and control core property.

Capability performance measures comprise: capability capacity measures, capability state measures and capability QoS measures, i.e. traffic and dependability measures. Capability capacity measure examples are transmission channel capacity, CPU processing speed and disc size. Capability state measure examples are number of connections, and the number that is waiting. Important traffic performance measures are transfer time, waiting time, throughput and utilization. Important dependability performance measures are availability and recovery time.

Service performance measures are performance concepts related to the service provided to the service user. These measures comprise i) service system state measures and ii) service system QoS measures, i.e. traffic and dependability measures

Service level agreements (SLA) are agreements between the service users and the service provider. The agreement can contain elements such as: required capabilities, required service performance, payment for the service when the agreed QoS is offered and payment for the service in case of reduced QoS.


[1] Y. Inoue, et al., The TINA Book: A Co-operative Solution for a Competitive World: Prentice Hall, 1999.


TAPAS computing architecture

The theatre metaphor

The Theatre Metaphor
Enlarge
The Theatre Metaphor

The computing architecture is founded on a theatre metaphor. Actors perform roles according to manuscripts. Actors are software components in the nodes that can download manuscripts defining the roles to be played. An actor will constitute a role figure by behaving according to a manuscript. A play consists of several actors playing different roles, each possibly having different requirements on capabilities.

Computing architecture viewpoints

The computing architecture is illustrated below. The architecture has three views: the service view, play view and physical view. The service view considers the service as constituted by conceptual service components. The leaf conceptual service components are constituted by role figures which are implemented by actors. The actors are executed as operating system software components in nodes, which are physical processing units such as servers, routers, switches and user terminals.

TAPAS Computing Architecture
Enlarge
TAPAS Computing Architecture

Capability and capability performance measures defined in the physical view, however, are visible in the play view as well as the service view. The service performance measures and SLA defined in the service view are also visible in the play view. This is not explicitly illustrated in the figure.

The core platform is a platform supporting the execution of service functionality based on the computing architecture functionality.

The computing architecture concepts and functionality are intended to be a basis for designing functionality that can meet the general as well as the core properties. The three views meet the general architecture requirements. Concerning the core properties, the play view concepts are primarily rearrangement flexibility oriented. The QoS concepts, gives a basis for functionality that can meet the robustness and survivability as well as the QoS awareness and resource control properties.

Actor, role figure and service component types

Actor, Role Figure and Service Component Types
Enlarge
Actor, Role Figure and Service Component Types

An actor can be an Extended Finite State machine (EFSM) or Reasoning Machine(RM). Actors are able to download and execute EFSM- and RM-based manuscripts. Networked services are traditionally based on EFSM-based specification and execution. RM makes policy-based specification and operation possible. Policy-based software has a specification style, which is expressive and flexible.

A policy is a set of rules with related actions. A policy system is a set of policies. A RM is using a policy system to manage the behavior of a target system. A static policy system has a non-changeable set of policies, while a dynamic policy system has a changeable set of policies.

There are two types of role figures: i) EFSM-based role figures and ii) RM-based role figures. The EFSM-based role figure is constituted by an EFSM actor. The RM-based role figure is constituted by an RM actor.


TAPAS service functionality architecture

Service Functionality Architecture
Enlarge
Service Functionality Architecture

The functionality of the service functionality architecture are classified as

primary service functionality and

service management functionality.

The primary service functionality are services offered to external service users while the service management functionality are the functionality providing internal services for monitoring and management of the primary service functionality as well as the mangement functionality itself.

The service mangement functionality are further classified as: Service configuration, Capability and service administration, Capability and service monitoring and Mobility management. The service management functionalty has two repositories: Service specification repository and Inherent capability and service repository. Service specification repository stores role figure behavior specifications, capability type and capability parameter requirements specifications, and SLAs. Inherent Capability and Service Repository stores data about available nodes, capabilities and instantiated services.

Service configuration has sub-components as illustrated in the figure. Capability Configuration finds and selects target nodes that satisfy the capability requirements of the service. Capability Allocation allocates capabilities to the service users of the various service classes. This task is performed in accordance with the requirements of system performance, here defined as the sum of capability performance and service performance, defined in the SLA. The component Deployment and Instantiation comprises deployment which is the introduction of new service components in nodes, and instantiation which starts execution of deployed service components. Fault Diagnosis detects faults. System Performance Diagnosis detects mismatch between the required system performance and the inherent system performance. Service Adaptation plans the adaptation during the service system execution in case of 1) mismatch between the required system performance and the inherent system performance, 2) faults and 3) other reasons for service component movements.

Capability and service administration handles the registration of nodes, capabilities and instantiated services. This component also provides a current view of available nodes, capabilities and instantiated services.

Capability and service monitoring monitors nodes, capabilities and services. This component gets monitoring requests from Capability and sevice administration and updates monitored data via the same component.

Mobility management handles various mobility types such as personal mobility, terminal mobility as well as service component mobility.

Views
Personal tools