35
wba2 (Subject) / wba2 (Lesson)
Advertisement
- Middleware unterstützt und verwaltet die Interaktion zwischen Anwendungen aus heterogenen Computernetzen. „architektonische Lösung für das Problem, eine Sammlung von Anwendungen über ein gemeinsames Interface anzusprechen“. Hohes Maß an Verteilungstransparenz verschiedene Typen Anwendungsorientiert Kommunikationsorientiert Nachrichtenorientiert Komplexität dieser Applikationen und ihre Infrastruktur verborgen werden Ebene in einem komplexen Softwaresystem dar, die als „Dienstleister“ anderen ansonsten entkoppelten Softwarekomponenten den Datenaustausch ermöglich Middleware organisiert den Transport komplexer Daten (sog. messaging), vermittelt Funktionsaufrufe zwischen den Komponenten (sog. Remote Procedure Calls), stellt die Transaktionssicherheit über ansonsten unabhängige Teilsysteme her etc.
- Middleware Software (2) als Standardsoftware von mehreren Herstellern verfügbar stellt sieSoftware-Schnittstellen oder Dienste bereit Eine Softwarekomponente A, die die Middleware-Schicht benutzen möchte, um mit einer Softwarekomponente B zu kommunizieren, kann diese Schnittstellen benutzen. Die entsprechenden Aufrufe werden von der Middleware-Softwarekomponente über ein Netzwerk weitergereicht. Auf der Empfängerseite setzt die Middleware die Anforderung in einen Funktionsaufruf an die Software B um. Gegebenenfalls leitet sie die „Antwort“ der Komponente B an Komponente A auf demselben Weg zurück.
- JMS Java Message Service Programmierschnitstelle für Ansteuerung einer Message oriented Middleware zum Senden und Empfangen von NAchrichten aus einem client heraus soll asynchrone bzw. lose gekoppelte Kommunikation ziwschen Komponenten einer verteilten Anwendung ermöglichen Teil der JEE zwei Ansätze Point to Point mit Queues und Publish-subscribe
- JMS provider ein messaging system, das JMS Schnitstellen und administrative Funktionen bietet. zB Topics (für PubSub), Queues (P2P) und Sessions
- JMS Client ein in Java geschriebenes Programm das JMS-Nachrichten produziert und/oder konsumiert
- Administrated objects (JMS) vorkonfigurierte Objekte eines JMS providers, die von eine JMS Client genutzt werden können .
- JNDI (JMS) Java Naming and Directory Interface nimmt die Name/Adress-Zuordnung vor
- lose Kopplung bezeichnet in der Informatik einen geringen Grad der Abhängigkeit mehrerer Hard- oder Software-Komponenten untereinander. Bei loser Kopplung eines Systems lassen sich Änderungen einzelner Komponenten oftmals einfacher durchführen, da die Änderung nur eine lokale Auswirkung hat
- Administrative tool (JMS) erlaubt die destination(objekte) und connction factories(objekte) an ein JNDI namespace zu binden.
- Connection factory objects (JMS) encapsulates a set of connection configuration parameters that has been defined by an administrator. A client uses it to create a connection with a JMS provider. erlauben einer anwendung andere JMS-Objekte zu kreieren
- Advertisement
- Destination objects (JMS) dienen als Verzeichnisse für Nachrichten GlassFish: Queue Objects for P2P-communication TopicObjects for PubSub-Communication
- Resource injection (JMS) @Resource annotation is used to declare a reference to a resource. The container will inject the resource referred to by @Resourceinto the component either at runtime or when the component is initialized
- xml extensible markup language
- verteiltes System Ein verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes, kohärentes System erscheinen. Eigenschaften: 1. Ein Verteiltes System besteht aus autonomen Komponenten. 2. Die Benutzer (Menschen oder Programme) glauben sie hätten es mit einem einzigen System zu tun. 3. Unterschiede zwischen den einzelnen Computern und der Art wie sie miteinander kommunizieren bleiben weitgehend vor den Benutzern verborgen. Ebenso der innere Aufbau. 4. Benutzer können konsistent und einheitlich mit dem System arbeiten. 5. Grundsätzlich sollten Verteilte Systeme einfach zu erweitern oder zu skalieren sein. 6. Es steht normalerweise ununterbrochen zur Verfügung, auch wenn einige Komponenten vorübergehend ausfallen.
- Schnittstelle Austausch Beschriebung Kontakt
- Software Komponente abhängigkeiten und zusicheurngen verteilung & integration
- synchron dsf
- asynchron svf
- rest fd
- web services dfgdf
- Distributed Coordination based Systems regerrwer
- xmpp gdfg
- Distributed Objects & Remote Invocation - fdsf
- Distributed Object based Systems gdg
- free Software xcyxf
- open source software rd
- rdf srtsd
- RPC Remote Procedur Call zsm: 1. The client procedure calls the client stub in the normal way. 2. The client stub builds a message and calls the local operating system. 3. The client's as sends the message to the remote as. 4. The remote as gives the message to the server stub. 5. The server stub unpacks the parameters and calls the server. 6. The server does the work and returns the result to the stub. 7. The server stub packs it in a message and calls its local as. 8. The server's as sends the message to the client's as. 9. The client's as gives the message to the client stub. 10. The stub unpacks the result and returns to the client -Client verwendet Stubs um Parameter für das Unterprogramm zu verpacken und auf reise zu schicken(mshalling) Call By Referenz (Übertragung einer Referenz mittels Zeiger) macht keinen Sinn da meistens in verschiedenen Namensräumen und lokale Speicheradresse des clients von Server nicht ersichtlich sind -> Lösung : Werte von Cleint zum Server über Parameterliste Werte von Serer zum Cleint als Return werte SUN-RPC: nur eine Parametervariable, wenn mehrere Variablen übergeben werden müssen, werden sie zu einer Struktur zusammengefasst -Server-stub stellt Hülle u das gewünschte Unterprogramm dar
- Servlet sf
- Verteilte Anwendung SW-Komponente verteilte Systeme Köhärenz
- Advertisement
- Dienst „mechanism“ definierte Schnittstelle Regulierung des Zugriffs
- EJB (Java EE) Enterprise JavaBeans standardisierte Komponenten innerhalb eines Java-EE-Servers vereinfachen die Entwicklung komplexer mehrschichtiger verteilter Softwaresysteme mittels Java wichtige Konzepte für Unternehmensanwendungen, z. B. Transaktions-, Namens- oder Sicherheitsdienste, umgesetzt werden, die für die Geschäftslogik einer Anwendung nötig sind. mehreren unterschiedlichen Ausprägungen für verschiedene Klassen von Anwendungsfällen können entweder remote oder lokal ngesprochen werden. Entity Bean modellieren die dauerhaften (persistenten) Daten des Systems Beispiele sind physikalisch vorhandene Dinge wie Benutzer, Informationsstrukturen wie Adressen oder archivierte Vorgangsinformationen wie Rechnungen. Sie repräsentieren z. B. einen Datensatz aus einer Datenbank. Die Persistenz kann entweder vom Bean-Entwickler selbst programmiert („Bean Managed Persistence“,BMP) oder von einem EJB-Container bereitgestellt werden Session Bean Session Beans bilden insbesondere Vorgänge ab, die der Nutzer mit dem System durchführt. Sie bedienen sich häufig mehrerer Entity Beans, um die Auswirkungen des Prozesses darzustellen.
- Java EE -Enterprise Edition JAVA EE Plattform verwendet ein verteiltes multi-tier Anwendungsmodell für Enterprise -Anwendungen Anwendungslogik ist in Komponente die bestimmte Funktionen erfüllen unterteilt. Diese werden je nachdem zu welchem Tier sie gehören an verschiedenen Systemen installiert. Die meisten Komponenente wurden mit Java programmiert. Jede Komponente ist ein unabhängiges, funktionelles Softwarelement welche in die Java EE mit ihren relatierten Klassen und Files assembliert wunrden und mit anderen Komponenten kommunizieren. Typischerweise spricht man bei Java EE um ein 3-tier-Modell, da die Anwendung über drei Standorte verteilt wird. Diese sind Client Machine, Java EE Serve, Database Server. JavaServer Faces: Mit Hilfe von JSF kann der Entwickler auf einfache Art und Weise Komponenten für Benutzerschnittstellen in Webseiteneinbinden und die Navigation definiere
- Message oriented Communication Unterteilung in synchron und asynchron und transient und persistent Communication Synchron:Sender blockiert bis der Empfänger sich an der Kommunikation beteiligt Asynchron: es müssen nicht beide Kommunikationspartner zur sleben Zeit interagieren -> Lose Kopplung von transient und persistent hängt ab wie lange Nachrichten gespeichert werden. Transient Communication speichert die NAchrichten nur solange, solange beide Seiten in Ausführung sind. Und wenn nächster router oder Empfänger nicht erreichtbar ist wird die Nachricht verworfen. Persisistent: Nachricht wird solange gespeichert bis sie vom Empfänger abgeholt wird
- Asynchroner RPC und Verzögerter RPC Asynchroner: Wenn es kein Ergebnis gibt auf das der Client warten muss oder der Cleint nicht bereit ist zu warten ohne in Zwischnezeit irgendwas zu tun , dann macht es keinen Sinn, dass er auf das Ergebnis des Servers wartet -> unnötige Ressourcenverschwendung Verzögerter RPC Man kann auch 2 RPCs kombinieren. Der Cleint artet nur auf Acknowledgement und sobald Server fertig ist macht er seinerseits einer RPC zum Cleint und übergibt ihm die Ergebnise.