communications aspects of ansa

Communications Aspects of AN SA

49

Andrew HERBERT Advanced Networked Systems Architecture Project, 24 Hills Road, Cambridge CB2 1JP, UK," teleph.: 44 223 323010

This paper describes the communications primitives used in ANSA. ANSA has an object-oriented model of information, processing and distribution. An important part of ANSA is the Distributed Application Support Environment (DASE) which provides a consistent program level interface to both inter-process and network communications. DASE is a subject for current ECMA and future ISO standardization. DASE supports both synchronous and asynchronous activity and can be mapped onto many different sorts of communications services including voice channels, connection-oriented data networks, connectionless data networks and networks offering integrated voice and data services. Included in the paper is an outline of a distributed operating system based implementation of DASE.

Keywords: ANSA, Communications, DASE, networks, protocols remote operations, remote pr~,xlure call

Andrew Herbert is presently the chief architect of the ANSA project. This is a collaborative industrial venture, involving BT, DEC, GEC, HP, ITplc, Olivetti, Plessey, Racal, and STC/ICL, funded under the UK Alvey programme, to pave the way towards the next generation of open multi-vendor standards for distributed systems. Prior to ANSA, Andrew Herbert was a lecturer at the Cambridge University Computer Laboratory in the OK, con- ducting research in computer network-

ing, distributed operating systems, computer security and programming support environments. He is a fellow of Wolfson College, Cambridge, and a member of the ACM, BCS and IEEE.

North-Holland Computer Standards & Interfaces 8 (1988) 49-56

1. Introduction

ANSA is an architecture being developed by a collaborative project sponsored by BT, DEC, GEC, HP, ITL, Olivetti, Plessey, Racal and STL/ICL, funded under the UK Alvey programme, to pave the way towards the next generation of open' standards for distributed systems, building upon the current generation of OSI and related standards. The architecture is intended to be a generic architecture spanning the requirements for distributed processing in many fields of application including office automation, factory automation and telecommunications.

At the heart of ANSA is an architectural framework which provides a formal object-based model of distributed systems, their components and properties. Accompanying the framework are a series of architectural rules which determine how a system designer can use objects in the framework. The framework and rules enable the system designer to: • select appropriate components for use in a sys-

tem by rtle and property • treat components as building blocks and make

complex structures of them to meet system requirements

• specialize and extend architectural components to meet application requirements.

To assist the designer further, the architecture includes guidelines on how to implement the architecture sensibly and on the range of design trade-offs that must be faced during implementation.

2. The Object Model

The object model has been widely applied in programming languages, operating systems and distributed systems with subtle differences in meaning and scope. The ANSA view is that an object is most usefully thought of as a unit of design and structure and that it is convenient, but not necessary, for the implementation of a system designed using the object model to be imple-

0920-5489/88/$3.50 © 1988, Elsevier Science Publishers B.V. (North-Holland)

50 A. Herbert / Communications Aspects of ANSA

mented on a system with direct support for object-oriented programming. This leads to two views of objects, the black box view, and the white box view.

In the black box view an object is that which can interact with other entities, but whose internal organization and properties are unknown. This is an interface oriented viewpoint in which objects are described by the interfaces they conform to. Objects implemented in different ways can support identical interfaces, and are consequently of the same type from the black box perspective. The black box view is an appropriate view to take in the context of open and heterogeneous systems since it is concerned with what objects do and not how they do them. This permits vendors to choose implementations for products that best meet their market requirements, yet which at the same time conform to a public interface to permit interwork- ing.

In the white box view an object is described as a set of sub-objects assembled together, according to some rules, to interact. This is a constructional viewpoint, and is the view of the object model put forward by operating systems and programming languages which provide direct support for object-oriented programming. Objects implemented in different ways are different objects from this viewpoint, even if from a black box perspective they are of identical type. The concept of inheritance is often applied in the white box view. Inheritance means that an object exhibits all of the properties of the individual objects from which it is made. Thus the object can be used in any context where one of its ancestors is required. This is a very powerful concept for simplifying the implementation of complex systems.

3. Objects in ANSA

Objects in ANSA are black boxes - that is they are described by their interfaces. The architecture includes many recipes for white box compositions of (sub)objects to meet particular interface requirements. In an implementation of an ANSA system there will be special objects, called facto- ties, which consume templates, derived from the recipes, and manufacture new objects from them.

There is a stylized model of activity in ANSA. Activity may be wholly within an object, or may

span over several objects. The relationship between activities may be causal, parallel or rever- tire.

Causal activity is where one activity cannot begin until the completion of another, i.e., there is a sequence of activities to be progressed.

Parallel activity is where there is no constraint on the ordering of the activities and they can arbitrarily overlap.

Revertive activity is where activities in two objects are tightly coupled and a dialogue or session is established.

In an implementation, objects are an abstrac- tion relative to the infrastructure (programming language, operating system, hardware etc.) that supports them. Different infrastructures provide different styles of interaction to support the activity model (e.g., procedure call, message-passing, shared memory). ANSA specifies in some detail a particular infrastructure based on distributed operating system concepts.

Infrastructures may themselves be built from lower-level object-based systems (for example the distributed operating system could be pro- grammed in an object-oriented programming language, running on a CPU with direct support for object-oriented processing). Such recursion is per- mitted in the ANSA architectural framework.

4. Distributed Application Support Environment

The ANSA computational model for distributed processing is based on the concept of a Distributed Application Support Environment (DASE) spanning all the nodes in a distributed system (see Fig. 1). DASE provides the infrastructure for application-level objects and decouples them from the details of the computing and communications resources in the distributed system.

Activity at the DASE level is described in terms of operations. An operation is a sequence of processing steps within an object. Many operations return results and have a well-defined end- point; other operations are asynchronous and do not resturn results. DASE enables one object to invoke operations in another object.

DASE is presently being progressed as a technical report by ECMA TC32-TG2, based on the work of the ANSA project, for presentation to ISO TC97/SC21 as part of the proposed new

A. Herbert / Communications Aspects of ANSA 51

Objects

Infrastructure I

~ an operation ©

Distributed Application Support Environment (DASE)

Fig. 1. The computational model

Open Distributed Processing (ODP) work item. DASE takes a black box view of objects; ANSA

includes a Distributed Object Support System which provides a white box object implementation of DASE.

DASE is concerned with interfaces to an object. An interface is a view on to the operations of an object. An object may offer several interfaces - for example one to users and another to adminis- trators - and some of the object's operations may appear in more than one of its interfaces.

5. Binding

Before objects can interact, there must be a binding between them. This requires that the interface be published by the object supporting the interface operations and found by the object wish- ing to invoke them. The binding is an abstract concept represented within the infrastructure as network addressing information associations and connections etc.

Binding details can be static or dynamic. In a static system, the infrastructure is pre-configured, or downloaded with information about the bindings that may exist. In a dynamic system the objects themselves create and destroy binding information.

DASE provides two binding primitives called Export and Import. Export is used to publish the availability of an interface; the parameters of export are: • the interface type name (i.e., what sort of inter-

face) • a trading scope into which the interface is to be

published • a set of attributes to distinguish this interface

export from other interfaces of the same interface type in the same trading scope. A trading scope is essentially a name space for

interfaces, managed by a special object called a trader.

Import is the primitive to locate an object in a trading scope; the parameters of export are: • the interface type name (i.e., what sort of inter-

face) • the trading scope to search for the interface • a set of attributes to be met by the imported

interface. The division of the trading name space into

trading scopes allows for different trading poli- cies to be supported in different parts of the name space. The trading scope parameter selects which trading policy (and therefore wich sub-name space) to be used. A trader may support subtype matches on interface names and partial matching of constraints. An example of subtype matching is to request an interface to any sort of printing service (as opposed to selecting a lineprinter, laser printer or so forth). Partial matching of constraints allows for requests to bind to, for example, the nearest printer.

The result of an import is an association which can be the parameter of a subsequent interaction primitive to invoke an operation across the bound interface.

In a system using early binding, export and import essentially confirm dynamically the use of a preconfigured binding. In a system using dynamic binding the trader must carry out all necessary checking for consistency of use of interfaces.

6. Interaction Primitives

Figure 2 shows the two interaction primitives provided by DASE.

Object A Object B Interrogate ~ .'~(Reaction) ]

Announce (association, parameters) Object A Object B

Announce ~ -~" ~ (Reaction)

Fig. 2. Operation primitives interrogate (association, parameters) result


Interrogate provides a synchronous request-reply interaction. Invocation carries a set of parameters to the destination object which performs an operation in reaction to the request and subse- quently returns a result. An object may only have one interrogation outstanding at once for an activity. This is the conventional remote procedure call model [1].

Announce provides an asynchronous request- only interaction. Invocation carries a set of parameters to the destination object which performs an operation in reaction to the request. No result is returned. An activity may therefore stream off a sequence of announce request, independently of the activity in the destination object.

Interrogate Ii "~' (reaction)

return @-~i (reaction)

return ~ .

Interrogate

(reaction)

(reaction)

(reaction)

I Interrogate

I Interrogate

q return

(reaction)

annoufice

announce

return

7. Back Calls Fig. 3. Back calls

Revertive activities are supported in DASE via a 'back call' mechanism. While processing an operation in response to an interrogate, an object is provided with a temporary back association (provided that the interface permits back calls).

Figure 3 shows how back calls provide a session-like structure between the interacting objects. If an interrogate is invoked on the back association the session alternates between the two objects in strict alternation; i.e., a token passes back and forth. If announces are invoked on the back association there is no such alternation and so fewer messages are required. However this asynchronism has a number of implications for flow control and buffering which are discussed in Section 9.

8. Interaction Modes

Practical communication systems have a number of features such as error characteristics, delay and so forth which impact the ability of the system to support the interaction structures previ- ously described. DASE abstracts these communication properties into a set of named communication modes. Interfaces include a required mode necessary to support each operation in the interface.

A mode is a complex quantity made up of many elements. Some elements are concerned with physical properties such as bandwidth, delay and jitter. Two important elements from the interac-

tion structure point of view are sequentiality and cardinality.

A sequential communication system is one in which interactions arrive at the destination in the same order that they left the source.

A cardinal communication system is one in which all interactions invoked by a source appear at the destination.

These two attributes can be illustrated by examples: OSI layer 4 transport is both sequential and cardinal; a voice channel is sequential, but non-cardinal (since errors in transmission are not corrected); a datagram (connectionless) network is non-sequential and non-cardinal (since packets can be discarded and re-ordered); X.400 electronic mail is non-sequential and cardinal (since mail is always delivered, but not necessarily in the order in which it was sent).

This parameterization of communications is very important to DASE because it allows the system designer to trade off complexity in communications against complexity in applications with possible performance and cost benefits.

Interrogate invocations are always sequential and cardinal; that is to say in the absence of network partition and node failures they are ex- actly once. An interrogate once started will complete and will never be repeated. This provides an important synchronization property to the application designer. In the presence of failures, interrogate invocations are at most once (i.e., the guarantee is that the invoked operation will not


Table 1 Treatment of announce

Problem

seq. error

no l isten

Mode

CS

buffer

buffer

C-S

accept

buffer

-CS - C - S

discard accept

discard discard

seq. error: no listen:

buffer:

discard:

request a r r ives out of order request a r r ives while des t ina t ion sti l l r eac t ing to a previous one DASE r e t a i n s the r eques t un t i l i t is ready to be accepted DASE forgets about the reques t

occur more than one time, if at all). The general model of interface binding is that a

communications channel is set up between the objects for each operation in the interface. This permits the infrastructure to choose the most appropriate communications service for each operation. (In multi-media applications involving both voice and data operations it is quite possible that voice will transit one physical network - a PABX - and data another, LAN for example).

Operations can be grouped in an interface and a mode assigned to the group. Thus two operations to a database server, add Record and up- date Record could be put in a sequential group. The client would then be guaranteed that requests are delivered to the server in the order in which they are invoked. If the invocations are interroga- tions, each request will be held off until the reply to the previous request has returned. Table 1 shows the treatment of grouped announce invocations under various modes. If both announce and interrogate invocations are grouped, all outstanding announce invocations must be completed before an interrogate starts. Similarly while an interrogate is in progress, announces are not possible.

9. Examples

Figure 4 shows two examples of bulk data transfer between two objects exploiting different communication modes and back calls. The first shows the use of a sequential, cardinal stream, such as the ARPA TCP protocol or OSI layer 4 transport. An initial interrogate invocation re-

quests the transfer. Successive disk blocks are sent by announce invocations which are buffered to ensure that no data is lost. (In TCP and layer 4 transport, buffering is accomplished by end-to-end s top/s tar t flow control). The second example shows use of a non-sequential, non-cardinal protocol such as the ARPA IP or UDP datagram protocols. Here the announce invocations are not flow controlled and therefore requests may be discarded if the destination is overrun. Thus after the main transfer phase there are individual inter-

• FTP (cardinal, sequential)

Interrogate

(reaction)

(reaction)

(reaction)

° .

i h° - °

r . ~L "

• Blast (non-cardinal, non-sequential)

Interrogate

(reaction)

Interrogate

E r a ,

i 0

Fig. 4. Examples

~ (reaction) announce

announce

h announce , return I

I

I I

J j (reaction) •

I

| I announce :~ h announce il

I I(reaction) , return


rogate invocations to recover missing blocks. Since it requires a simpler protocol, the second example is likely to be more efficient than the first; the penalty is that the application is more complex since it must be prepared to receive blocks out of order and deduce which blocks have been lost. In a network with rate control block loss will be rare. This is a trade-off that only the system designer can make. It would be unreasonable for an architecture to force a particular choice in all cir- cumstances.

10. Implementation

ANSA includes an object-oriented implementation of DASE. The structure of the implementation for each node in an ANSA-based system is shown in Figure 5.

The DASE implementation can be layered above any real machine with a physical communications capability to other machines. The real machine may be raw hardware, or a machine running a proprietary operating system. This real machine provides the computation resources to support the ANSA abstract machine.

The ANSA abstract machine is a module added to the real machine which mechanizes the ANSA primitives (import, export, announce, interrogate, etc). Associated with the abstract machine is a nucleus which provides ANSA interfaces to the

association management interface process and memory / management interface / device interfaces

",, 4 , / ~ ' ~ ANSA instructions

- / ~ N u c e u s ~ (e'g" ann°unce) / Real . "Nb Instructions

I Abstract Machile I J (e'g'ADD)

I Real Machine

Communications Fig . 5. E x e c u t i o n m o d e l

services of the abstract machine and the real machine. The abstract machine and nucleus impose homogeneity on the heterogeneity of real machines that could be used in ANSA systems. The most important of these interfaces for the present discussion are device interfaces to the communications devices and an association management interface to load and empty a table of associations for local objects held by the abstract machine.

Depending upon the host, the abstract machine may be implemented as a library in each process, an extension to the real machine's operating system kernel, or as an auxiliary 'ANSA gateway' process.

Communication between local objects is handled entirely by the abstract machine. It directs announce and interrogate invocations from one object to another using information held in its association table.

Import and export are directed to a special binder object, found at every machine. Every local object in a host has an association to the binder (either by inheritance, or by reservation of some particular association).

Export informs the binder of the willingness of an object to support an interface and details of the entry point into the object for invocations across that interface are passed over (in an implementation specific way). The binder may record details of the interface internally, or make use of a distributed name server depending upon the trading conventions in use.

Upon receipt of an import invocation request for a local interface, the binder retrieves details of the interface and loads the association table with a pointer to the exporting object, returning an association number to the importing object. Subse- quent invocations using this association will be passed to the exporting object for execution.

There is no buffering in the abstract machine. So, for local invocation, the abstract machine provides flow control by holding off invocations until the destination is ready to process them.

Upon receipt of an import invocation request for a remote interface, the binder retrieves details of the interface and then invokes a local communications object with a remote binding request, giving details of the remote object. (The information recorded for remote interfaces is presumed to include sufficient detail to enable this step). The local communication object sends network mes-


I l, Fig. 6. Indirection

sages (via a nucleus device interface) to its peer on the remote node. The remote communications object then interacts with its binder and imports the interface of the remote object (which is local to the remote communications object). Once this path has been established the original importing object is given an association leading to its local communications object. Subsequent invocations using this association will be passed to the communications object, transmitted across the network, re- ceived, decoded and turned into a local invocation at the far end. This is shown diagrammatically in Figure 6.

This implementation provides objects with full access transparency: there is no difference in the communication primitives used for either local or remote operations. All of the complexity of protocol, buffering, flow control, data encoding and so forth is taken care of by the communications object. The communications object may be a sim- ple encapsulation of a full seven layer protocol stack in the real machine, or it may be a complete protocol implementation with a basic physical interface to the network. In the latter case, the communications object may be broken down into a series of interacting objects (possibly one per OSI layer) as required, using the DASE primitives to pass invocations between them.

The indirection strategy described above is very general; some other uses of it for dealing with aspects of distribution transparency in ANSA are as follows: • indirection via a logical name to physical ad-

dress mapper for location transparency and object migration

• indirection via a multi-cast communication manager and response collator for object rep- lication transparency in dependable systems

• indirection via a concurrency manager for transactional concurrency control.

11. Summary

ANSA is an object-oriented architecture for multi-vendor distributed systems. Conformance to the architecture is in terms of conformance to object interfaces. Design with the architecture is achieved by offering the basic building blocks and structures of a distributed operating system supporting the object concept.

Objects export and import interfaces to make bindings. Once a binding exists the importer can invoke operations on the exporter. Operations may use the synchronous interrogate primitive or the asynchronous announce primitive. During the course of an interrogate, the destination object may invoke back operations on the source. The reaction of the communications subsystem to errors and congestion is determined by an interface mode negotiated during binding.

The implementation of ANSA depends upon an abstract machine to mechanize the basic primitives and a binder to make bindings. Remote invocation is handled transparently via inter- mediate communications objects.


ANSA is contributing towards the ISO ODP standardization programme; the communications aspects of ANSA, known as DASE are the subject of an evolving ECMA technical report.

Reference

[1] Birrell, A.D. and Nelson, B.J., "Implementing Remote Procedure Calls", ACM on Computer Systems, 2 (1), February 1984, pp 39-59.

communications aspects of ansa

Documents