The TINA Service Composition Architecture

A Position Paper

Colin Ashford TINA Consortium ashford@nortel.ca

Abstract

The issue of software composition has received some exposure in the literature and in the market place of late, but the issue of service composition has received little attention. The TINA Consortium of telecommunications-related companies has examined the area in the context of developing an architecture for the delivery of new telecommunications services. The results of this research are encouraging and point to opportunites for the rapid deployment of new and innovative services.

1. Introduction

There has been some encouraging, if slow, progress in the area of software composition--the construction of software applications from domain-related components [Nier95], [Sun96] but hitherto there has been little attention paid in the literature to service composition. By service composition, we mean the creation of a new services by the combination of existing service components or service sessions. For example, it might be desirable to temporarily merge two separate teleconference sessions or it might be desirable to combine the appropriate audio and video components of a movie before delivering the combination to a customer. The TINA Consortium has developed a composition architecture as part of its Service Architecture [TINA96] which we present here.

2. Background

TINA is a consortium of over 40 companies including public network operators, telecommunications equipment suppliers, and telecommunications research organisations whose mission is "...to define and validate a consistent and open architecture for distributed telecommunications software applications". The TINA architecture is composed of four main parts:

a distributed service architecture that specifies a business model, a session model, service components, and service composition;
a network resource architecture that specifies the underlying connectivity services;
a computing architecture that specifies the distributed processing environment (DPE) required to support service delivery, and
a management architecture to provide overall network and systems administration facilities.

The key concepts in the service architecture are those of a session (a temporal relationship between components), a business model consisting of consumers, retailers, brokers, third-party providers, and network providers; and service components including service supports objects, session endpoints, and user applications.

3. TINA Service Composition

The TINA Service Architecture recognises two forms of service composition: dynamic composition that can be accomplished at runtime and entailing the ad hoc merging of services and static composition essentially that of service creation. In both cases a number of supporting services will be required including identification services (naming and name resolution), visibility services (browsing and type-resolution), and management services (accounting, security, and fault-management).

3.1. Composition Models

The TINA Service Architecture recognises three primary models for service composition:

Parallel Model: all the individual service interfaces of the constituent services are available to the user;

Serial Model: only the service interfaces of the primary service are directly available to the user--access to the service interfaces of the secondary service(s) is mediated by the primary service;

Component Model: a service is composed of service components (special resources, content, or service logic) rather than service sessions.

3.2. Support Services

In order to make composition possible, a number of support services need to be made available. Most of these services would normally be made available through the DPE, but additional services (especially in the case of static composition) may be required.

3.2.1. Identification

Identification of services, service components, and composite services will require a dynamically extensible naming model that supports intra- and inter-domain naming of types and instances. Name-resolution services will also be required to locate services and service components.

3.2.2. Visibility

Any extensible form of composition, whether dynamic or static, will require some form of discovery service. Trading services typically provided by a DPE for machine processing may be sufficient but, likely, browsing services providing informal information for human consumption will also be required.

3.3. Management Services

An important part of the overall TINA strategy is concerned with management and administration of TINA services. TINA management requirements are normally couched in terms of FCAPS (Fault, Configuration, Accounting, Performance, and Security) and service composition calls on three of these:

Accounting: billing models, subscription models, and account violations;

Security: authorisation, delegation of authority, privacy, and security violations; and

Fault: QoS agreements, best-effort or all-or- nothing, recovery, fault reporting, and critical service nomination.

4. Implementation

The TINA Service Architecture assumes that the implementation of dynamic service composition will largely rely on the services of the DPE defined in the Computing Architecture although it is noted that scripting languages could address behavioural composition. Static service composition will mainly be supported by the compositional notation of the TINA Object Definition Language--a super-set of the OMG IDL [OMG95].

5. Conclusions

The TINA service composition architecture is valuable in fostering an understanding of the requirements, impacts, and opportunities of service composition; it will go a long way in helping to reach the goal of rapid deployment of new telecommunication services. However, it offers only rudimentary support for the formal specification of service composition either from a structural or behavioural standpoint. Formalisms for object and functional composition can be found in the literature [Spiv89], [ISO92] but these are generally pitched at a fine level of granularity and generally in the context of programming rather than service delivery. However, we are encouraged by the popularity of component toolkits such as JavaBeans and scripting languages such as Perl and believe that such developments can help in the rapid deployment of new telecommunication services.

References

[TINA96] Telecommunications Information Networking Architecture Consortium (TINA-C). Service Architecture, Version 5.0, 1996. (Available through www.ticac.com)

[Nier95] Nierstrasz, O and Meijler, T. D., Research Directions in Software Composition. ACM Comput. Surv. (27)2, June 1995.

[Sun96] Hamilton, G. (Ed) JavaBeans. Sun Microsystems, 1996.

[OMG95] Object Management Group. The Common Object Request Broker: Architecture and Specification. 1995

[Spiv89] J.M. Spivey, The Z Notation: A Reference Manual. Prentice-Hall International, 1989.

[ISO92] International Organization for Standardization and International Electrotechnical Commission. Information Technology | Open Systems Interconnection | Management Information Services | Structure of Management Information
| Part 4: Guidelines for the Definition of Managed Objects. International Standard ISO/IEC 10165-4 : 1992.