G.v. Bochmann, revised Jan 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 Comm Systems Arch 2 Architecture of communication services and protocols

G.v. Bochmann, revised Jan Comm Systems Arch 3 Architectural structure of a protocol layer protocol entity communication service used by the protocol (offered by the lower layer) service offered by the protocol user of protocol service interface Protocol service interfaces of lower layer message encoding

G.v. Bochmann, revised Jan 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 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 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 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 Comm Systems Arch 8 Different kinds of specifications for distributed systems See next page for explanations Serv.APIProt.the specification -xTCP -xsocket interface of Linux xxOSI Transport protocol trivial xASCI, JPG, MPEG, etc. ? xHTML struct ASN.1 (of OSI), IDL of CORBA (struct) x ASN.1 encoding rules, OSI Remote Operations, GIOB (struct) xx ORB providing Java interface and using IIOP (GIOB over TCP/IP) struct x XML struct xx Java object serialization and RMI

G.v. Bochmann, revised Jan 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.