The Information Services Supermarket - a trial TINA-C Design

Mark Bagley, Ian Marshall, Martin Yates and Julian Hill,

BT Labs
Martlesham Heath
Ipswich, IP5 7RE
UK
Tel +44 473 646505
Fax +44 473 637400

Abstract

This paper describes the design steps we have found to be necessary to create a practical design for
realisation of a TINA-C like service environment supporting an advanced information service (Travel
Agent). It was found to be important to start by constructing an enterprise model which delineated the
roles of the stakeholders in the service. The next step was to construct a detailed service operation
scenario within the enterprise model. Only after this work was complete was it possible to commence
detailed system designs and make use of the technical content of the TINA-C deliverables. In particular it
was found that management aspects could not be designed without a very clear idea of what was to be
managed and why. A number of critical interfaces requiring standardisation have been identified during
the work and the the nature of the standards needed is explored in some detail in the paper. The designs
are now being implemented in an Asynchronous Transfer Mode (ATM) network environment on an Object
Management Group (OMG) Common Object Request Broker Architecture(CORBA) based Distributed
Processing Environment (DPE).

Introduction

Until recently the principal barriers to mass market introduction of commercial information services have
been technological and financial. Now that easy to use multimedia applications for cheap terminals are
readily available, the Internet is experiencing explosive growth, and it might appear that the problems are
solved. However, finding and retrieving the desired information is still time consuming, and no guarantees
of correctness are available. A commonly quoted solution to the problems is the use of intelligent
networked agents [1,2,4,8,9,13] as exemplified by TINA-C and General Magic. The agents required are
extremely complex and sophisticated and considerable design effort must be expended before they can be
realised in a concrete implementation. This paper will describe the early (abstract) design phases of a
project intended to realise a prototype commercial telecommunications/information service environment
using intelligent networked agents based on the TINA-C architecture [2,4]. We call this environment an
Information Services Supermarket. The first section contains a generic description of a well known
historic information service to illustrate the problems that must be solved. This is followed by an enterprise
model for this service, which was derived by analogy with service offerings in the retail and distribution
sectors [5,7]. The enterprise model has allowed us to breakdown the design problem and expose a number
of key interfaces. In order to progress to detailed design it was necessary to create a detailed example
scenario. We chose to use a travel agency as the example on the grounds that it would allow most of the
known issues to be explored and generalised for use in other examples. The enterprise model presentation
is followed by a section giving an overview of the scenario and the associated session designs which are
currently considered outside the scope of TINA but which need to be in place before the bulk of the TINA
output can be used. It is helpful to use TINA principles at this stage of the design. The next section
elaborates on the design of the supermarket, which uses a substantial range of components from the TINA
service and management architectures and refines the architectural concepts towards a practical realisation.
A few pointers to concurrent implementation experiments are also recorded. The next sections of the paper

page 1 of 13
explore and examine the key interfaces and their properties. Then finally we assess the benefits of TINA-C
in the work we have done and indicate areas where additions and improvements to TINA-C would be
beneficial.

Historic Information Services

When telephone networks were first introduced to an unsuspecting public they were very different to the
networks of today. To use the network one picked up a microphone, wound a handle to charge a battery
and said "operator". The instrument would respond by asking you to state your desires. Any reasonable
desire for information or communication could be satisfied, either directly (as in "Oh the doctor is at Mrs
Smith’s, I’ll connect you to there) or indirectly (as in "I don’t know but I know a man who does"). This was
at the time a wonderful and much loved service, however, as the networks grew problems started to appear.
• The service became inconsistent (it was better in small villages than large towns)
• The service became expensive (it was predicted that 50% of the population would be
telephone operators by the year 2000)
• The service became selective rather than impartial
• The service became a major management headache

Since the service was not earning revenue (no Electronic Fund Transfer Point Of Sale!) it was withdrawn
as soon as automatic switches (Strowger) became available. The users were pleased since their calls
became private and the service was cheaper and more consistent. Nevertheless the loss of the "information
mine" that operators once represented was regretted.

It is proposed that automation would solve many of the problems since an intelligent machine;
• Can provide access to large amounts of up to date information quickly
• Does not need training, sick leave etc.
• Can be copied any number of times to provide universal access
• Can be paid electronically
• Is always as impartial as its makers intended
• etc.

Indeed aspects of the service have already been reintroduced in an automated form, whenever it was
feasible and cost effective (e.g. Yellow Pages and Intelligent Network (IN) [3]). The work we will describe
is intended to realise an automated version of all aspects of a suite of "information services" similar to that
described above. The first stage is to construct an enterprise model and break the problem down into more
manageable domains.

Enterprise Model

The enterprise model we have developed was derived by interpreting the service above as information
retailing and attempting to represent the activities of a hardware retailer/distributor in the model. This
analogy is the source of the name "Information Services Supermarket". It was felt that basing the model on
an existing implementation in this way would enable productive reuse of existing technology and
knowledge and thus minimise the effort involved. Analysis of this enterprise model has led us to the view
that we need a distributed object oriented implementation with well defined open interfaces. Many (but not
all) of the concerns are addressed by TINA-C so we have used TINA-C as the basis of our designs
(elaborated in the next section). The model is shown in Fig. 1

page 2 of 13
 Information Services Supermarket

User Domain Service 1

Retailer Domain
User prefs Service 2
Management
User
of Services
Agent
Service 3
terminal Buyer Agents

terminal
agent
Service N

Connections, Network Resources

Provider
Network Domain Domain

Fig. 1. Enterprise model

There are four separate domains depicted in the model;

• The user domain
• The network domain
• The provider domain
• The retailer domain

The user domain represents the domain of interest of users of the services available in the retail domain. It
contains the user and items which he owns or controls such as his personal profile and applications, and his
terminal(s). It also contains a terminal agent which can negotiate with the retail domain and communicate
the capabilities of the users domain to the retail domain when necessary. This agent is intended to include
the terminal agent concepts from the TINA-C architecture. We envisage that the terminal agent may be
supplied by the retailer but owned by the user (or his subscriber).

The network domain represents the domain of interest of the owners of the network used to convey
messages from the user to the retailer or other users. It is envisaged that by analogy with "normal"
retailing the user will not have a direct contractual relationship with the network. Instead the network
should be regarded as a subcontractor to the retailer. Initial access of the user to the retailer is regarded as
being achieved by services such as freephone which are paid for by the retailer. The network domain is
intended to contain the network hardware and associated software, such as connection co-ordinators and
managers from the TINA-C connection management architecture. It also needs to contain connection
control features form IN Capability Set 1/2 [3] to enable freephone and mobility.

The provider domain represents the domain of interest of sources of the services which can be purchased in
the retail domain. It contains a set of disparate service providers, each of which provides agents which can
negotiate with buyers in the retail domain on supply and payment for services, and similar issues. It is
probably a specialisation of the retailer domain with a restricted set of customers and service offerings.
This allows the purchase of composite services.

page 3 of 13
The retailer domain is perhaps the most interesting. It is intended to represent the domain of interest of a
retailer who;
• Facilitates access to information and communication services and associated tools
• Acts as a middleman or broker for service providers and n etwork providers
• Offers customised guaranteed services to individual customers
• Manages the services
• etc.

It contains a set of intelligent agents which can respond to user and manager demands on an individual
basis. These include the TINA-C user agent, service session manager and communications session
manager. It also contains a set of management processes which allow managers to;
• Monitor activity
• Make configuration changes
• Specify and enforce policies
• Maintain quality, performance, access etc. as demand and resources vary
• Enforce payment and security related mechanisms
• Assess interactions and add links to third parties
• Advertise services
• etc.

A more complete list can be obtained by analysing the activities of existing retailers. We have found that
the above "services" can be supported by the existing TINA-C resource, fault and configuration concepts,
and that the concepts can be reused for high level designs of security, account and performance
management processes. This retailer can be considered almost entirely analogous to the arrangement a
supermarket (say a food retailer) has with suppliers of products and the services it offers to those suppliers
and the buyers of the products (subscribers). Services (products) are offered by the supermarket (say BT) on
behalf of the service providers to users (end-users that are associated with a subscriber). The service offered
can in theory be physically situated anywhere, so it could be resident in the service providers domain and
accessed via the supermarket, and indeed in practice this is the most convenient logical position for it.
Physically there are benefits to the service provider to have the service resident in the supermarket. This is
because if the supermarket operator is also a network operator or has access to a large network then the
service is potentially available to a wide range of users.

The model illustrates several important inter domain interfaces. These include;
• The user domain - retailer domain interface
• The retailer domain - provider domain interface
• The retailer domain - network domain interface
• The user domain - provider domain interface (mediated by the retailer)

In order to support flexible use of services from different providers and connections across different
networks using user domain terminals and applications of diverse types, these interfaces need to be open.
By this we mean that the capabilities required at the interface can be described using a set of defined terms
drawn from published standards and agreements. A key concern is to establish the degree of openness
required at the inter domain interfaces and agree how it can be achieved. The understanding of the
interfaces and their properties which we have gained from our design work, and the degree to which TINA-
C enables them to be open is the main topic of the final part of this paper.

Specific Service Scenario

In order to render the design efforts specific, and easily resolve the issues that arise, we have found it useful
to define a scenario for the use of the above Enterprise Model and Generic Information Service capability.
The scenario (at its highest level) defines the retailer as a franchise holder for a “strongly brand imaged”
travel company (whose branches are normally franchised). This travel company (TravelCo) has existing
contracts with third parties for the provision of various specialised services (such as brochure providers,
video footage provider, foreign exchange provider, Airline Booking, etc), and has provided an application
that can be made available to the user from a server in the retailer domain (TINA-C Service Factory

page 4 of 13
feature). The application, resident on the user’s terminal or acessed remotely from the retailer’s server,
provides a look and feel consistent with the brand image of the travel company and provides to the user
many of the usual services asssociated with a travel agent. The retailer will have provided a retail site with
good access links (from the Network Provider), the management of that retail site (Management Agents)
and access to it (TINA-C User Agents), and a number of additional user features such as mobility, links to
the generic services such as the users bank, multipoint videophone and E-mail. The user display in this
case consists of the display (icons menus, etc, -perhaps in a separate window on a video capable terminal)
of the Services provided by the Retailer with the specific TravelCo look and feel superimposed, with the
additional TravelCo features shown as say icons. This scenario is schematised in figure 2. It is not
presented as the only solution to the requirement of providing a scenario to test some of the designs, but
rather one way that seems to “exercise” the designs and the TINA-C architecture.

video TravelCo (Provider)

User
e-mail
TravelCo payment
AI Engine

Retailer

Foreign Exchange

Hotels

Airways

Package Holidays
Network Provider
Travel Customer Handling

Other subcontractors

Fig 2. Schematic Representation of Electronic Travel Agent Scenario

The full detail of the scenario currently runs to 20 pages and will not be reproduced here, however it is
worth bringing out a few key general points;
a) The scenario is very clear on the roles and responsibilities of the various stakeholders
b) The scenario is very clear on what the user should experience
c) The scenario quantifies the demands on the system wherever possible

These details have enabled a clear definition of the Quality of Service, performance, accounting and
security guarantees required and have thus provided strong constraints on the solutions adopted in the
system design. They have also provided a clear picture of what has to be managed, how well and why.
The result is a design for a lightweight management system which we believe is both fit for purpose and
practical to implement using available technology (including some research prototypes). It is worth noting
that this result is relatively independent of the specific scenario chosen -the scenario largely served to
justify design decisions by reference to a concrete model which was well understood by all members of the
team. An additional benefit was in the validation of the design - without the scenario many important
features of the design would not have been identified (creative abstract thinkers are rare!).

Having agreed on the Enterprise Model and a specific scenario we then progressed to the design. Rather
than attempt to use the Open Distributed Processing viewpoints (since we could not agree on their precise
meaning) we simply used an existing well proven methodology [12] with a useful support tool (Software
through Pictures - Object Modelling Tool). We also started to perform concurrent implementation
experiments (in the true spirit of Object-Oriented design). The experiments assumed an ATM network
platform since this could provide all the network properties our scenario demanded without involving us in
substantial network integration tasks. We used the proprietary signalling scheme supplied by the switch
manufacturer (Fore Systems), since the open ATM standards are not yet mature. Off-line network
hardware management (diagnosis, planning etc) is performed with the assistance of HP Openview. The

page 5 of 13
DPE was assumed to be OMG CORBA compliant, but with the addition of a trader (similar to the
implementation in APM‘s ANSAware).

The first stage in the design was to design a local application and a corresponding service session. The
complete service session is actually a hierarchy of component sessions. The top level sessions are
MarketBrowse, Bank and TravelAgency. These are coordinated by the user and terminal agents. The
component sessions such as E-mail are coordinated by a coordination service provided by the top level
sessions. Some of the component sessions (e.g. videophone) are also compound and thus contain their own
coordinators. A view of some of the high level components in the service session is provided below;

MarketBrowse A service which is launched automatically on access which provides the user with an
up to date view of the supermarket on his terminal

Bank A compound service giving the user access to his own banking services. Provided
via an agency in the Retailer’s environment.

TravelAgency A service provided by the Information Supermarket derived by compounding the

TravelCo franchise service/software into a single service session with existing
features of the supermarket, such as E_Mail, payment and video (see below).

Video A "one way" video service which allows video images to be piped from a source to a
remote destination.

E_Mail A service which allows users to send and receive electronic mail messages to/from
user’s that are subscribed to the E_Mail service. Again provided to the user via a
relationship with the Retailer, potentially independent of the TravelCo service.

Payment A service which allows users to make payment to the retailer. Perhaps a subset of the
BankingService (see below) or might be from a different provider. A user will have
the option of using the banking service instead if required.

VideoPhone A compound service which allows bidirectional and multi-party video telephony
between members of a group. It consists of
WhiteBoard A shared drawing space for multiple users.
AudioConference A bi directional multiway voice conferencing service.
VideoConference A bi directional multiparty video conference service

TravelCo A container for TravelCo software components, whose tasks include contract
management with subcontractors on behalf of the retailer, travel consultancy to the
retailers customers, profit or user satisfaction maximisation algorithms, support for
audit trails, etc. Contents include;
TravelCo_HelpDesk An interface to a subcontractor which provides "human"
assistance with the TravelCo package.
TravelCo_Core The main engine for establishing links with subcontractors
TravelCo_Coord The coordination software for the TravelCo Service.

This is not an exhaustive list but gives a flavour of what we are attempting. The deconstruction continues
down to the level of generic service components (GSCs or service independent building blocks) such as
Datareaders, Datarecorders, Monitors, Notifiers, Binders, Adaptors etc. This modularity provides
extremely good opportunities for reuse in different services and contexts and enables the extensible and
flexible configuration that the supermarket requires. The principles of hierarchical structuring were
derived frome the TINA USCM [2] but the existing TINA-C architecture was not much help in identifying
the above components. It is worth noting that the coordinators are not hierarchical controllers (in the
managed object sense) but peers with special tasks, for example they are usually intended to be recorders
and notifiers of changes in group membership (through faults or service regrades). They can also take on
more hierarchical activities such as refereeing when contentions for resources arise, etc if the specific
service design requires such a feature. They effectively provide coordination sessions which in their most
hierarchical realisation are analogous to threads on the TINA Connection Coordinator.

page 6 of 13
We have also designed a user application corresponding to the above service session. This consists of a set
of windows and icons corresponding to the components in the service session, a presentation manager
(local coordinator) and a set of communications adaptors. Since this part of the work is outside the scope
of TINA-C we will not elaborate further here.

In this scenario the TravelCo part of the service uses data from extrenal (federated) sources - the
subcontractors. To model this the TravelCo session dynamically invokes SubconDataAcc sessions (a
further specialisation of service session) when required. This is analogous to the dynamic invocation of
communication sessions (TINA connection management).

SubconDataAcc A service providing licensed access to the data owned by third parties who provide
the retailer with goods and services and with whom the retailer has a contractual
relationship. Included in here are the services listed in Figure 1, namely Foreign
Exchange, Hotels, Airways, Package Holidays and Travel Customer Handling.

The implementation experiments have resulted in a Graphical front end which can access a user agent, and
hence a remote Service Session which will invoke ATM connections and read relational databases. To date
we are confident that the design is practical and have not discovered any insoluble issues.

Supermarket Design

This section is intended to present and discuss some of the high level designs we have created for the
retailer domain or "Information Services Supermarket" which enable access to, and management of, the
above service. The issues discussed concentrate on inter domain relationships, especially with other
supermarkets, network providers and users. The intention is to justify the following discussion of
interfaces.

The user (no matter what role he is playing) accesses the system via a terminal of some kind (say a
personal computer or a set-top-box of comparable processing power, with some technology to access the
system, DPE node, network access, code to access the services on the system, etc.). As far as the retailer is
concerned each terminal contains a Terminal Agent (TINA-C Generic Session End Point), which manages
communications, and a set of representatives which convey necessary information about the user, his
Graphical User Iinterface, his applications, his terminal and his current Network Access Point (NAP). The
current terminal agent design can be summarised by the following three entities;

TerminalRep This is a conceptual object, which is here used as a container for a cluster of
other objects. It holds context details on terminal based representatives. e.g.
User, User Interface, Application, Terminal and NAP.

AccessObject Based on the TINA-C GSEP. It manages AccessSessions, relays context to

UserAgent, finds an Initial Agent (explained later) and negotiates with local
agents e.g. presentation manager and user notifucation of incoming messages.
This object contains the terminal coordinator.

AccessObjectSession A representation of a thread of AccessObject activity (this is not the TINA-C

access session concept)

Clearly the representatives are an important area where standardisation is required at the user-retailer
interface.

page 7 of 13
A user calls up the supermarket via some kind of "Freephone" service1, which the user has been previously
given by the supermarket operator during the agreement of a contract (Service Level Agreement) with the
supermarket. The user will then send a message to gain access to the range of services (either remotely or
transferred locally2) via the user’s agent. The agent used will depend on the role that the user is playing, we
have defined and designed a number of agents including:

Sales Agent This is the agent the user sees when he has logged onto the supermarket
and wishes to browse and/or try out services. He needs to supply
subscriber authentication to buy (get access) to services.

Subscription Agent An agent for the purchase of Services for use by End-Users. Acts for a
number of End-Users.

Management Agent An agent for the management of the Service, enabling management
activity not delegated to the system, e.g. Service Operator role.

Service Provider Agent The access the Service Provider has to the Service Provider’s service logic,
perhaps located in the Retailer’s Domain.

Buyer Agent An agent for the purchase of Service Provider services for resale/inclusion
in another service. The actions are split between those that the buyer can
act on the service provider and those that can act on the supermarket:

Initial Agent The initial agent that is available on start-up of a service for the first time.
Control is passed to any of the other agents, to which agent depends on
the actions of the user in identifying to the supermarket what role he is
playing.

Terminal/NAP Agent Services that have been made available to the terminal or NAP are used
via this agent.

User Agent The end-user aspects, the end-user is not the provider (i.e. subscriber) of
the service and therefore cannot browse.

When a service is invoked the above agents will identify an appropriate service factory which will provide a
service session. The agent will then spawn a usage session, a "temporal container" for the actions of the
user (TINA-C definition), which ensures that chargeable actions of the service session are recorded in the
users account record. Each agent has an associated session object class.

AgentServiceSession A temporal container for user session information. Its role is to notify
the client agent in the event of the failure of the ServiceSession; monitor
events, arrange monitoring and storage on “clear-down” of relevant data
e.g. for charging

The Service Factory will also spawn a temporal container to enable permanent recording of events
associated with the service session and a set of management objects not included in the user oriented
session design in the previous section, which will report information to it and notify the service coordinator
if nesessary. These management objects can be divided into a set of types including monitors (for
performance, security, fault etc), accounters (for timing charging etc), blockers and mediators. They are all
members of a class we refer to as Management adapters.

1
only available if the communication medium controller (supermarket operator or network operator) has an agreement with the
user’s home supermarket operator to allow freephone service to operate, otherwise the user has to use the standard call and
pay for the call to the local operator as a separate operation.
2
Depends on the relationship between the local communication medium operator and its relationship with the user’s home
supermarket operator.

page 8 of 13
 ManagementServiceSession Temporal container for persistent service management information. For
example it may be involved in notifying the ServiceFactory if a Service
Session dies or store service QoS information for later retrieval by an
off-line system.

ComponentMonitor Enables the performance of a component to be observed and recorded.

For example performance management can be carried out by this
monitor notifying the associated accounter or coordinator to trigger
tarriff changes or component replacement. (These concepts were
derived by examining the management interface of the connection
performer and extending the role of the connection coordinator)

ComponentCounter Binds to a clock if required and holds current tarrifing algorithms

ComponentBlock Blocks access to a component if this is temporarily undesirable (e.g

there is an interaction with another concurrently invoked component.

ComponentMediator Enables interworking without specialisation of the core GSC

Clearly in order for usage to be possible any content software derived from a provider (e.g. the TravelCo
object described in the previous section) must either conform to some rigorous set of standards, or it must
be wrapped so as to appear as though it does, by objects like the above adaptors. Either way a well defined
standard is required.

Our designs have reached a significantly more detailed form in parts than the exemplary designs in the
TINA-C deliverables. Indeed many components have already been implemented on an OMG derived DPE
[6,11]. We have chosen to present the design at a similar level of abstraction to that in the TINA-C
deliverables since we feel that this abstraction has some useful properties;
a) The level of detail is sufficient to allow a formal specification using which one can prove many of
the properties needed to enable components implemented in different domains to interwork. At
present such specifications have to assume a common language of concepts at the interface, which is
not currently specified by TINA-C. This paper aims to illustrate our thoughts on the properties of
the language required.
b) The level of detail is sufficiently abstract that it does not require disclosure of significant IPR over
and above that which will be contained in a mature TINA-C, and any potential commercial
differentiators arising from it.

Our proof of a) rests on a case study of the above access agents, which we have specified in the Pi-calculus
of Milner et. al [10]. The specification enabled us to show that, providing services conformed to certain
simple rules of naming and event ordering, third party services would not interfere with the activities of the
access agents and the retailers management system, and also that access to services would not be granted
without guarantee of payment. The preconditions were derived from analysis of the enterprise model. The
proof of b) is simply that the designs presented are a reworking of concepts which are in TINA-C, together
with some additional concepts which, we believe, will form part of a complete TINA-C and which we are
happy to place in the public domain.

Unfortunately the level of abstraction is at present only defined by reference to the TINA-C deliverables.
Although it is likely that this represents the maximum level of detail that partners are happy to expose, a
more rigorous definition would be useful. At present we merely observe that this definition will not be
simple.

Inter domain interfaces

In support of the operations of the supermarket there will be a transfer of information across the inter
domain interfaces identified in the Enterprise Model. Examples are listed in table 1a and the required
protocols are listed in table 1b.

page 9 of 13
Specification required for: Examples/comments

Content on server & demands on system granularity, size, format, behaviour

Terminal
Source
Application in terminal
Application reqs of source
User Interface on terminal
User Profile
Comms capability
Tariffs and bills
Protocols and Languages
Addressing/Naming scheme
RPC : Remote Procedure Call IDL: Inteface Definition Language
HTTP : HyperText Transfer Protocol
RAM, O/S, speed, configuration
RAM, O/S, speed, configuration
quantity, version, source, permits
quantity, version, source, permits
API (e.g. ’Windows’), drivers, colours, format
credit limit, tariffs/bills, identity/authority
Network card, NAP type
Tariff options (as a function of QoS, service type), billing information
e.g. RPC & IDL pair, HTTP & HTML pair, etc.
User Names, Network Addresses (Access Points, Server location),
Application names, etc.
API : Application Programmers Interface
HTML : HyperText Markup Language

Table 1(a) Key Properties for specification

Protocol Comments
messaging between: User and Retailer "Play", "Pause", etc.
Customer and Retailer Status -for example, billing information
Provider and Retailer Info -for example,
messaging between: User and Provider Similar to User to Retailer, user must be allowed to
deal direct if desired
signalling between: User and Network for example, the User Network Interface to request
Retailer and Network network resources for configuration, management, etc.
Customer and Network

Table 1(b) Protocols for specification

Typical examples of critical interdomain interfaces are those between the TINA-C Terminal Agent (TA)
and the TINA-C User Agent (UA) and between the TINA-C User Agent and the TINA-C Service Session
(SS) concepts. A more computational view of these interfaces is shown in Figure 3. The numbers in Figure
3 refer to the lists of information categories in the in Table 2. The categories are intended to represent
conceptual domains for which a common language must be agreed. The reuse of the numbers indicates
possibilities for reuse of the lists in the table

App ua-factory s-factory

2
1
1

TA UA SS(M)
1 2

App : Application s-Factory: Service Factory ua Factory : User Agent Factory SS(M) : Service Session (Manager)

Fig. 3. Graphical view of key interfaces

The specific capabilities of each of the interfaces have been partially enumerated. For example the type of
information needed to be exchanged at each of the interfaces Terminal Agent(TA) to Usage Agent(UA)
[Interface 1] and UA to Service Session(SS) [Interface 2] are shown in Table 1 (c) below:

page 10 of 13
 Interface Type 1: TA-UA Interface Type 2: UA-SS
Terminal/App. Capabilities Service Level Agreement
-X-open (e.g. X11)
-naming scheme
-NAP properties
-bandwidth
-comms technology
-protocols
Basic Message Protocol Quality of Service
-precondition for 1 -response time
-starting point
Stream End Point Encryption
-NAPs and Ports
Message End Point Charges
-Names
Application End Point Preferences
- 2 and 3 -e.g. extra NAPs
Constraints
Names
Adaptations
Owner Defined
NAP
Ports
Note: Interface 1 is a specialisation of interface 2.

Table 1(c) Key Properties for interfaces

Interworking Capability Sets

The work presented in the previous section makes it clear that the degree of openness needed to implement
many of the exciting features of our design, such as the flexible use of third party services and extensive
terminal heterogeneity, implies a high level of agreement or standardisation between the involved parties.
A realistic approach would be to define levels of conformance to TINA-C with consequential levels of
feature support. These levels can be interpreted as a hierarchy of capability sets from a simple message
passing capability to a fully TINA-C compliant open capability. Support for an Interworking Capability Set
maps onto a level of openness of the supermarket, which may or not be desirable depending on the
circumstance of the use.

We propose a hierarchy of Interworking Capability sets for consideration by TINA-C, listed below:

0 Basic message passing, i.e. any form of communication channel

e.g. Telegraphy, Tones, IP
3
1 Technology available now for the provision of services
e.g. Telephony, Internet with fixed tariffing and fixed QoS (for duration of service)

2 Functionality in the management of services that could be achieved without TINA-C

standardisation and in the near term, specifically to support terminal mobility. Such as GSM
and UPT, and support of variable bandwidth provision for connections (ATM).

3 More advanced functionality with a longer timescale than 2, specifically to support user mobility.
Such as support for user agents, service portfolios for individuals (or groups thereof) i.e. user
profiles, context dependent tariffs and quality of service, limited feature selection for the user

4 Heterogeneity of Applications, terminals, user interfaces and support for personalised user
preferences.

3
in the developed countries

page 11 of 13
5 Full user customisation of services (and products).
Interworking Capability Set 4 is the highest level of standardised/publicised interaction that will be possible
between companies (supermarket owners, service providers and network operators) conformant to the
TINA-C principles.4 Interworking Capability Set 5 is intended for use within companies and between
companies with special arrangements. Interworking Capability Set 4 is expanded below since it is this set
which is most relevant to the information supermarket and TINA-C. The expansion indicates specific
concepts required to achieve the functionality indicated and suggests standards which could be sources of
the terms and definitions which will enable open discussion of the concepts.

Network and DPE Terminals Applications User Interfaces Users

i Protocol translations Owner defined Version and Reproduce user Set filters
ii Comms between capabilities manufacturer defined look Deal with
heterogeneous DPEs Resolve compatibility and feel on any incompatible
iii Definition of end points, etc conflicts with Portable device filters
(what is a network ?) user Flexible Choose my menus, Pick and mix
preferences configuration VR, text features
Hardware and styles, colours, speed,
independent deployment + still communicate
O.S. with
independent capabilities
i ii Nucleus Behaviour Express underlying Constraints
invocation Bindings Wrappers Dependencies needs time
reply channel definiton Capabilities Relationships Shared attributes location
notification ordering Properties of Entity Agree capabilities recipient
argument sychronisation hardware Format price
result transactions (machine interaction
object profiles) QoS
interface permissions
stream details
source
sink iii
protocol G803
OMG OMG DAVIT TINA-C, Nextstep TINA-C +
TINA-C ? IETF SPIRIT Multimedia X-11, Auxiliary’
TINA-C ? TINA-C forum Microsoft Windows Projects,
OSI OMG X-Open, OLE select from ITU

DAVIT The Digital Audio-Visual Council IETF Internet Engineering Technical Forum
OSI Open Systems Interconnect X, etc Computer Video Display Standards
OLE bject Linking and Embedding (Microsoft) Nextstep OO Operating System
SPIRIT Service Provider Integrated Requirements for Information Technology

Table 2 Expansion of Interworking Capability Set 4

TINA-C Support for designs

We have found the published TINA-C concepts to be useful in our designs. Of particular interest was the
discovery that the exemplary designs could be extended easily into some areas not considered in detail by
the core team through reuse of concepts such as the USCM, agents and sessions, to express different
concerns, e.g. performance and security management and the handling of policies. Initially we found the
lack of an agreed methodology was a stumbling block but with hindsight we feel this is a strength since it
allowed us to define a methodology for ourselves (based on Rumbaugh) which was well understood by both
our design team and our implementation team. The conclusion seems to be that any methodology capable
of expressing the full set of TINA-C concepts will suffice. It may be useful for the core team to suggest a
range of suitable approaches but this should not be prescriptive.

4
via interface definitions -see the table in the previous section of this paper

page 12 of 13
There are areas of our design work which are outside the current scope of TINA-C, most notably the
concerns about user applications and the user interface. Whilst it is important that these areas are
addressed in a collaborative forum we feel that it is not realistic for TINA-C to expand its current efforts in
this direction. We propose however, that the core team should identify bodies which are covering the area
(such as multimedia forum) and make some effort to develop concepts which enhance compatibility.

The major concern we have with TINA-C in its present unfinished form is the lack of detail in the key area
of open interfaces and the associated standardised languages. In order to accelerate progress we propose to
input our proposals for solutions to the TINA-C Core Team immediately and work with them on further
development.

Conclusions and recommendations

It has proved possible to create a high level design of an advanced information service and its environment
using the TINA-C concepts. However major gaps in TINA-C have been identified especially for User
Interface concerns and in the standardisation of key interfaces. We conclude that the set of concepts
offered by TINA-C needs to be extended to cover these gaps and that further developments should
concentrate on the provision of an agreed high level interface definition language which should be thought
of as a client of the OMG IDL. Although the TINA-C core team has not yet issued a request for solutions
in this area we intend to provide them with our suggestions.

References

[1] Arango M et. al. "The Touring machine system" Comm ACM, 36, 1 (1994)
[2] Berndt H and Minerva R (eds) "Definition of service architecture" TINA-C Deliverable (1994)
[3] CCITT recommendation Q.1201 "Principles of Intelligent Network Architecture" (1992)
[4] Chapman M "Overall Architecture" TINA-C Deliverable (1994)
[5] Darabi F and Howard-Healy M "Virtual Private Networks: Market Strategies", Ovum (1992)
[6] Iona Technologies "Orbix programmers guide" Iona technologies (1994)
[7] Jeffcoate J and Templeton A "Multimedia strategies for the business market" Ovum (1992)
[8] Kautz H, Selman B and Coen M "Bottom up design of software agents" Comm ACM, 37, 7 (1994)
[9] Kobayashi H (ed) "Service Component Specifications" TINA-C Deliverable (1994)
[10] Milner R "The polyadic pi-calculus: a tutorial" in Logic and Algebra of Specification, F Bauer et al
(eds), Springer (1993)
[11] OMG "The common object request broker architecture and specification", doc no 91.12.1, revision
1.1, draft 10 (Dec 1991)
[12] Rumbaugh J et al "O-O Modelling and Design" Prentice Hall (1991)
[13] White J "Telescript technology: the foundation for the electronic marketplace" General Magic White
Paper (1994)

page 13 of 13