slides

clappingknaveSoftware and s/w Development

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

62 views

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch
1

Different system architectures


Object
-
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
global

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
local

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

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

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch
2

Architecture of communication services and protocols

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch
3

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


protocol


user of protocol

user of protocol

service interface

service interface

Protocol

service interfaces of lower layer

message encoding

message encoding

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch
4

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
-
to
-
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
end
-
point (with FIFO property without loss nor errors)

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch
5

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
6

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
output(s)
) depending on the inputs and
the history of all previous interactions (also called
“trace”
, and
which represents the
state

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
7

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
system)

G.v. Bochmann, revised Jan. 2005

Comm Systems Arch
8

Different kinds of specifications for
distributed systems


See next page for explanations


Serv.

API

Prot.

the specification


-


x

TCP


-

x


socket interface of Linux


x


x

OSI Transport protocol


trivial


x

ASCI, JPG, MPEG, etc.


?


x

HTML


struct



ASN.1 (of OSI), IDL of CORBA


(struct)


x

ASN.1 encoding rules, OSI Remote Operations, GIOB



(struct)

x

x

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


struct


x

XML


struct

x

x

Java object serialization and RMI







G.v. Bochmann, revised Jan. 2005

Comm Systems Arch
9

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
no
, 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
client
's place.