clappingknaveSoftware and s/w Development

Dec 14, 2013 (3 years and 7 months ago)


G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Different system architectures

oriented architecture

(only objects, no particular structure)

Layered architecture
(e.g. layered functions of an operating system)

Embedded systems: We have to model the complete system

“work flow analysis”: to model the whole work process including
automated and non
automated parts

process control systems: model of the plant and the control system

Communication services and protocols: a distributed and
layered architecture

(see slides below)

Service specification provides the

view of the service provided by a
layer (the distribution aspect is ignored, a single distributed component is
considered, but different interfaces are considered for the different service
access points)

Protocol specification: the view is

(the behavior of a local protocol
entity is specified) and

(e.g. abstract layer interfaces, certain
functional properties of the specified protocol entities can be left

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Architecture of communication services and protocols

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Architectural structure of a protocol layer

protocol entity

protocol entity

communication service used by the protocol

(offered by the lower layer)

service offered

by the


user of protocol

user of protocol

service interface

service interface


service interfaces of lower layer

message encoding

message encoding

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Service specification

The specification of a communication service has two parts:

specification of an
abstract service interface

through which the service can be
locally obtained (sometimes called service access point)

e.g. in the case of TCP: local interactions for establishing a connection and for
closing it; sending a flow of data over an established connection (with flow
control, no notion of "end of service unit")

It is an abstract interface, the interaction primitives may be considered a kind
of abstract message (initiated by one side, received by the other side of the
interface; some interactions are initiated by the user, others are initiated by the
service). The specification of an abstract service interface is like the
specification of the dynamic behavior of an object class. It includes

Static aspects

list of interaction primitives, also called service primitives (like messages exchange; not
like method calls that have the initiating party blocked until the method returns)

for each primitive, which sides initiates the message, and its parameters and their type

Dynamic aspects

sequencing rules which define in which order the primitives may be executed

rules concerning the allowed parameter values for particular execution sequences

specification of the
end behavior

of the (distributed) system component that
provides the service

e.g. in the case of TCP: the establishment of a connection involves local
exchanges at both end
points of the connection concerning the connection
establishment; data received at one end
point must have been sent at the other
point (with FIFO property without loss nor errors)

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Protocol specification

Protocol specification = definition of the behavior of a protocol entity as visible
at the upper and lower (abstract) service interfaces

This includes

reference to the specification of the upper (abstract) service interface (normally defined by the
corresponding service specification)

reference to the specification of the lower (abstract) service interface (normally defined by the
service specification of the underlying service used by the protocol)

dynamic behavior of the protocol entity, that is,

sequencing rules concerning interactions at the upper and lower interfaces.

Note (a): Certain protocols developed by certain groups, e.g. IETF, do not refer to any service specification. In this
case only the ordering of interactions at the lower interface are defined.

Note (b): In the simplest case (if the protocol does not use any connections, or if it can be assumed that appropriate
connections are already established) the interactions at the lower interface only include the sending and receiving of
protocol messages (so
called PDU's).

Rules concerning the allowed interaction parameters

e.g sequence numbering in TCP, sending acknowledgements, etc.

Encoding rules

(a) concerning how interaction parameters received at the upper interface are coded and sent as so
called "user data"
in one of the data fields of the primitives at the lower interface
(and inversely the decoding of user data to obtain the corresponding
value for the upper interaction parameter).

e.g. in the case of the IP protocol: how is the address "local host" coded in the destination address field of an
IP packet ?

(b) concerning the coding of protocol control information managed by the protocol entity

e.g. in the case of the TCP protocol: where in the "user data" of the lower layer primitive (which in the case
of TCP is the data field of an IP packet) is the TCP sequence number placed and how are the integer values
coded ?

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Properties to be specified (in general)

Functional properties

properties of a sequential program: results as a function of the input

properties of a reactive system:

Safeness properties: results (or
) depending on the inputs and
the history of all previous interactions (also called
, and
which represents the

of the system).

Liveness properties:

(1) response time: Different levels of guarantee: (a) guarantee of an eventual
response, (b) guarantee of an average response time, (c) guarantee of a maximum
response time (hard real
time guarantee)

(2) fairness properties : relative “priority” in the case of several “clients” (this can be
formalized by Temporal Logic)

behavior in exceptional situations (in addition to the behavior in the
“normal” situations)

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Different levels of abstraction

When is a specification complete ?

Note: One should leave
“implementation details” unspecified !

abstract interfaces (leave the details of "concrete interface

unspecified), based on abstract interaction primitives, such as

message passing (as suggested above for service access points)

abstract operation call, possibly over distance (e.g. remote procedure call), where
the caller waits for the results

rendezvous (with reciprocal waiting)

examples of concrete (implementation
level) interfaces

a set of procedures to be called at the level of a programming language (typical
“application programming interface” (API))

communication protocol (PPP, bus interface within a workstation, etc.)

Note: In the case of a network access between X.25 protocol interface between
computer and network node.
Similarly, in the case of an
API one distinguishes
between the client program and the server side (which may the the operating

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Different kinds of specifications for
distributed systems

See next page for explanations




the specification






socket interface of Linux



OSI Transport protocol








ASN.1 (of OSI), IDL of CORBA



ASN.1 encoding rules, OSI Remote Operations, GIOB




ORB providing Java interface and using IIOP (GIOB over TCP/IP)







Java object serialization and RMI

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch

Explanation of previous slide

The first three columns indicate whether the Service (or abstract
service interface), the detailed API, and/or the Protocol is
defined by the specification in question.

" means
, and it would be better if this was defined

"struct" means that the specification defines how one can define data types,
object classes, etc.

"(struct)" means that the specification makes use of a notation for defining data
types, etc. given by another specification (e.g. an ORB uses IDL)

The specifications of ASCI, JPEG, MPEG, HTML, XML, Java serialization,
and ASN.1 encoding rules include no aspect of sequencing of service
primitives, because they are concerned with the question how some data
object is coded as a string of bits. Therefore these protocols are also very
useful for writing these data objects into data storage.

The specifications of the OSI Remote Operations, CORBA ORB and Java
RMI and SOAP (using XML) provide a service of invocations of operations
on remote objects. In the case of ORB and RMI (which provide an API) the
paradigm of a proxy object is used. The proxy object is co
located with the
client which calls the remote server; the proxy represents the server at the
's place.