Verteilte Software Systeme Hochschule für Technik Rapperswil Lukas Martinelli 25.08.2014, basierend auf Zusammenfassung Marc Juchli

Grundlagen Definitionen Programm ● ● ● ●

Hat einen Anfang und ein Ende  Akzeptiert Input und produziert Output  Läuft deterministisch  Ist clock­driven 

System Besteht aus Programmen und Subsystemen  ● Hört evtl. nie auf  ● Akzeptiert immer Input  ● Oft dynamisch konfiguriert  ● Kann sich nichtdeterministisch verhalten  ● Ist event­driven 

Distributed System A distributed system is a collection of independent computers that appears to its users as a single  coherent system.  What is the opposite of distribution? Non​ distributed systems: Presentation tier and middle tier of the application run in the same server.  So the business components can be accessed locally without remote calls; this will improve  significant performance of the overall application. However it is vital that presentation tier and middle  tier are kept logically distinct. The main risk in the web application is that blurred responsibilities  between presentation and business logic components. 

Dimensionen Verteilte Software Systeme besitzen drei unabhängige  Merkmale:  ● Nebenläufigkeit  ● Verteilung  ● Persistenz   

Transparency   Transparency 

Description 

Access 

Hide differences in data representation and how a resource is  accessed  1 

Location 

Hide where the resource is located 

Migration 

Hide that the resource may move to another location 

Relocation 

Hide that the resource may be moved to another location while in  use 

Replication 

Hide that resources is replicated 

Concurrency 

Hide that resource may be shared 

Failure 

Hide failure and recovery 

 

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

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.     

2 

 

Abstraktionsebene Datenaustausch ● ● ●

Sockets (UDP/TCP über IP)  File Transfer  Shared Database 

   

Nachrichtenaustauch ● ●

Message­Oriented Middleware  HTTP GET, POST 

     

Remote Procedure Call (RPC) ● ● ●

DCE RPC  Java RMI, CORBA  Web Services, RESTful HTTP 

     

Middleware Middleware ist Infrastruktur­Software zur Kommunikation zwischen Software­Komponenten und  Anwendungen auf verschiedenen Computern    Die Middleware erfüllt folgende Funktionen:  ● Dient als Verteilungsplattform die viele Protokolle unterstützt  ● Bietet höheres Abstraktionsniveau als einfacher Datenaustausch  ● Verbirgt Komplexität darunter    Gründe für eine Einführung:  ● Interoperabilität (Überwindung von Heterogenität)  ● vereinfachte Erstellung verteilter Anwendungen (Produktivität)       

3 

Kommunikationsorientierte Middleware Stellt ein von der Applikation unabhängiges  Protokoll zur Verfügung.  ● Low­level protocols and API  (infrastructure)  ● Sockets 

Anwendungsorientierte Middleware Benutzt ein spezifisches Protokoll  ● High­level protocols and API  (programming models)  ● CORBA IDL, RMI interfaces  ● WSDL/SOAP Webservices       

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

 

2-Tier Architecture Die Applikationschichten lassen sich beliebig auf den Server oder Client auslagern. Sowohl  Persistenz und die eigentliche Business Logik wird vom Server bereitgestellt, der Client ist lediglich  ein Thin Client. Das lässt sich in der Praxis nicht immer so leicht trennen, deshalb gibt es  verschiedenste Variationen. 

 

4 

3-Tier Architecture Tier 1: Clients mit Browser oder Desktop Applikation (Rich Client)  Tier 2: Web Server, Presentation Logic (z.B. HTML Templates), Application Server und Business  Logic  Tier 3: Database 

 

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

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

Event Driven Architecture Reagiert auf Ereignisse.  Peer-to-Peer Systeme  

Eight Fallacies of Distributed Systems The network is reliable Oft ist mit Netzwerk das Internet gemeint. Wenn ein Zugriff auf eine 3rd Party API gemacht wird, ist  die Chance gross, 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 Nutzer surfen im offenen WLAN. TLS wird oft implizit voraussgesetzt. 

5 

Topology doesn’t change Topology ist oft nicht statisch, IPs können ändern. 

There is one administrator Even with applications hosted in your own private datacenter, your applications are likely interacting  with systems outside your administrative control. 

Transport cost is zero Not only is transport cost not zero, it’s priced (see AWS).   

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.   

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

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   

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 

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) 

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) 

  6 

Message Exchange Pattern (MEP) nicht garantiert Weder die Socket API noch MPI legen das Message Exchange Pattern fest. Dies muss in der  Applikation festgelegt werden und muss behandeln können:  ● Wer schreibt wann?  ● Wie geht man mit Buffer Overflows um?  ● Wie wird zwischen Client und Server synchronisiert?       

7 

Berkeley Sockets Funktioniert plattformübergreifend für alle Sprachen gleich.   

   

     

Primitive 

Meaning 

SOCKET 

Create new communication end point 

BIND 

Attach a local address to a socket 

LISTEN 

Announce willingness to accept connections 

ACCEPT 

Block caller until connection request arrives 

CONNECT 

Actively attempt to establish connection 

SEND 

Send data over connection 

RECEIVE 

Receive data over connection 

CLOSE 

Release the connection 

 

8 

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

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

  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 zu eröffnen auf dem wir ihm Daten zurücksenden können.   

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.   

Unterschied von Socket und ServerSocket java.net.ServerSocket:  This class implements server sockets. A server socket waits for requests to come in  over the network. It performs some operation based on that request, and then possibly  returns a result to the requester.  java.net.Socket:  This class implements client sockets (also called just "sockets"). A socket is an endpoint  for communication between two machines    9 

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

Listen and accept on multiple ports For each port that you want to listen to:  1. Create a separate socket with socket.  2. Bind it to the appropriate port with bind.  3. Call listen on the socket so that it's set up with a listen queue. 

Multiple connections to server without blocking the port Da ein Socket ein Quadrupel von Client (IP + Port) und Server (IP + Port) ist, erstellt accept für jede  TCP Connection einen neuen Socket. Da das unterschiedliche Sockets sind, blockieren sie sich  auch nicht.    netstat für zwei verbundene Clients zeigt Folgendes an:  ● two inbound connections, belonging to the server (local port:1234). Each has its own Socket  in the server application.  ● two outbound connections, belonging to the client (remote port:1234). Each has its own  Socket in the client application.  ● one listening connection, belonging to the server. This corresponds to the single  ServerSocketthat accepts connections.     

   

UDP und Multicast ● ●

DatagramSocket für UDP (Adresse muss bei jedem Paket angegeben werden)  MulticastSocket für Multicasts mit UDP 

 

  10 

Multithreaded Server Hier wird für das obige Beispiel für jeden neuen Socket, ein eigener Thread eröffnet.    public static void main(String args[]) throws Exception { ServerSocket server = new ServerSocket(1234); while(true) { Socket client; = server.accept(); ServerThread t = new ServerThread(s); t.start(); } } public class ServerThread extends Thread { private Socket client; public ServerThread(Socket client) { this.client = client; } public void run() { try(PrintWriter out = new PrintWriter(client.getOutputStream(), true)) { Date date = new Date(); out.println(date); } } }

 

TCP/IP vs UDP/IP ● ● ●

●

Connection­oriented vs. connection­less protocol (and communication)  IP­level addressing and routing via DNS, ARP etc.  Quality of Service (QoS) differences:  ○ Sequencing (Packet order preserved?)  ○ Dealing with packet loss (retransmission in case of temporary failure)  Broadcast and multicast possible 

Blocking vs. Non Blocking Socket Blockiert ein Programm (z.B. der accept Call beim Java Socket API) so muss dies unbedingt  dokumentiert werden. Blockierende Methoden bringen ausserdem viele Fehlermöglichkeiten mit  sich, deshalb sollte man immer ein Timeout setzen.  Blocking means that if data is not available for reading or if the device is not ready for writing then  the operating system will wait on a request to read from or write to a socket until it either gets or  sends the data or times out. In other words the program may halt at that point for quite some  time if it can't proceed.  Non​ blocking means that the request to read or write on a socket returns immediately whether or  not it was successful, in other words, asynchronously. It is the task of the programmer then to  decide what to do next: to try again or consider the read/write operation complete. Non​ blocking  is usually much faster but is a bit more complex to set up and manage.      11 

   

Synchron 

Asynchron 

Blocking API Call 

Ja 

Situationsbedingt 

Non­blocking API Call 

Selten 

Ja 

 

Synchronous vs. Asynchronous  

 

Remote Procedure Call (RPC)   Remote procedure call (RPC) is an inter​ process communication (a set of methods for the  exchange of data among multiple threads in one or more processes. Processes may be running on  one or more computers connected by a network.) that allows a computer program to cause a  subroutine or procedure to execute in another address space (commonly on another computer on  a shared network) without the programmer explicitly coding the details for this remote interaction.   

 

Connection An RPC is initiated by the client, which sends a request message to a known remote server to  execute a specified procedure with supplied parameters.  The remote server sends a response to the client, and the application continues its process. While  the server is processing the call, the client is blocked (it waits until the server has finished  processing before resuming execution), unless the client sends an asynchronous request to the  server, such as an XHTTP call.  12 

 

Steps

1. Client procedure calls the client stub in the normal way.  2. Client stup builds a message and calls the local operating system.  3. Client’s OS sends the message to the remote OS.  4. Remote OS gives the message to the server stub.  5. Server stub unpacks the parameters and calls the server.  6. Server does the work and returns the result to the stub.  7. Server stub packs it in a message and calls its local OS.  8. Server’s OS sends the message tot the client’s OS.  9. Client’s OS gives the message to the client stub.  10. Client stub unpacks the result and returns to the client    Zwei Designdimensionen:  ● lokaler Aufruf (Kommunikation mit nächst tieferer lokaler Schicht)  ● Remote​  Protokoll (Kommunikation mit derselben Schicht auf entferntem Rechner)       

13 

 

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 den Merkmalen:  ● 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)   

Message Oriented Middleware (MOM)   Message​ oriented middleware (MOM) is software or hardware infrastructure supporting sending and  receiving messages between distributed systems. MOM allows application modules to be  distributed over heterogeneous platforms and reduces the complexity of developing applications  that span multiple operating systems and network protocols. The middleware creates a distributed  communications layer that insulates the application developer from the details of the various  operating systems and network interfaces. APIs that extend across diverse platforms and networks  are typically provided by MOM.  MOM provides software elements that reside in all communicating components of a client/server  architecture and typically support asynchronous calls between the client and server applications.  MOM reduces the involvement of application developers with the complexity of the master​ slave  nature of the client/server mechanism. 

14 

  Where is the Middleware? Middleware ist sowohl beim Client als auch beim Server im Queuing Layer.  Does the sender side also need a queue? Sender und Empfänger brauchen eine Queue um zeitlich entkoppelt zu sein.   

API Primitives   Primitive 

Meaning 

Put 

Append message to specified queue 

Get 

Block until the specified queue is nonempty and remove first message 

Poll 

Check queue for messages and remove first. Never block 

Notify 

Install handler to be called when a message is put into specified queue 

 

 

   

Message Queing Model Mit dem Message­Queuing Model enkoppelt man den Empfänger von der Zeitdimension. Er kann  selbst wählen, wie er die Nachricht empfangen will.  Der Sender kann auch eine lokale Queue verwenden um beispielsweise momentane  Übertragungsprobleme auszugleichen oder inkommende Nachrichten zu puffern. 

15 

       

Zeitlich gekoppelt 

Zeitlich entkoppelt 

Räumlich  gekoppelt 

Abbildung a: Kommunikation findet  gerichtet zwischen Sender und  Empfänger(n) statt. Empfänger  müssen zum Zeitpunkt des Sendens  aktiv sein   Beispiel: Message Passing, Remote  Invocation 

Abbildung b und d:  Kommunikation findet gerichtet  zwischen Sender und  Empfänger(n) statt. Empfänger  müssen zum Zeitpunkt des  Sendens nicht aktiv sein. 

Räumlich  entkoppelt 

Abbildung c: Sender und Empfänger  brauchen sich nicht zu kennen.  Empfänger müssen zum Zeitpunkt der  Kommunikation aktiv sein.  Beispiel: IP Multicast 

Abbildung d: Sender und  Empfänger brauchen sich nicht  zu kennen. Sender und  Empfänger haben eigene  Zeitsysteme. 

 

Architekturen  

16 

Pipes-and-Filter Chaining

Hub-and-Spoke Architecture

 

JMS JMS ist ein Interface zu einer Message Oriented Middleware (MOM) um Nachrichten  auszutauschen. Java EE bring von Haus aus eine JMS Implementation mit. Externe JMS Provider  implementieren lediglich das JMS Interface.    Einige Provider Implementationen:   ● Apache ActiveMQ  ● JBoss   ● WebSphere MQ    17 

Terminologie  

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

Producer/Publisher A JMS client that creates and sends messages.    Connection connection = connectionFactory.createConnection(); connection.start(); Session session = connection.createSession(mp.transacted, Session.AUTO_ACKNOWLEDGE); Destination destination = session.createQueue("testQueue"); MessageProducer producer = session.createProducer(destination); producer.setDeliveryMode(DeliveryMode.PERSISTENT); TextMessage message = session.createTextMessage("hello"); producer.send(message); producer.close(); session.close(); .connection.close();

Consumer/Subscriber A JMS client that receives messages.    Connection connection = connectionFactory.createConnection(); connection.start(); Session session = connection.createSession(mc.transacted, Session.AUTO_ACKNOWLEDGE); Destination destination = session.createQueue("testQueue"); MessageConsumer consumer = session.createConsumer(destination); TextMessage text=(TextMessage) consumer.receive(); consumer.close(); session.close(); connection.close(); 

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). Note that, contrary to what the name queue suggests, messages don’t have to be  delivered in the order sent. A JMS queue only guarantees that each message is processed only  once. 

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

18 

Struktur Header Ein Header wird immer gesendet. Er enthält Informationen für das Routing   und die Identifikation. Ein MOM­Provider normiert seine Message Header.  

Properties Properties sind optional – sie enthalten zum Beispiel Informationen, mit   deren Hilfe ein Consumer Nachrichten filtern oder weiterrouten kann   (Erweiterungen des Standard­Headers).  

Body Der Body ist auch zwingend erforderlich – er enthält die  auszutauschenden Nutzdaten (Text, Objekte, Binärdaten).   

QoS Settings JMS unterstützt gewisse Headers, allerdings ist die Implementation provider spezifisch! Es sollte  also immer die MOM Provider Dokumentation angeschaut werden und sich nicht auf die JMS  Beschreibung verlassen.      Attribute 

Description 

Transport Type 

Transport Protokoll für die Übertragung 

FIFO delivery 

Messages werden in der Reihenfolge zugestellt, in der sie gesendet  wurden 

Message length 

Maximale Länge einer Nachricht 

Setup retry  count 

Maximale Anzahl Versuche um die Remote Queue zu erreichen 

Delivery retries 

Maximale Anzahl Versuche um eine Nachricht in die Queue zu  speichern 

   

19 

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.   

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 Performance verschlechtert.     

 

20 

Channel Types  

Point-to-Point Channel   Messages werden zu einem spezifischen Consumer gerouted, der eine Queue für die Messages  verwaltet. Jede Message geht an eine spezifische Queue.    PTP characteristics:  ● Each message has only one consumer.  ● A sender and a receiver of a message have no timing dependencies. The receiver can fetch  the message whether or not it was running when the client sent the message.  ● The receiver acknowledges the successful processing of a message.     

     

 

21 

Publish-Subscribe Channel Messages werden an ein spezielles Topic gesendet. Subscriber können alle Messages zu einem  Topic abonnieren. Der Publisher muss die Consumer nicht kennen.    Publish/Subscribe model characteristics,  ● Each message can have multiple consumers.  ● Publishers and subscribers have a timing dependency. A client that subscribes to a topic  can consume only messages published after the client has created a subscription, and the  subscriber must continue to be active in order for it to consume messages.       

     

Message Reception Styles  

Polling Consumer Blocking Receive­Call (optionaler Timeout) 

22 

 

Event-driven Consumer Request Handler Pattern 

   

AMPQ   ●

Messages are published to exchanges, which are often compared to post offices or  mailboxes.   ● Exchanges then distribute message copies to queues using rules called bindings.   ● Then AMQP brokers either deliver messages to consumers subscribed to queues, or  consumers fetch/pull messages from queues on demand.      

Enterprise Integration Patterns   siehe andere Zusammenfassung       

23 

Remote Method Invocation (RMI)   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. Dieser Vertrag löst folgende NFRs:  ● Interoperability (multi platform connectivity)  ● Robustness (e.g. timeout management)  ● Openness (portability of application code) 

Interface Description Languages (IDLs) IDLs describe an interface in a language​ independent way, enabling communication between  software components that do not share a language – for example, between components written in  C++ and components written in Java   

RMI Möglichkeiten   ●

●

●

Kommunikation mit entfernten Objekten (Remote Objects)  ○ Synchroner Auftruf entfernter Methoden (Client​ Server)  ○ Details der Kommunikation dem Entwickler verborgen (Remote Proxy Pattern und  Skeletons)  Referenzieren entfernter Objekte  ○ über Namensdienst (RMI​ Registry)  ○ über Austausch entfernter Referenzen  Laden von verteilten Objekten  ○ entfernte Objekte als Methoden Parameter  ○ RMI beinhaltet einen Mechanismus zum dynamischen Laden von   ○ Objektcode 

  Die entfernte Schnittstelle spezifiziert, welche Methoden entfernt aufgerufen werden können.  In Java ist es nicht möglich, dass ein Objekt lokale und entfernte Methoden enthält, es ist nur  entweder lokal oder entfernt erlaubt.   

Higher-Level RPC Architecture  

24 

 

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

25 

 

 

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

RMI-Compiler All die Stubs und Skeletons von Hand anzulegen wäre eine zu grosse Handarbeit. Deshalb wird  RMI­IDL (als Interface Sprache) 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. 

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 Parameter und holt das Ergebnis ab. 

26 

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 client und delegiert diesen an das Objekt. Der Rückgabewert wird dann über  die Socketverbindung an Client zurück gesendet. 

Deployment Die RMI­Registry wurde sowohl vom Client, als auch vom Server verwendet. Um diese  bereitzustellen, wird ein Infrastruktur Server benötigt. 

  Wer started die RMI-Registry? Die RMI­Registry muss separat auf dem Infrastruktur Server gestartet und verwaltet werden. 

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. 

 

27 

RMI Beispiel  

Es muss ein Interface für die Remote­Methoden erstellt werden, dass sowohl dem Client, als  auch dem Server bekannt ist import java.rmi.Remote; import java.rmi.RemoteException; public interface Hello extends Remote { String sayHello() throws RemoteException; }

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) { ... } } }

28 

Zuerst muss das Remote Object von der RMI­Registry abgeholt werden. Danach können wir  auf dem Interface alle definierten 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) { ... } } }

 

Call-by-Value Es werden Kopien der Objekte zwischen Client und Server verschickt, dazu müssen die  Parameter­Klassen serialisierbar sein.  ● Vorteil: sie Anzahl der remote Zugriffe ist reduziert  ● Nachteil: Änderungen von entfernten Objekten sind so nicht möglich   

Call-by-Reference Referenz auf das Parameter­Objekt wird an den Server übertragen, dazu muss die  Parameter­Klasse ebenfalls ein RMI­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 

 

29 

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

  Um in Java ein Klasse serialisierbar zu machen, muss das Objekt mit dem Marker Interface  java.io.Serializable ausgezeichnet 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 serialVersionUID des Codes und des Objekts verglichen. Stimmen diese nicht überein wird  eine InvalidClassException auftreten.     

30 

Webservices   Basiert auf den Grundsätzen von RPC. 

 

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 in XML. WSDL schreibt man heutzutage nicht mehr von Hand, sondern wird  mit Contract Generation automatisch generiert (wsimport für Java oder svcutilfür .NET).  Diese Tools können auch direkt Proxies, Skeletons und Stubs für ein Schema generieren.   

 

Terminologie ● ● ● ● ● ●

Service  Endpoint  Binding  Interface  Operation  Types 

31 

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 

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. 

SOAP Envelope   234 Apples  

     

 

33 

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 

Quality Attributes (QAs) QAs are samples of NFRs:  ● 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    The challenges are:  ● Many attributes, many conflicts between them; many attributes hard to quantify  ● Often under​ specified (unknown) or over​ specified (overly ambitious)  ● Often stated on inadequate level of abstraction    Performance QAs  ● Latency  ○ Client perception: how long does a request/response interaction take?  ● Throughput  ○ Server concern: how many concurrent requests can be processed?  ● Code quality (e.g. object lifecycles)  ● Algorithms and data structures   ● Logical component architecture  ● Physical infrastructure architecture  ● Capabilities of products and open source middleware 

Performance and Scalability Tactics   Desired Quality  The ability of the system to predictably execute within its mandated  performance profile and to handle increased processing volumes in the future if required  Applicability 

Any system with complex, unclear, or ambitious performance requirements;  systems whose architecture includes elements whose performance is  unknown; and systems where future expansion is likely to be significant  34 

Concerns 

● ● ● ● ● ●

response time  throughput  scalability  predictability  hardware resource requirements  peak load behavior 

Activities 

● ● ● ● ● ● ●

capture the performance requirements  create the performance models  analyze the performance models    conduct practical testing  assess against the requirements  rework the architecture 

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  partition and parallelize  scale up or scale out  degrade gracefully  use asynchronous processing  relax transactional consistency  make design compromises 

Pitfalls 

● ● ● ● ● ● ● ● ● ● ●

imprecise performance and scalability goals  unrealistic models  use of simple measures for complex cases  inappropriate partitioning  invalid environment and platform assumptions  too much indirection  concurrency­related contention  database contention  transaction overhead  careless allocation of resources  disregard for network and in­process invocation differences 

     

Deployment Diagramme UML Deployment Diagramm  

  35 

  Hardware, Prozessoren und Runtimes (z.B. JVM) werden als Nodes dargestellt.  Als Artefakte werden Software Komponenten (Web Applikation, Datenbank) und deren  Verbindungen (JDBC, REST, RMI) bezeichnet.  Artefakte werden Nodes zugewiesen um den Deployment Status des Systems zu modellieren.         

     

36 

$  37 

IBM Unified Method Framework (UMF) UMF verwendet für Artifact den Begriff Work Product und ein Deployment Diagram wird als  Operational Model bezeichnet.  Deployment Units sind die Verbindung zwischen der logischen  Sicht (Komponenten) und der Infrastruktur (Operational Model).     UMF ist eine eigene Methode Software in folgenden Schritten zu entwickeln:  1. Component Model und Operational Model beinflussen sich gegenseitig, so brauche ich  beispielsweise für persistente Sessions eine weitere Datenbank (z.B. Redis)  2. Conceptual OM, Logical OM, Physical OM: Es wird zwischen den verschiedenen Levels  immer mehr ins Detail gegangen (Datenbank => RDBMS => MySQL) 

   

 

38 

MSDN Deployment Patterns Deployment Strategy  

Non-Distributed Deployment Aller Layer sind auf demselben Server, dies macht das Deployment und die Entwicklung einfacher  und die benötigten Ressourcen sind klein. Ausserdem ist der Performance Einfluss von  Kommunikation verringert (da die Layers lokal kommunizieren können).  Aber weil alle Layers diesselben Ressourcen verwenden, kann beispielsweise das Business Layer  zum Flaschenhals für das Presentation Layer werden. Es ist sehr schwierig, ein solches  Deployment gut zu skalieren und zu warten. 

 

Distributed Deployment Durch das die Layers auf verschiedenen physikalischen Server sind, kann ein Server verwendet  werden, der am besten auf die Anforderungen des Layers passt (z.B. RAM für Webserver, CPU für  Business Layer). Durch die separierten Komponenten sind wir viel flexibler und können einfacher  skalieren und anpassen (z.B. eine Firewall zwischen Web Server und Application Server). 

39 

Performance Patterns  

Web Farms   Mehrere Server welche die gleiche Applikation betreiben, werden Web Farms genannt. Requests  werden gleichmässig auf alle Server verteilt. Einfaches Routing ist zum Beispiel mit Round Robin  DNS (Die A Records werden alterniert).   

   

Application Farms Auch für das Business und Data Layer können mehrere Server zu einer Farm zusammengefasst  werden. Dazu müssen die Requests aus dem Presentation Layer gleichmässig auf die Server des  Business Layers verteilt werden. 

Separate User Sessions   Web Applikationen sind nicht immer stateless. Ein gutes Beispiel sind User Sessions (welcher  User gehört zu welchem Cookie), diese sollten in einem separaten Session State Store gehalten  werden und nicht auf den Web Application Server selbst.   

Affinity   Die Webserver müssen alle den selben Encryption Key verwenden. Auch für SSL Verschlüsselung  sollten entweder all denselben Key benutzen oder ein separater Cluster ist für die Verschlüsselung  zuständig.     

40 

Load-balancing Cluster   Load Balancer verteilen Requests auf  verschiedene Webserver (besseres  Verfahren als DNS Load Balancing). Ein  Load Balancer kann zum Beispiel für eine  Webseite die Bilder von verschiedenen  Servern beziehen und so die Reaktionszeit  verbessern.   

Reliability Patterns

  Failover Cluster   Bei einem Failover Cluster springen Server  für einander ein und übernehmen die Arbeit  falls jemand ausfällt. Jeder Server im Cluster  hat einen anderen Server als Standby  konfiguriert.           

Security Patterns  

Impersonation/Delegation   Bei Impersonation emuliert der Server als  wäre er der User des Clients. Er führt das  Programm also im Security Kontext eines  anderen aus. So können die Security Regeln  für Windows User oder Datenbank Benutzer  angewandt werden.               41 

Trusted Subsystem User bekommen Rollen zugewiesen welche  die gleichen Privilegien haben. Der  Application Server wendet nun die  Sicherheitsregeln auf diese Rollen an und  deshalb haben dann auch nur Benutzer die  berechtigt sind, Zugriff auf die Datenbank.  Die Datenbank muss aber dem Application  Server vertrauen, dass er die  Sicherheitsregeln korrekt umsetzt     

Multiple Trusted Service Identities   Wenn mehr als eine Trusted Entity (wie der Application Server zuvor) benötigt werden, kann der  Server zum Beispiel einfach verschiedene Benutzer für die Datenbank verwenden. Das Prinzip des  Trusted Subsystem giltet immer noch und es hat keinen Einfluss auf die Scalability. 

   

42 

Performance Testing Gatling Gatling ist eine Load Testing Software mit der man Benutzungsszenarien spezifizieren und deren  Ausführungszeit messen 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 Usersessions simuliert werden können, um den zu testenden Server voll auszulasten. 

UML Aktivitätsdiagramm   Es ist wichtig, dass die Bedenkzeiten zwischen den Interaktionen zufällig gestreut werden.  Einerseits würde einekonstante Verzögerung kein realistisches Benutzerverhalten modellieren.  Zudem würden dadurch in einer Simulation mit mehreren Benutzern, dieselben Requests immer  zusammen ausgeführt. 

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

Kriterium 

Metrik 

K1 

Die Webseite soll flüssig bedienbar sein. 95% aller Requests sollen  in weniger als 500ms beantwortet werden. 

Response  Time in ms 

K2 

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

Response  Time in ms 

K3 

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

no_errors /  no_total 

43 

Kapazitätstest Performance sollten an der Kapazitätsgrenze durchgeführt werden. Deshalb muss zuerst evaluiert  werden, wieviele Benutzer ein System zur gleichen Zeit benutzen können. Die Kapazitätsgrenze  findet man heraus, indem man die Anzahl User hochschraubt, ohne das man die  Akzeptanzkriterien verletzt.  Diese Kapazitätsgrenze kann nun als Baseline für Performance Tests genommen werden. 

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

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    Scalability kann durch verschiedene Arten herbeigeführt werden:  ● Size scalability: Lineare Skalierung mit mehr Ressourcen (Mehr CPU, RAM, Bandwidth)  ● Generation scalability: Bessere Hardware durch Innovation (Hyperthreading, SSD)  ● Problems scalability: Gewisse Probleme lassen sich schwer oder gar nicht skalieren   

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

Scale Out Underlying resources that are increased are mainly additionally complete servers. 

  44 

 

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  ● Workload­based    Verteilung basierend auf Workload braucht konstantes Monitoring der Server und bedingt gutes  Testen und Abschätzen der Auslastung, die Applikation darf aslo keine Black Box sein. 

Caching Ein Cache ist ein schneller Assoziativspeicher (Hardware, Operating System, Middleware),  typischerweise als Zwischenspeicher genutzt. Caching sollte vorsichtig verwendet werden und  erst, wenn es wirklich benötigt wird, denn es führt zu vielen neuen Problemen. 

Vorteile ● ● ● ●

Schnellerer Zugriff auf gecachte Ressourcen  Es kann Bandbreite gespart werden  Server wird geschont (weniger Rechenzeit)  Cache funktioniert auch noch, wenn der Server down ist 

Nachteile ● ●

Langsamere Performance bei einem Cache Miss  Eine veraltete Version des Cache Eintrags wird verwendet (funktioniert schlecht für  dynamische Inhalte)  ● Ressourcen gehen im Cache verloren  ● Komplizierte Konfiguration    There are only two hard things in Computer Science: cache invalidation and naming things.  ­ Phil Karlton   

In-Memory Caching Die Resultate rechenintensiver Operationen   werden durch die Applikationen im lokalen Hauptspeicher abgelegt. 

Distributed Caching Innerhalb einer Applikation werden Resultate   rechenintensiver Methodenaufrufe auf einem Remote­Server gecached.   Dadurch können z.B. mehrere Instanzen eines Services die Informationen   im Cache teilen.  

45 

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

Performance Bottlenecks     Ressource 

Zeitfaktor 

Platzfaktor 

CPU 

CPU muss möglichst schnell  agieren. 

 

Memory 

 

Platz ist der limitierende Faktor bei  Memory 

Hard Disk 

Datenmenge spielt heute keine  grosse Rolle mehr, die Zeit um  die Daten zu speichern jedoch  schon. 

 

Netzwerk 

Latency und Throughput sind  limitierend. 

 

 

Availability  

Definition Ein System gilt als verfügbar wenn es läuft und korrekte Resultate produziert. Hohe Verfügbarkeit  ist, wenn die Verfü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)   

Mean Time Between Failure (MTBF) Die Durchschnittszeit bevor ein System fehlschlägt. MTBF misst also die Zuverlässigkeit. 

Mean Time To Repair (MTTR) Die Durchschnittszeit um ein System zu reparieren. Entspricht der Downtime.     

46 

   

 

Hohe Verfügbarkeit 24x7 Verfügbarkeit ist unmöglich und eine Annäherung sehr teuer.  Hohe Verfügbarkeit muss also genau mit den Kosten abgewogen werden. Der Vorteil von hoher   Verfübarkeit ist eine kleineres Downtime Risiko.    Falls Risiko > Kosten der hohen Verfügbarkeit, lohnt sich eine spezielle Lösung. 

47 

    Availability % 

Downtime  per year 

90% 

36.5 days 

95% 

18.25 days 

98% 

7.3 days 

99% 

3.65 days 

99.5 

1.83 days 

99.9 

8.76 hours 

99.99 

52.56 minutes 

99.999 

5.26 minutes 

                Verfügbarkeit verteilter System  Wenn mehrere Systeme voneinander abhängen, ist die gesamte Verfügbarkeit das Produkt der  Verfübarkeit der Systeme.  Bei der Verfügbarkeit ist also das schwächste Glied der Kette wichtig. 

48 

   

Incident Lifecycle    

   

49 

Availability Tactics   Redundanz ist der Schlüssel für eine gute Verfügbarkeit. Dazu sollte Software möglichst schnell  fehlschlagen, so das der Fail­Over übernehmen kann.  Weiter Methoden sind:  ● 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    Bewährte Designentscheidungen für HA Software:    ● Client/Server Kommunikation auf Queues basieren (wiederherstellbar)  ● Server Transaktionen für Client Calls verwenden  ● Message Integrity gewährleisten  ● Server müssen so weit wie möglich stateless sein  ● Server Hot Pools (Redundanz)  ● Messaging verwenden   

Watchdog   Ein Watchdog überprüft periodisch ob ein Programm noch am Leben ist.    Folgende Methoden werden verwendet:  ● Heartbeat: Prozess schicht “I’m alive” Nachrichten an den Watchdog. Hören diese  Heartbeats auf ist der Prozess wahrscheinlich fehlgeschlagen  ● Pulse: Monitor fragt aktiv den Status des Prozess ab (Polling)    Ein Watchdog kann Prozesse aufgrund dieser Informationen neustarten (ähnliche Funktionsweise  wie Windows Services und dem Unix init system). 

Deadman Switch Falls kein Puls oder Heartbeat da ist, begeht das ganze System Selbstmord (kompletter System  Shutdown).     

50 

Redundanz 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 is basically turned on once to have software installed and configured, and then  is turned off until needed. 

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. 

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

 

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 nicht redundant ausgelegt ist  ● Garbage Collector: Läuft der GC nicht mehr, wird das Programm irgendwann abstürzen.         

51 

API Design und Management  

Maintainability Wartbarkeit ist die Eigenschaft leicht verändert werden zu können. Man will zum Beispiel etwas  korrigieren oder verbessern, an eine neue Komponente oder an ein System anpassen.  Remote APIs unterscheiden sich von lokalen APIs in der Wartbarkeit. 

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 

 

Service Developer Questions ● ●

● ● ● ● ● ● ●    

How do you create a service API, what are the common API styles, and when should a  particular style be used?   How can clients and services communicate, and what are the foundations for creating  complex conversations in which multiple parties exchange data over extended periods of  time?   What are the options for implementing service logic, and when should a particular approach  be used?   How can clients become less coupled to the underlying systems used by a service?   How can information about a service be discovered?   How can generic functions like authentication, validation, caching, and logging be supported  on the client or service?   What changes to a service cause clients to break?   What are the common ways to version a service?   How can services be designed to support the continuing evolution of business logic without  forcing clients to constantly upgrade?    

52 

 

Service Design Patterns Service Layer Pattern Die Komplexität eines Systems muss nach aussenhin verborgen sein. Man möchte keine  primitiven Operationen und komplexe Modelle bereitstellen, stattdessen sollte eine ausgewählte  Menge Operationen alle wichtigen Handlungen umfassen.    Das Service Layer eignet sich ausserdem für:  ● Zugriff auf Rollen beschränken (RBAC)  ● Transaktionen kontrollieren  ● Logging und Monitoring  ● Exception Handling   

 

Remote Facade   Viele kleine Calls eignen sich schlecht für Remoting, sie sollten deshalb in ein gröberes Interface  umstrukturiert werden, dass mehrere Calls bündelt.    Anstatt drei Remote Calls für setStreet, setCity und setZip zu machen, wird eine grössere Aktion  durchgeführt, welche die Aktionen bündelt und auch gute Transaktionsgrenzen setzt. 

53 

 

Data Transfer Object (DTO)   Ein DTO entkoppelt das Service Layer von der Applikation. Anstatt einen konkreten Typ Album zu  übertragen, wird ein Objekt, dass alle benötigten Eigenschaften für den Client enthällt übertragen.   

   

Service Granularity Patterns Dot Pattern Einen einzigen skalaren Parameter. 

Bar Pattern Ein einziger Parameter, der jedoch einen komplexen Typ hat mit mehr Informationen. 

Dotted Line Pattern Mehrere skalare Parameter. 

Combined Pattern Mehrere komplexe Parameter. 

54 

 

REST Anti Patterns ● ● ● ● ● ● ● ●

Tunneling everything through GET  Tunneling everything through POST  Ignoring caching  Ignoring response codes  Misusing cookies  Forgetting hypermedia  Ignoring MIME types  Breaking self​ descriptiveness 

  Further more:  ● Using inappropriate REST maturity level (HATEOAS justified?)  ● Under​ specifying service contract and request/response payloads 

POINT-Test An API should get (and stick) to its POINT.    Purpose: an API must be purposeful (e.g., driven by client demand/use cases)  Orientation: an API should expose domain objects (e.g., resources or services) and adhere to OO  principles such as high cohesion/low coupling  Isolation: each API call should be as isolated as possible (i.e., free of side unexpected, undesired  effects)  Neutrality: an API should be neutral, i.e. not optimized for any particular client channel  T­Shaped: an API should be “t­shaped” (i.e., offer broad and deep calls), e.g., provide a  master­detail interface and/or search functionality   

55 

Checkliste  

Mandatory ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●

Semantics, inklusive gewünschte (Seiten­)effekte und Parameter­Bedeutung (Spezifischer  Datentyp oder generisch?)  Idempotenz des Aufrufs (wiederholte Aufrufe mit den gleichen Daten führen zu demselben  Ergebnis)  Pre­ und Postconditions dokumentiert  State Management/Transitions of Resources  Blocking Behaviour (if any), Timeout Management  Multithreading considerations (bei local API: ist es threadsafe, startet es eigene Threads,  gibt es library­interne Concurrency)?  Treatment of NULL, Optional Values, Value Ranges, Grenzwerte (z.B. beim übergeben von  Zahlen)  Error Handling  Versionsangaben (ganzes API, einzelne Methoden)  Bei RESTful HTTP: HTTP Method Definition:  http://www.w3.org/Protocols/rfc2616/rfc2616­sec9.html  Response examples for all the supported response types  URI Structure is described  Parameters are documented and their encoding/format is specified (e.g. DateTime uses  ISO 8601)  Documentation for all service methods that is up to date  All possible response codes or errors are specified  SLO und SLA (vgl. Lektion 9): Service­Verfügbarkeit, Preis pro Aufruf 

 

Wishlist   ● ● ●

● ● ● ● ● ●

● ●

OOAD Domain Model der Schnittstelle und der dahinterliegenden Anwendung wird erklärt  und visualisiert (soweit relevant für API User, vgl. Remote Facade und DTO Patterns)  Naming Conventions vorhanden und durchgängig eingehalten (Resourcen, Operationen,  Parameter, Datentypen)  Sandbox in Dokumentation eingebaut (mit verschiedenem Body­ und Request­ Format  Einstellungsmöglichkeiten),  Bsp:https://github.com/nelmio/NelmioApiDocBundle/blob/master/Resources/doc/index.md  Gute Beispiele  Call Choreography (Sequencing, FSM or Workflow)  API Usage Best Practices (performance tuning tips, patterns)  Links to Developer Community (own wiki, stack overflow)  Change Log  If I request a collection of objects, I want to specify which attributes the objects should be  included (e.g. I'm not interested in published photos of every user, I only want the name and  prename)  Examples how to access the API for popular languages  API is versioned (e.g. /v1/users/12 ) and gets obsolete as soon as a new version (e.g.  /v2/persons/12) is released but stays usable for a transition time  56 

●

Overview which services are online (Uptime information) 

 

Andere Kriterien   ● ● ● ● ● ● ● ● ●

Klare Begriffe (Methoden, Parameter)  Präzise, nachvollziehbar, implementierbar  Abgestuft, konsistent, sofort ablauffähig  Parameter – so viel wie nötig, so wenig wie möglich  Keine exotischen Datentypen  Abgrenzung Funktionen untereinander und nach aussen  Offenheit – Spezifikation ist lesbar, Feedback, Einfluss der User, öffentlich zugänglich  Active Developer and User Community  Weiteres Beispiel : http://developers.flattr.net/api/ 

     

Distributed Control Systems Definition Realtime System A real­time system is one that must process information and produce a response within a specified  time, else risk severe consequences, including failure. That is, in a system with a real­time  constraint it is no good to have the correct action 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)    Control Loop    DCS Architektur 

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  57 

More Details

● ● ● ● ●

  Separates components in memory  Spans across cores and systems  Provides distributed execution  Enables software­based fault tolerance  Allows for dynamic software updates 

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 

Fault Tolerance in Real Time Domain Redundanz Redundante Controller mit einem Heartbeat Monitor.    Parameter für Redundanz:  ● Zeit benötigt um Controller zu wechseln  ● Anzahl Fehler (Wie häufig steigt z.B. Sensor aus?)  ● Kosten (Hardware und Energie)   

 

58 

Dynamic Fault Tolerance Hypervisor verteilt kritische Applikationen automatisch redundant. 

 

System Management FCAPS

 

Fault Fehler erkennen, isolieren und korrigieren. 

Configuration Konfiguration von Software und Hardware im Netzwerk (Versioning, Change Management). 

Accounting Kosten identifizierenund analysieren (Billing für Kunde). 

Performance Performance evaluieren und Effektivität des Netzwerks messen. 

Security Sicherheitsaspekte beachten (Confidentiality, Availablility, Integrity).   

59 

60 

IT Infrastructure Library (ITIL) ITIL ist eine Sammlung von Best Practices zur Umsetzung eines IT­Service­Managements. Gilt als  De­facto Standard für IT­Geschäftsprozesse. Die ITIL orientiert sich an dem durch den IT­Betrieb  zu erbringenden wirtschaftlichen Mehrwert für den Kunden. Dabei werden die Planung, Erbringung,  Unterstützung und Effizienz­Optimierung von IT­Serviceleistungen im Hinblick auf ihren Nutzen als  relevante Faktoren zur Erreichung der Geschäftsziele eines Unternehmens betrachtet.   

 

61 

Systems Management Patterns   System Management dreht sich um drei Punkte:  ● Monitoring and Controlling  ● Observing and Analyzing   ● Testing and Debugging    Middleware kann nicht nur für das Umsetzen von Remoting gebraucht werden, sie ermöglichen  auch System Management Patterns.   

Wire Tap  

Der WireTap ermöglicht es Messages eines Point­to­Point Channel zu untersuchen und  beispielsweise zu archivieren. Dazu konsumiert der Wire Tap die Message vom Input  Channel und publiziert sie sowohl an die ursprüngliche Destination als auch einen neuen  Channel. Auf dem zweiten Channel können wir nun ohne die Funktionalität des Messaging zu  beinträchtigen die Messages analysieren.. 

 

Detour Manchmal müssen Messages auch verändert werden(im Gegensatz zum Wire Tap), um  beispielsweise Kompabilität zu gewährleisten oder ein Messaging System zu testen.    Eine Detour besteht aus einem Router, der bestimmte Messages (Control Bus) herauspickt und  auf eine Detour (Umweg) schickt. 

   

…    62 

Message History   Die loose Kopplung zwischen Sender und Empfänger hat neben vielen Vorteilen auch zur Folge,  dass wir beispielsweise nicht wissen wer eine Nachricht publiziert hat. Das Message History  Pattern hilft den Nachrichtenfluss zu analysieren.  Dazu wird an jede Message eine zusätzliche Information an den Header angehängt, wo die  Nachricht durchgegangen ist (wie ein Poststempel oder SMTP). Jede Komponente im  Nachrichtenfluss schreibt ihre Debugging Informationen in den Heade. Der Body bleibt dabei  unberührt.     

   

Message Store   Der Message Store ist ein Archiv, dass Informationen zu jeder Nachricht an einem zentralen Ort  (dem Message Store) speichert.  Beim Senden einer Nachricht wird immer zusätzlich noch ein Duplikat der Nachricht an den  Message Store gesendet. 

   

       

63 

Java Management Extensions (JMX)   JMX ist eine Erweiterung für Java SE und EE welche für das Ressourcen Management gedacht ist.     Mit JMX ist es möglich:  ● Status von Hardware zu messen (mit einem Java Wrapper)  ● Ressourcen zu konfigurieren und Statistiken zu sammeln  ● Debugging Optionen festzulegen  ● Performance einer Applikation zu messen  ● Management einer Java Applikation (einfache Anbindung an Management Interface)     

   

Manageable Resource Ist eine Applikation oder Gerät, dass gemanagt werden soll. Ist in der Regel eine Java Instanz oder  Wrapper um ein anderes Objekt.   

MBean Eine Resource welche man mit JMX managen und monitoren kann.   

64 

MBean Server Eine Java Klasse welche mehrere MBeans verwaltet. Ist eine Registry um MBeans zu finden und  zu registrieren.    JMX Agent  Ein Java Prozess mit denen man MBeans managen kann. Der MBean Server kann beispielsweise  verschiedene Protokolle und JMX Clients unterstützen.   

Management Objekt implementieren   Ein Objekt in JMX wird als MBean bezeichnet. Um beispielsweise einen Cache als MBean  darzustellen, müssen wir:  1. Interface mit MBean als Suffix erstellen  2. Ressourcen implementieren Interface  3. Ressourcen werden bei einem MBean Server registriert   

 

65 

Logging Logging ist essenziell für Entwickler und das Operation Team:  ● Ursache für Fehler analysieren  ● Spezielle Last (Event Storm during Peak) zu untersuchen  ● Events zu beobachten    Logging in einem verteilten System hat viele Schwierigkeiten:  ● Es braucht eine einfache Logging Solution die in verschieden Applikationen verwendet und  erweitert werden kann  ● Logging muss an einem zentralen Ort stattfinden (Administrator braucht nur Zugriff auf  einen zentralen Ort)  ● Logging darf die Performance nicht negativ beeinflussen  ● Logging Solution muss Nachrichten filtern und Aktionen auf speielle Events erlauben  (Persistieren einer Nachricht, Alerts auslösen)  ● Es muss auch möglich sein lokal zu loggen, denn bei Netzwerkproblemen dürfen keine  Nachrichten verloren gehen    Folgendes sollte beim Loggen von Events beachtet werden:  ● ExistierendeLogging Frameworks verwenden (Log4J)  ● Log Levels definieren und verwenden (DEBUG, INFO, WARNING, ERROR, SEVERE)  ● Interface für Logger verwenden um Logging Framework wechseln zu können  ● Notruf Analogie:  ○ Wer meldet sich und warum  ○ Wann und wo passierte das Ereignis   

Log Levels   TRACE: Sehr detaillierte und spezifische Informationen, die für das Entwickeln und Debuggen  eines Features benötigt werden, beispielsweise In und Out Parameter von Methodenaufrufen ,  Snapshots von Datenstrukturen oder Zwischenschritte in komplexen Algorithmen. Werden u.U.  nach dem Fertigstellen des Features auch wieder entfernt.    DEBUG: Detaillierte Informationen, die nützlich sein können, um Fehler in der produktiven  Umgebung nachvollziehen zu können (Bsp, einzelne Schritte in komplexen Abläufen, Schicht­ und  Tierübergänge).     INFO: Welche fachlichen Prozesse im System durchgeführt werden. Z.B. „Benutzer X hat Item Y  bestellt“ (Ebene Use Case/User Story).    WARNING: Vorgänge, die unter Umstände näher beachtet werden sollten. Das Abweichen von  empfohlenen Standardeinstellungen in einem Konfigurationsfile oder das Nichtvorhandensein von  bestimmten SystemRessourcen sind zwei Beispiele. Sollte sparsam verwendet werden, damit   die Warnungen auch beachtet werden.    ERROR: Fehler, die zum Abbruch eines Vorgangs oder zum Herunterfahren eines Systems führen      66 

Oft kann es nützlich sein, die Log Levels einzelner Logger im laufenden Betrieb ändern zu können.  So kann zum Beispiel nach dem Ausliefern neuer Feature ein tieferes Log Level gewählt werden  (d.h. mehr geloggt werden), um Probleme rasch erkennen und beheben zu können. Später kann  dann der Log Level erhöht werden (also weniger geloggt werden), um Ressourcen zu schonen.    

Verschiedene Anforderungen   ●

Als Entwickler möchte ich nachvollziehen können, wie oft ressourcenintensive Methoden  aufgerufen werden, um Performanceengpässe zu erkennen.  ●  Als Systemadministrator möchte ich über Netzwerkprobleme informiert werden, um  geeignete Gegenmassnahmen durchführen zu können.  ●  Als Systemadministrator möchte ich wissen ob das Starten und Stoppen der Applikation  erfolgreich durchgeführt wurde, damit ich den Fortschritt von Deploymentprozessen  überwachen kann.  ●  Als Supporter möchte ich die Aktionen eines Benutzers nachvollziehen können, um ihm  bei Problemen schnell helfen zu können.   

67