System Design Document
Network & Event Service
Informatik XII
WS 1998/1999
Technische Universität München
Preface:
This document addresses the requirements of the PAID system. The intended audience for this document are the designers and the clients of the project.
Target Audience:
Clients, Developers
PAID Members:
|
Project Management: |
Bernd Brügge, Günter Teubner |
|
Team Coaches: |
Ralph Acker, Stefan Riss, Ingo Schneider, Oliver Schnier, Anton Tichatschek, Marko Werner |
|
Architecture Team: |
Asa MacWilliams, Michael Luber |
|
Authentication & Security Team: |
Klaas Hermanns, Thomas Hertz, Guido Kraus, Gregor Schrägle, Tobias Weishäupl, Alexander Zeilner |
|
Database Team: |
Osman Durrani, John Feist, Florian Klaschka, Johannes Schmid, Florian Schönherr, Ender Tortop |
|
Learning Team: |
Burkhard Fischer, Jürgen Knauth, Andreas Löhr, Marcus Tönnis, Martin Uhl, Bernhard Zaun |
|
Network & Event Service Team: |
Henning Burdack, Jörg Dolak, Johannes Gramsch, Fabian Loschek, Dietmar Matzke, Christian Sandor |
|
STAR NETWORK Integration & User Interface Team: |
Daniel Stodden, Igor Chernyavskiy, Inaki Sainz de Murieta, Istvan Nagy, Stefan Krause, Stefan Oprea |
|
Testbed Team: |
Bekim Bajraktari, Bert van Heukelom, Florian Michahelles, Götz Bock, Michael Winter, Sameer Hafez |
Revision History:
Version R1.01 01/24/99 Marko Werner. Created
Version R1.02
01/25/99 Henning Burdack. Released.
Version R1.1net 02/01/99
Henning Burdack, Johannes Gramsch. Networking SDD
Version R1.2net
02/08/99 Fabian Loschek. Edited Chapter 4
Version R1.3net 02/08/99
Henning Burdack. Added Diagrams for System Decomposition
Table of Contents
1 Goals and Trade-Offs 1
2 System Decomposition 1
2.1 System Decomposition 1
2.2 Layers & Partitions 1
2.3 System Topology 2
3 Concurrency Identification 2
4 Hardware / Software Mapping 2
4.1 System Performance 3
4.1.1 General System Performance 3
4.1.2 Input / Output Performance 3
4.1.3 Processor Allocation 3
4.1.4 Memory Allocation 3
4.2 Connectivity 4
4.3 Network Architecture 5
5 Data Management 5
6 Global Resource Handling 5
7 Software Control Implementation 5
7.1 External Control Flow (between subsystems) 5
7.2 Concurrent Control 5
7.3 Internal Control (within a single process) 5
7.4 User Interface 5
8 Boundary Conditions 6
8.1 Initialization 6
8.2 Termination 6
8.3 Failure 6
9 Design Rationale 6
9.1 Event Service vs Method Calls 6
9.2 Voyager vs Other Middleware 7
The Event Subsystem consists of the following classes:
Event Hierarchy:
The Event Service has to handle multiple internal events (nested and concurrently running) and also multiple events originated by external systems (servers and clients).
Each event will be accompanied by a source object which indicates
Object which fired the event, either a reference or described by an ID (for remote objects). Remark: for symmetry reasons internal and external events have to handle the source object the same way. An ID for internal objects might be an overhead, but to serialize every remote object would be overkill.
Remote computer of which the event originated (or nothing for local computer).
Direction of Event (up / down / local).
Based on client feedback, our target deployment platform is Windows NT. Development occurs on both MacOS and Linux platforms. For the software bus of the PAID system, we will be using Voyager from ObjectSpace. Voyager provides the ability for rapid prototyping and CORBA interaction.
Subsystems are mapped to the existing software/hardware by the Java Virtual Machine and subsequent layers of the operating system.
The query response time goal for the dealer's local PAID database is under 1 second for over 90% of the requests. For any network requests, PAID aims at a maximum response time of one minute, not including time to connect to the network. However, PAID can not guarantee network response time, due to circumstances beyond our control (i.e. heavy network traffic).
Since we have not been provided with sample data and data volumes, we have been unable to determine data transaction volumes.
Depending on server requests the Voyager specific ports might be flooded with network traffic by the network subsystem and therefore by the Voyager software. In this case additional or/and more powerful servers, improved networks are recommended.
The data mining performed by the learning subsystem is processor intensive and may require a separate machine. Depending on system loads, additional resources may be necessary. Without data and data volumes, it is difficult to determine specific hardware requirements.
The data mining performed by the learning subsystem is memory intensive and may require a separate machine. Depending on system loads, additional resources may be necessary. Without data and data volumes, it is difficult to determine specific hardware requirements.
The connectivity between subsystems is done via Voyager based Remote Method Invocations:
The network is based upon TCP/IP which is the standard protocol for the Benz intranet and the internet. This will affect the representation of remote addresses (IP-addresses), security, and the package size. The last two issues will be handled by Voyager.
Events will be sent using the Voyager Event Service. Database data may be multicasted with a possibility to continue transmission if the connection breaks.
Licenses should be distributed which include the addresses of the primary parent server and its uncles. The clients introduce themselves by a valid license.
The Event Service functions as the core of the PAID project. All events generated will be passed through it. All subsystems will communicate with each other by publishing events and by subscribing to events they are interested in. Only the network subsystem will use an API provided by Authentication & Security. This is necessary to ensure all Events that leave a PAID system are signed and encrypted. On the other hand no event that enters a PAID system through the network may reach the Event Service without being decrypted and authenticated.
For every client request and server notification a thread should be started.
The license include the location of parent servers.
If a directed event fails to be sent over the network the event subsystem has to reply with an exception (Event Post Failed). The sender has to decide whether to repost it later or to abort the transmission. A failed general request will be sent to another parent server by the Event System. If all server fail the network has to be down, which is also handled by an exception.
The transfer of database data is done through a continue-able protocol (comparable to ftp). If the connection fails during transfer another parent-server is asked to repost the data beginning at the requested position.
The Event Service was introduced to enhance flexibility & scaleability and to reduce dependencies.
Subsystems can be replaced and enhanced more easily. They just need to publish events needed by the other subsystems and to subscribe to the information they need.
New Subsystems can be added easily. Subsystems like Testing, Logging and the Star Network Server don't need to be present in every PAID system while the code of the remaining keeps the same.
If a method call fails in an unpredicted way the calling subsystem gets into trouble. If a necessary event isn't provided within a given time the subsystem generates a time-out and will in most cases be able to continue its normal operations.
Currently the subspaces are closed due to security. If local authentication is implemented the subspaces can be opened and a PAID server could be distributed to the extend of one computer for each subsystem. Setting up a separate machine for the most resource-hungry subsystem could be an easy and low-cost way to increase performance.
We decided to use Voyager as middleware for different reasons. Voyager provides the necessary functionality we need for the described event service including all discussed future extensions. Voyager is an ORB implemented in Java. If for any reasons necessary it could easily be replaced by another ORB or event service like the ORB provided in Java 2 or the event service provided by Jini.
Since DaimlerChrysler started using Voyager before April 1997 they may use it for free, no license fees need to be paid.
We use Voyager for both the internal event service and the external network communication. The Event Service and the Network subsystems are implemented independently from each other and can be replaced or changed without any cross-reactivity. PAID is designed that any middelware and any third party solution used by one ore more subsystems can be replaced in one subsystem without affecting any other subsystem.