VSS Documentation · VSS Documentation, Release 0.0.1 1.1.4Transparency Transparency Description...

VSS DocumentationRelease 0.0.1

Lukas Martinelli

27.06.2014

Inhaltsverzeichnis

1 Grundlagen 31.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Architekturstile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Sockets 112.1 Mechanismus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Berkeley Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Java Socket API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Multithreaded Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6 TCP/IP vs UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Remote Procedure Call 173.1 Blocking vs Non-Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Synchronous Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Asynchronous Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Messaging 194.1 Message Oriented Middleware (MOM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Enterprise Integration Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Remote Method Invocation (RMI) 275.1 IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 RMI-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3 RMI Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 SOAP Webservices 336.1 Web Services Description Language (WSDL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 SOAP Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.3 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 Non-Functional Requirements (NFRs) 357.1 Performance NFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.2 Performance and Scalability Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.3 Quality Attributes (QAs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Deployment Diagramme 37

i

8.1 UML Deployment Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.2 UML Komponenten Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9 MSDN Deployment Patterns 399.1 Non-Distributed Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399.2 Distributed Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399.3 Web Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409.4 Load-balancing Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419.5 Failover Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

10 Performance Testing 4310.1 Gatling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4310.2 UML Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4310.3 Akzeptanzkriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4310.4 Kapazitätstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4310.5 Performancetest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

11 Scalability 4511.1 Scale Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4511.2 Scale Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

12 Edge Server 47

13 Caching 4913.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

14 Clustered and Managed Topology 51

15 Availability 5315.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5315.2 Possible Downtime per % . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5415.3 Optimale Verfübarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5515.4 Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5515.5 Verfügbarkeit bei verteilten System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

16 Redundanz 5716.1 Cold Standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5716.2 Warm Standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5716.3 Hot Standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5716.4 Single Point of Failure (SPOF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

17 API 5917.1 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5917.2 API Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5917.3 Service Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5917.4 POINT-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

18 Distributed Control Systems 6118.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6118.2 Future Automation System Architecture (FASA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6118.3 Distributed Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6218.4 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

19 System Management 6319.1 FCAPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6319.2 IT Infrastructure Library (ITIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

ii

19.3 Systems Management Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6519.4 Java Management Extensions (JMX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6519.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

20 Indices and tables 67

iii

VSS Documentation, Release 0.0.1

Inhaltsverzeichnis:

Inhaltsverzeichnis 1


2 Inhaltsverzeichnis

KAPITEL 1

Grundlagen

Prüfungsrelevante Themen:

• VSS-Definitionen

• Middleware-Begriff

• Architekturstile

• einfache Web-Programmierung und Java-Netzwerkklassen

1.1 Definitionen

1.1.1 Programm

• Hat einen Anfang und ein Ende

• Akzeptiert Input und produziert Output

• Läuft deterministisch

• Ist clock-driven

1.1.2 System

Besteht aus Programmen und Subsystemen

• Hört evtl. nie auf

• Azeptiert immer Input

• Oft dynamisch konfiguriert

• Kann sich nichtdeterministisch verhalten

• Ist event-driven

1.1.3 Distributed System

A distributed system is a collection of independent computers that appears to its users as a single coherent system.

3


1.1.4 Transparency

Transparency DescriptionAccess Hide differences in data representation and how a resource is accessedLocation Hide where the resource is locatedMigration Hide that the resource may move to another locationRelocation Hide that the resource may be moved to another location while in useReplication Hide that resources is replicatedConcurrency Hide that resource may be sharedFailure Hide failure and recovery

1.1.5 Dimensionen

Verteilte Software Systeme besitzen drei unabhängige Merkmale:

• Nebenläufigkeit

• Verteilung

• Persistenz

1.1.6 Message Passing Interface (MPI)

Eine Alternative zu Sockets speziell für die Kommunikation im High Performance Computing (HPC) Bereich.

4 Kapitel 1. Grundlagen


1.1.7 Message Exchange Pattern (MEP)

Ein Template das die Verbindungsart für den Austausch von Nachrichten festlegt. Beispiele sind:

• Datagram

• Request-Response

• Duplex

Diese können auch alle noch Connection-Oriented sein in dem man eine Session hält.

1.1.8 Abstraktionsebene der Verteilung

Datenaustausch

• Sockets (UDP/TCP über IP)

• File Transfer

• Shared Database

Nachrichtenaustauch

• Message-Oriented Middleware

• HTTP GET, POST

1.1. Definitionen 5


Remote Procedure Call (RPC)

• DCE RPC

• Java RMI, CORBA

• Web Services, RESTful HTTP

1.2 Middleware

Middleware ist infrastrukturelle Software zur Kommunikation zwischen Software-Komponenten und An-wendungen auf verschiedenen Computern

Die Middleware erfüllt folgende Funktionen:

• Dient als Verteilungsplatform die viele Protokolle unterstützt

• Bietet höheres Abstraktionsniveau

• Verbirgt Komplexität darunter

Gründe für eine Einführung:

• Interoperabilität

• Vereinfachung

1.2.1 Communication-oriented middleware

Stellt ein von der Applikation unabhängiges Protokoll zur Verfügung.

• Low-level protocols and API (infrastructure)

• Sockets



1.2.2 Anwendungsorientierte Middleware

Benutzt ein spezifisches Protokoll

• High-level protocols and API (programming models)

• CORBA IDL, RMI interfaces

• WSDL/SOAP Webservices

1.2.3 Multi Channel Architecture (MCA)

1.3 Architekturstile

1.3.1 Distributed Objects

Jedes Objekt ist unabhängig vom Ort und antwortet auf einen Method Call.

1.3.2 N-Layers

Jedes Layer kennt nur das tieferliegende Layer. Ein Request geht durch alle Layers hindurch (Request flow) und wiederzurück (Response flow).

1.3.3 Client-Server

Der Client sendet einen Request auf den Server und bekommt die Antwort.

1.3. Architekturstile 7


1.3.4 2-Tier Architecture

Die Applikationsschichten lassen sich beliebig auf den Server oder Client auslagern. Sowohl Persistenz und die ei-gentliche Business Logik wird vom Server bereitgestelllt, der Client ist lediglich ein Thin Client. Das lässt sich in derPraxis nicht immer so leicht trennen, deshalb gibt es verschiedenste Variationen.

1.3.5 3-Tier Architecture

Tier 1 : Clients mit Browser Tier 2: Web Server und Presentation Logic (z.B. HTML Templates) Application Serverund Business Logic Tier 3: Database

1.3.6 Event Driven Architecture

Reagiert auf Ereignisse.

1.3.7 Peer-to-Peer Systeme

1.3.8 Eight Fallacies of Distributed Systems

Bemerkung: Nicht prüfungsrelevant

The network is reliable

Oft ist mit Netzwerk das Internet gemeint. Wenn ein Zugriff auf eine 3rd Party API gemacht wird, ist die Chancegross, dass dieser Service auch offline gehen kann.

Latency is zero

Server näher zu den Kunden bringen (mit Cloud Availability Zones und CDNs).



Bandwidth is infinite

Die meisten Mobilgeräte haben keine unlimitierte Bandbreite.

The network is secure

TLS

Topology doesn’t change

There is one administrator

Even with applications hosted in your own private datacenter, your applications are likely interacting with systemsoutside your administrative control.

Transport cost is zero

Not only is transport cost not zero, it’s priced.

1.3. Architekturstile 9

KAPITEL 2

Sockets

Socket Programmierung ist im Grunde Low-Level Messaging und ist der Basis Mechanismus für verteilte Aufrufe.

Es wird kein Programmierkomfort geboten, es werden lediglich Byteströme auf Programmierebene ausgetauscht.

2.1 Mechanismus

Ein Socket ist eine eindeutige Verbindung zwischen eine Client (IP + Port) und einem Server (IP + Port).

Vorsicht: Typische Fehler:• Mit einem Port zu verbinden, für den kein BIND und LISTEN ausgeführt wurde• BIND auf Port machen, der bereits belegt ist• Protocol Mismatches (Format stimmt nicht überein, Buffer überläuft)

2.1.1 Client

Client kennt Hostname und Port für den CONNECT mit dem Server:

1. stellt eine Verbindung her

2. erhält Socket Objekt

3. kommuniziert mit Methoden des Socket Objekts

11


2.1.2 Server

Server kennt eigenen Port und ist im LISTEN Modus:

1. Wartet bis Client über den Connect Port verbindet

2. akzeptiert Request

3. erzeugt für jeden Request einen neuen Socket (neuer Port) um auf den Request zu antworten

4. Ursprünglicher Connect Sockets ist bereit für weitere Requests

12 Kapitel 2. Sockets


2.2 Nachteile

• Byteströme müssen erstellt und geparst werden

• Messaging Format muss selbst spezifiziert und implementiert werden

• Viele fehlende Features die heute Middleware übernimmt (z.B. Synchronization)

2.3 Berkeley Sockets

Funktioniert platformübergreifend für alle Sprachen gleich.

Primitive MeaningSOCKET Create new communication end pointBIND Attach a local address to a socketLISTEN Announce willingness to accept connectionsACCEPT Block caller until connection request arrivesCONNECT Actively attempt to establish connectionSEND Send data over connectionRECEIVE Receive data over connectionCLOSE Release the connection

2.3.1 Message Exchange Pattern (MEP) nicht garantiert

Weder die Socket API noch MPI legen das Message Exchange Pattern fest. Dies muss in der Applikation festgelegtwerden und muss behandeln können:

• Wer schreibt wann?

• Wie geht man mit Buffer Overflows um?

• Wie wird zwischen Client und Server synchronisiert?

2.4 Java Socket API

Die Klasse Socket in Java benutzt standardmässig einen TCP/IP Socket.

2.4.1 Server

Beispiel für einen Single-Threaded Server, welcher die aktuelle Zeit liefert

2.2. Nachteile 13


public class TimeServer {public static void main(String args[]) throws Exception {

int port = 2342;ServerSocket server = new ServerSocket(port);while(true) {

Socket client = server.accept();try(PrintWriter out = new PrintWriter(client.getOutputStream(), true)) {

Date date = new Date();out.println(date);

}}

}}

Der Konstruktor des ServerSockets macht implizit einen BIND und LISTEN wenn ihm ein Port übergeben wurde.Mit dem server.accept Call warten wir bis ein Client eine Verbindung eröffnet, um dann einen neuen Socket client zueröffnen auf dem wir ihm daten zurücksenden können.

2.4.2 Client

Beispiel für den Client der die Zeit vom Server holt

public class TimeClient {public static void main(String args[]) throws IOException {

String host = "localhost";int port = 2342;

Socket server = new Socket(host, port);try(BufferedReader in = new BufferedReader(new InputStreamReader(server.getInputStream))) {

String date = in.readLine();}

}

Der Client macht lediglich einen CONNECT und schreibt auf den Socket.

2.4.3 Berkeley Socket Pattern

Der Konstruktor in der Java Socket API macht vieles implizit (zum Beispiel den CONNECT oder BIND). Es wärebesser die Berkely Sockets nicht zu abstrahieren sondern direkt explizit connect() und listen() Methoden zu verwenden.

2.4.4 UDP und Multicast

• DatagramSocket für UDP

• MulticastSocket für Multicasts mit UDP

2.5 Multithreaded Server

2.6 TCP/IP vs UDP/IP

• Connection-Oriented vs Connection-Less



• QoS Unterschiede

– Sequencing: Wird die Paketreihenfolge sichergestellt?

– Packet loss: Werden Pakete erneut übertragen?

• Broadcast und Multicast möglich

Bemerkung: Can one program listen to and accept connections on multiple ports?

Bemerkung: How can multiple clients connect to the same server without blocking the port?

2.6. TCP/IP vs UDP/IP 15

KAPITEL 3

Remote Procedure Call

Es gibt zwei Designdimensionen:

lokaler Aufruf: Kommunikation mit nächsttieferer lokaler Schicht

** remote Aufruf:** Kommunikation mit derselben Schicht auf entferntem Rechner

3.1 Blocking vs Non-Blocking

Blockiert ein Programm (beispielsweise der accept() Call beim Java Socket API) so muss dies unbedingt dokumentiertwerden.

Bringt ausserdem viele Fehlermöglichkeiten mit sich. Bei blockierenden Methoden deshalb immer ein Timeout setzen.

Blocking API Call Ja SituationsbedingtNon-blocking API Call Selten Ja

3.2 Synchronous Remote Procedure Call

3.3 Asynchronous Remote Procedure Call

17


18 Kapitel 3. Remote Procedure Call

KAPITEL 4

Messaging

Queue-basiertes Messaging gestattet die flexible und lose Kopplung unterschiedlichster Systeme:

• Auf unterschiedlichen Plattformen

• In unterschiedlichen Programmiersprachen

• Mit völlig unterschiedlichen Message-Formaten (Text, Byte, Objekt).

Messaging wird heute vielfach als einfacherer Ansatz für die Integration unterschiedlicher Systeme eingesetzt mit denMerkmalen:

• Einfachheit

• Lose Kopplung

• Erweiterbarkeit

• Skalierbarkeit

• Fehlertoleranz

Die APIs sind einfach zu benutzen, es müssen aber viele Designentscheidungen getroffen werden:

• Message intent (command vs. data)

• Returning a response (request-reply)

• Huge amounts of data (sequencing)

• Slow messages (message expiration)

• QoS (guaranteed delivery, transactionality, idempotency)

19


4.1 Message Oriented Middleware (MOM)

4.1.1 Message Queing Model

Mit dem Message-Queuing Model enkoppelt man den Empfänger von der Zeitdimension. Er kann selbst wählen, wieer die Nachricht empfangen will.

Der Sender kann auch eine lokale Queue verwenden um beispielsweise momentane Übertragungsprobleme auszuglei-chen oder inkommende Nachrichten zu puffern.

20 Kapitel 4. Messaging


4.1. Message Oriented Middleware (MOM) 21


4.1.2 Architekturen

Pipes-and-Filter Chaining

Hub-and-Spoke Architecture

4.1.3 API Primitives

JMS eine Message Oriented Middleware (MOM) API um Nachrichten auszutauschen. Java EE bring von Haus auseine JMS Implementation mit. Externe JMS Provider implementieren lediglich das JMS Interface.



Einige Provider Implementationen: * Apache ActiveMQ * Redis * JBoss * RabbitMQ * WebSphere MQ

4.1.4 Terminologie

Client

An application or process that produces and/or receives messages.

Producer/Publisher

A JMS client that creates and sends messages.

Consumer/Subscriber

A JMS client that receives messages.

Message

An object that contains the data being transferred between JMS clients.

Queue

A staging area that contains messages that have been sent and are waiting to be read (by only one consumer). Notethat, contrary to what the name queue suggests, messages don’t have to be delivered in the order sent. A JMS queueonly guarantees that each message is processed only once.

Topic

A distribution mechanism for publishing messages that are delivered to multiple subscribers.

4.1.5 Channel Types

Point-to-Point Channel

How can the caller be sure that exactly one receiver will receive the document or perform the call?

Messages werden zu einem spezifischen Consumer gerouted, der eine Queue für die Messages verwaltet. Jede Messagegeht an eine spezifische Queue.

Publish-Subscribe Channel

How can the sender broadcast an event to all interested receivers?

Messages werden an ein spezielles Topic gesendet. Subscriber können alle Messages zu einem Topic abonnieren. DerPublisher muss die Consumer nicht kennen.

4.1. Message Oriented Middleware (MOM) 23


4.1.6 Quality of Service (QoS) Settings

Attribute DescriptionTransport Type Transport Protokoll für die ÜbertragungFIFO delivery Messages werden in der Reihenfolge zugestellt, in der sie gesendet wurdenMessage length Maximale Länge einer NachrichtSetup retry count Maximale Anzahl Versuche um die Remote Queue zu erreichenDelivery retries Maximale Anzahl Versuche um eine Nachricht in die Queue zu speichern

4.1.7 Persistenz

Nicht-Persistent

• Vorteil dieses Modus ist der geringe Overhead.

• Die Nachrichten werden nicht gelogged oder gespeichert.

• Falls ein JMS Provider ausfällt, kann eine solche Meldung verloren gehen.

Persistent

• Instruiert den JMS Provider, dass dieser sich darum kümmern muss, dass die Nachrichten nicht verloren gehen.

• Der JMS Provider muss solche Nachrichten auch garantiert maximal einmal abliefern.

• Eine Nachricht kann also verloren gehen, darf dann aber garantiert nur einmal abgeliefert werden.

• Ein JMS Provider muss eine PERSISTENT Message einmal-und-nur-einmal abliefern. Dadurch wird die Per-formance verschlechtert.

4.1.8 Message-Struktur

Header

Er enthält Informationen für das Routing und die Identifikation oder auch QoS Settings. Ein MOM-Provider normiertseine Message Header.

Properties (optional)

Informationen, mit deren Hilfe ein Consumer Nachrichten filtern oder weiterrouten kann (Erweiterungen des Standard-Headers).

Body

Enthält die auszutauschenden Nutzdaten (Text, Objekte, Binärdaten).



4.1.9 Ablauf

• Create – the sender creates the message and populates it with data.

• Send – the sender adds the message to a channel.

• Deliver – the messaging system moves the message from the sender’s computer to the receiver’s computer,making it available to the receiver.

• Receive – the receiver reads the message from the channel.

• Process – the receiver extracts the data from the message.

4.2 Enterprise Integration Patterns

4.2.1 Polling Consumer

Blocking Receive-Call (optionaler Timeout)

4.2.2 Event-driven Consumer

Request Handler Pattern

4.2. Enterprise Integration Patterns 25


4.2.3 Guaranteed Delivery Pattern

4.3 RabbitMQ

TODO


KAPITEL 5

Remote Method Invocation (RMI)

5.1 IDL

IDL-Begriff, IDL-Beispiele, IDL-Prozess

Recurring Design Issues in Remoting: * Wire protocol * Naming/addressing of endpoints * Message Exchange Pattern(MEP) on application level * Request-Reply, One-Way, Long Polling, ... * Data formatting (requests, replies) a.k.a.parameter syntax * QoS policies:

Um diese Probleme in den Griff zu kriegen, wird ein Vertrag/Interface benötigt, der diese Aspekte definiert.

5.1.1 Service Contract vs. Service Implementation

TODO:

5.2 RMI-Architektur

Wird eine Methode auf einem Objekt aufgerufen, wird ein synchroner Aufruf vom Client an den Server gemacht. DerAnwendungsentwickler auf der Client-Seite bleibt der Remote Aufruf verborgen (Proxy Pattern).

27


5.2.1 RMI-Registry

Remote Objekte können auch referenziert werden, dies muss speziell über einen Namensdienst (RMI-Registry) ge-handhabt werden. Diese RMI-Registry wird von der RMI-Referenzschicht zur Verfügung gestellt. RMI stellt ebenfallseinen Mechanismus bereit um ein Remote Object, dass als Parameter an ein anderes Remote Object übergeben wurde,dynamisch nachzuladen.

28 Kapitel 5. Remote Method Invocation (RMI)


5.2.2 RMI-Compiler

All die Stubs und Skeletons von Hand anzulegen wäre eine zu grosse Handarbeit. Deshalb wird RMI-IDL (als InterfaceSprache) benutzt. Mithilfe des RMI-Compiler kann man dann vom RMI-IDL automatisch Proxies und Stubs erzeugen.

In neuen Java Versionen kann dies auch dynamisch zur Laufzeit mithilfe von Introspection passieren.

5.2.3 Stub

Ein Stub ist ein Stellvertreterobjekt (Remote Proxy), das Clientaufruf an Server weiterreicht.

Die Stub-Klasse baut Socket-Verbindung zu Server auf (CONNECT). Sie schickt Namen der Methode und Parameterund holt das Ergebnis ab.

5.2.4 Skeleton

Ein Skeleton nimmt Aufrufe des Stubs entgegen und leitet sie an Serverobjekt weiter.

Erzeugt Socket auf demselben Port wie Stub (BIND/LISTEN/ACCEPT), wartet auf den Methoden-aufruf vom clientund delegiert diesen an das Objekt. Der Rückgabewert wird dann über die Socketverbindung an Client zurück gesendet.

5.2.5 Deployment

Die RMI-Registry wurde sowohl vom Client, als auch vom Server verwendet. Um diese bereitzustellen, wird einInfrastruktur Server benötigt.

Wer started die RMI-Registry?

Die RMI-Registry muss separat auf dem Infrastruktur Server gestartet und verwaltet werden.

5.2.6 Kritik

• Es ist nicht immer klar, dass es sich um Remote Zugriffe handelt (Timeout Management)

• Client und Server sind stark gekoppelt (Objekt Serialisierung ist starker Vertrag)

• Binäres Protokoll (Kompabilität benötigt, gleiche Java Version auf Client und Server)

• Referenzen müssen gemanagt werden (Remote Garbage collection)

• Wird oft von der Firewall geblocket, da es sich um ein eigenes Protokoll handelt.

5.3 RMI Beispiel

Es muss ein Interface für die Remote-Methoden erstellt werden, dass sowohl dem Client, als auch dem Server bekanntist

import java.rmi.Remote;import java.rmi.RemoteException;public interface Hello extends Remote {

String sayHello() throws RemoteException;}

5.3. RMI Beispiel 29


Der Server implementiert nun dieses Interface

import java.rmi.RemoteException;import java.rmi.server.UnicastRemoteObject;public class HelloImpl extends UnicastRemoteObject implements Hello{

public HelloImpl() throws RemoteException {super();

}public String sayHello() throws RemoteException {

return "Hello World!";}

}

Nun muss ein Remote Object der Implementierung erzeugt und bei der RMI-Registry angemeldet werden.

import java.rmi.Naming;public class HelloServer {

public static void main(String args[]) {try {

HelloImpl obj = new HelloImpl();Naming.rebind("rmi://[hn]/remoteHello", obj);

} catch (Exception e) { ... }}

}

Zuerst muss das Remote Object von der RMI-Registry abgeholt werden. Danach können wir auf dem Interface alledefinierten Methoden aufrufen

import java.rmi.*;public class RmiClient {

public static void main(String[] args) {try {

Hello obj =(Hello)Naming.lookup("rmi://[hn]/remoteHello");String message = obj.sayHello();System.out.println(message);

} catch (Exception e) { ... }}

}

5.3.1 Call-by-Value

Es werden Kopien der Objekte zwischen Client und Server verschickt, dazu müssen die Parameter-Klassen serialisier-bar sein.

• Vorteil: sie Anzahl der remote Zugriffe ist reduziert

• Nachteil: Änderungen von entfernten Objekten sind so nicht möglich

5.3.2 Call-by-Reference

Referenz auf das Parameter-Objekt wird an den Server übertragen, dazu muss die Parameter-Klasse ebenfalls einRMI-Object sein (sie muss also ein Remote-Interface haben und von UnicastRemoteObject ableiten).

• Vorteil: Server kann übergebene Client-Objekte auf Client ändern

• Nachteil: Remote-Zugriffe sind teuer



5.3.3 Objekt Serialisierung

Um die Java Objekte zu übertragen, müssen sie zuerst serialisiert werden. Bei der Serialisierung werden die Objektein einen flachen, geordneten Bytestream geschrieben.

Um in Java ein Klasse serialisierbar zu machen, muss das Objekt mit dem Marker Interface java.io.Serializable aus-gezeichnet werden

public class Person implements Serializable {private static final long serialVersionUID = 1L;private String name;private String place;private int year;Person(String aName, String aPlace, int aYear) {

name = aName;place = aPlace;year = aYear;

}}

Die serialVersionUID ist die Versionsnummer einer Klasse. Wird ein Objekt deserialisiert, werden die serialVersio-nUID des Codes und des Objekts verglichen. Stimmen diese nicht überein wird eine InvalidClassException auftreten.

5.3. RMI Beispiel 31

KAPITEL 6

SOAP Webservices

Basiert auf den Grundsätzen von RPC.

Web Services, SOAP, WSDL; Apache Tomcat

6.1 Web Services Description Language (WSDL)

WSDL ist ein XML Format mit dem RPC beschrieben werden können. Es handelt sich also eigentlich um eine IDL inXML.

WSDL schreibt man heutzutage nicht mehr von Hand, sondern wird mit Contract Generation automatisch generiert(wsimport für Java oder svcutil für .NET).

Diese Tools können auch direkt Proxies, Skeletons und Stubs für ein Schema generieren.

33


6.1.1 Terminologie

• Service

• Endpoint

• Binding

• Interface

• Operation

• Types

6.1.2 Serialization

Interoperabilität ist nicht gewährleistet. Ein .NET Client kann zum Beispiel keine Java HashMap deserialisieren.

Es können verschiedene Implementation für die Serialiserung in Java benutzt werden:

• JAXB Implementation: In der JDK integriert

• 3rd Party Java-to-XML Mapper

– Castor

– OX

6.1.3 Kritik

• XML ist sehr verbose und deshalb nicht so gut lesbar

• WSDL ist eine komplexe Sprache mit einer hohen Lernkurve

• XML und XSD komplex

Tools können viele dieser Pain Points abnehmen.

6.2 SOAP Envelope

<?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header><m:Trans xmlns:m="http://www.w3schools.com/transaction/"soap:mustUnderstand="1">234</m:Trans>

</soap:Header><soap:Body>

<m:GetPrice xmlns:m="http://www.w3schools.com/prices"><m:Item>Apples</m:Item>

</m:GetPrice></soap:Body>

</soap:Envelope>

6.3 Apache Tomcat

34 Kapitel 6. SOAP Webservices

KAPITEL 7

Non-Functional Requirements (NFRs)

• Availability

• Compliance

• Maintainability

• Performance

• Response time, latency; throughput

• A.k.a. completion time, service time, ...

• Privacy

• Recovery

• Resilience, Fault Tolerance, Robustness

• Scalability

• Throughput

• Usability, User-Friendliness

7.1 Performance NFR

Gefahr: TODO

7.2 Performance and Scalability Tactics

• Optimize repeated processing

• Reduce contention via replication

• Prioritize processing

• Consolidate related workload

• Distribute processing over time

• Minimize the use of shared resources

• Reuse resources and results

35


• Partition and parallelize

• Scale up or scale out

• Degrade gracefully

• Use asynchronous processing

• Relax transactional consistency

• Make design compromises

Gefahr: TODO

7.3 Quality Attributes (QAs)

• QA Accuracy: orders must not be lost, resource reservations must be undone

• QA Efficiency (performance): sub-second response times specified

• QA Interoperability: multiple platforms to be supported

• QA Modifiability: skills for selected technologies must be available locally

36 Kapitel 7. Non-Functional Requirements (NFRs)

KAPITEL 8

Deployment Diagramme

8.1 UML Deployment Diagramm

Hardware, Prozessoren und Runtimes (z.B. JVM) werden als Nodes dargestellt.

Artefakte werden Nodes zugewiesen um den Deployment Status des Systems zu modellieren.

8.2 UML Komponenten Diagramm

37


38 Kapitel 8. Deployment Diagramme

KAPITEL 9

MSDN Deployment Patterns

9.1 Non-Distributed Deployment

9.2 Distributed Deployment

39


9.3 Web Farms

40 Kapitel 9. MSDN Deployment Patterns


9.4 Load-balancing Cluster

9.4. Load-balancing Cluster 41


9.5 Failover Cluster

42 Kapitel 9. MSDN Deployment Patterns

KAPITEL 10

Performance Testing

10.1 Gatling

Gatling ist eine Load Testing Software mit der man Benutzungsszenarien spezifizieren und deren Ausführungszeitmessen kann. Um Szenarien zu modellieren eignen sich UML Aktivitätsdiagramme gut.

In einer realen Testumgebung kann es gut sein, dass von einem einzelnen Load Generator nicht genügend Usersessionssimuliert werden können, um den zu testenden Server voll auszulasten.

10.2 UML Aktivitätsdiagramm

10.3 Akzeptanzkriterien

Es empfiehlt sich in jedem Fall für eine Applikation Akzeptanzkriterien zu definieren. Die dabei gewählten Metrikenmüssen spezifisch, messbar und realistisch sein.

Beispiele für Akzeptanzkriterien:

Nr Kriterium MetrikK1 Die Webseite soll flüssig bedienbar sein. 95% aller Requests sollen in weniger als

500ms beantwortet werden.Response Timein ms

K2 Das erstellen eines Tweets darf in 95% der Fälle nicht länger als 2s dauern Response Timein ms

K3 99.9% der Requests müssen ohne Fehler durch den Server beantwortet werden können. no_errors /no_total

10.4 Kapazitätstest

Performance sollten an der Kapazitätsgrenze durchgeführt werden. Deshalb muss zuerst evaluiert werden, wievieleBenutzer ein System zur gleichen Zeit benutzen können. Die Kapazitätsgrenze findet man heraus, indem man dieAnzahl User hochschraubt, ohne das man die Akzeptanzkriterien verletzt.

Diese Kapazitätsgrenze kann nun als Baseline für Performance Tests genommen werden.

43


10.5 Performancetest

Man kann nun versuchen Performancesteigerung durchzuführen und dann nochmals den Performancetest laufen lässt.Diesen kann man nun mit der Baseline vergleichen.

44 Kapitel 10. Performance Testing

KAPITEL 11

Scalability

Scalability ist die Fähigkeit:

• mit steigender Belastung umzugehen

• ohne die SLAs zu verletzen

• indem die Anzahl Ressourcen erhöht wird

Grundsätzlich gibt es drei verschiedene Ansätze:

Work harder Mehr Power um die Arbeit zu erledigen

Work smarter Besser Algorithmen verwenden

Get help Parallelismus einführen

11.1 Scale Up

Underlying resources that are increased are mainly the resources (CPUs, storage, bandwidth,...) of an individual server.

11.2 Scale Out

Underlying resources that are increased are mainly additionally complete servers.

45


46 Kapitel 11. Scalability

KAPITEL 12

Edge Server

Ein Edge Server (Load Balancer) hat eine einzige IP Adresse und verteilt Requests an mehrere andere IP Adressen.

Typische Verteilungsmechanismen:

Round robin Abwechslungsweise die Last verteilen

Last-recently-used Führt zu guter Lastverteilung

Workload-based Aufrund von Monitoring Ergebnissen die Auslastung abschätzen und dementsprechend verteilen.

47


48 Kapitel 12. Edge Server

KAPITEL 13

Caching

Ein Cache ist ein schneller Assoziativspeicher (Hardware, Operating System, Middleware), typischerweise als Zwi-schenspeicher genutzt.

Caching sollte vorsichtig verwendet werden, den es führt zu vielen neuen Problemen.

There are only two hard things in Computer Science: cache invalidation and naming things.

—Phil Karlton

13.1 HTTP

HTTP bringt von Haus aus gute Cachingmöglichkeiten mit. Einfaches HTTP Caching kann schon mit einem WebProxy / Reverse Proxy durchgeführt werden.

49


50 Kapitel 13. Caching

KAPITEL 14

Clustered and Managed Topology

51


52 Kapitel 14. Clustered and Managed Topology

KAPITEL 15

Availability

15.1 Definition

Ein System gilt als verfügbar wenn es läuft und korrekte Resultate produziert. Hohe Verfügbarkeit ist, wenn dieVerfügbarkeit nahe bei 100% ist.

Wir können also folgende Schlussfolgerungen ziehen:

• Je mehr Fehler ein System hat, desto weniger ist es verfübar

• Je länger es dauert um eine System zu reparieren, desto weniger ist es verfügbar

Verfügbarkeit = MTBF / (MTBF + MTTR)

53


15.1.1 Mean Time Between Failure (MTBF)

Die Durchschnittszeit bevor ein System fehlschlägt. MTBF misst also die Zuverlässigkeit.

15.1.2 Mean Time To Repair (MTTR)

Die Durchschnittszeit um ein System zu reparieren. Entspricht der Downtime.

15.2 Possible Downtime per %

Availability % Downtime per year90% 36.5 days95% 18.25 days98% 7.3 days99% 3.65 days99.5 1.83 days99.9 8.76 hours99.99 52.56 minutes99.999 5.26 minutes

54 Kapitel 15. Availability


15.3 Optimale Verfübarkeit

15.4 Tactics

• Select fault-tolerant hardware

• Use high-availability clustering and load balancing

• Log transactions

• Apply software availability solutions

• Select or create fault-tolerant software

• Design for failure

• Allow for component replication

• Relax transactional consistency

• Identify backup and disaster recovery solutions

15.5 Verfügbarkeit bei verteilten System

Wenn mehrere Systeme voneinander abhängen, ist die gesamte Verfügbarkeit das Produkt der Verfübarkeit der Syste-me.

Bei der Verfügbarkeit ist also das schwächste Glied der Kette wichtig.

15.3. Optimale Verfübarkeit 55


56 Kapitel 15. Availability

KAPITEL 16

Redundanz

16.1 Cold Standby

A cold server is a backup server whose purpose is solely to be there in case the main server is lost. The cold server isbasically turned on once to have software installed and configured, and then is turned off until needed.

16.2 Warm Standby

A warm server is a backup server that is turned on periodically to receive updates from the server being backed up.Warm servers are often used for replication and mirroring.

16.3 Hot Standby

A hot server is a backup server that receives regular updates and is standing by ready (on hot standby) to take overimmediately in the event of a failover.

16.4 Single Point of Failure (SPOF)

Potentielle SPOFs:

Active Directory Server Schlägt die Authentisierung / Autorisierung fehl läuft meistens gar nichts mehr

Externe Komponenten Zum Beispiel der Shipping Scheduler der nicht so oft gebraucht wird und deshalb nichtredundant ausgelegt ist

Garbage Collector Läuft der GC nicht mehr, wird das Programm irgendwann abstürzen.

57


58 Kapitel 16. Redundanz

KAPITEL 17

API

17.1 Maintainability

Wartbarkeit ist die Eigenschaft leicht verändert werden zu können. Man will zum Beispiel etwas korrigieren oderverbessern, an eine neue Komponente oder an ein System anpassen.

Remote APIs unterscheiden sich von lokalen APIs in der Wartbarkeit.

17.2 API Requirements

• Low latency

• High throughput

• Robustness

• Error handling

• Multi tenancy (dt. Mandantenfähigkeit) and API security

• User session stickiness and data privacy

• Extensibility and flexibility (a.k.a. evolvability)

• Backward compatibility

17.3 Service Design Patterns

17.3.1 Service Layer Pattern

Die Komplexität eines Systems muss nach aussenhin verborgen sein. Man möchte keine primitiven Operationen undkomplexe Modelle bereitstellen, stattdessen sollte eine ausgewählte Menge Operationen, die alle wichtigen Handlun-gen umfassen.

If in doubt, leave it out!

59


17.3.2 Remote Facade

17.3.3 Data Transfer Object (DTO)

17.4 POINT-Test

An API should get (and stick) to its POINT P

an API must be purposeful (e.g., driven by client demand/use cases)

O an API should expose domain objects (e.g., resources or services) and adhere to OO principles such as high cohe-sion/low coupling

I each API call should be as isolated as possible (i.e., free of side unexpected, undesired effects)

N an API should be neutral, i.e. not optimized for any particular client channel

T an API should be “t-shaped” (i.e., offer broad and deep calls), e.g., provide a master-detail interface and/or searchfunctionality

60 Kapitel 17. API

KAPITEL 18

Distributed Control Systems

18.1 Definition

A real-time system is one that must process information and produce a response within a specified time, else risksevere consequences, including failure. That is, in a system with a real-time constraint it is no good to have the correctaction or the correct answer after a certain deadline: it is either by the deadline or it is useless!

System must react to stimulus within given deadlines

• Determinism vs. performance

• Worst-case vs. average-case execution time (Car airbag (60-80 milliseconds)

18.2 Future Automation System Architecture (FASA)

• Is a real-time middleware

• Is based on components

• Provides platform abstraction

• Is a deterministic, linear execution framework

• Supports any number of CPU and cores

61


18.2.1 More Details

• Separates components in memory

• Spans across cores and systems

• Provides distributed execution

• Enables software-based fault tolerance

• Allows for dynamic software updates

18.3 Distributed Scheduling

Accommodating concurrent tasks on the available resources.

• Static schedule

• Based on Worst-Case Execution Time (WCET)

• Tasks are scheduled in a fixed order

18.4 Fault Tolerance

TODO

62 Kapitel 18. Distributed Control Systems

KAPITEL 19

System Management

19.1 FCAPS

Fault This involves the detection, isolation, and correction of a fault condition. Or in plain english, this lets you knowwhen things are broken.

Configuration This involves the configuration of the software and hardware in the network. This includes the versionsof software, the actual configurations, change management, etc. . .

Accounting This involves the identification of cost to the service provider and payment due for the customer. Ie:Billing.

Performance This involves evaluating and reporting on the effectiveness of the network, and individual networkdevices.

Security Security is. . . well security. These are the network management activites that involve securing the networkand the data running over it.

63


19.2 IT Infrastructure Library (ITIL)

ITIL ist eine Sammlung von Best Practices

64 Kapitel 19. System Management


19.3 Systems Management Patterns

19.3.1 Wire Tap

19.3.2 Message History

19.4 Java Management Extensions (JMX)

19.5 Logging

Issues:

• The logging solution should be easy for a developer to use, reusable across different applications, and extensibleto meet new needs.

• Logging should be centralized to a single point to allow an administrator to access it from one place.

• Logging should have little affect on application performance.

• The logging solution should filter messages, via configuration, by type to enable specific events to be triggered.These include things like persisting the message and performing alert notification, such as paging an adminis-trator.

• The logging environment should allow for centralized and local logging by identifying different types.”

19.3. Systems Management Patterns 65


66 Kapitel 19. System Management

KAPITEL 20

Indices and tables

• genindex

• search

67

VSS Documentation · VSS Documentation, Release 0.0.1 1.1.4Transparency Transparency Description...

Documents

Transcript of VSS Documentation · VSS Documentation, Release 0.0.1 1.1.4Transparency Transparency Description...