Zustandsgebundene Webservices

Größe: px
Ab Seite anzeigen:

Download "Zustandsgebundene Webservices"

Transkript

1 Universität Paderborn SS 2005 Warburger Str Paderborn Dozent: Prof. Dr. Stefan Böttcher Zustandsgebundene Webservices Proseminar: Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel 1. November 2005 Betreut durch Felix Heine

2

3 Zusammenfassung Das vorliegende Paper stellt einen Standard vor, der es zustandslosen Webservices ermöglicht zustandsgebundene Operationen durchzuführen. Dieser Standard, das sogenannte Webservice Resource Framework (WSRF), ermöglicht erst komplexe Webservice Anwendungen wie Authentifizierung oder Transaktionen. Kern der Lösung ist eine Trennung zwischen den Zustandsinformationen und dem Webservice selbst. Die Zustandsinformationen werden in einer Ressource gespeichert, dessen Name bei jeder Anfrage eines Client an den Server mitübertragen wird, damit dieser auf die Zustandsinformationen zugreifen kann. Dieser Standard vereinfacht sowohl die Kommunikation der Komponenten untereinander, als auch die Arbeit beim Softwareentwurf.

4 Inhaltsverzeichnis 1 Einleitung 5 2 Einführung Webservices Service Orientierte Architektur Die eingesetzten Protokolle und Sprachen Die WSDL Sprache Das SOAP Protokoll Protokollarchitektur Umsetzung der Kommunikation Zusammenfassung Zustandsbasierte Webservices Implied Resource Pattern Zustandsbasierte Ressourcen Kommunikation über Endpoint References WS-Resource Lebenszyklus WS-Resource Property Document Zusammenfassung Kontext 21 A Knobelaufgabe fürs Seminar 23 A.1 Aufgabe A.2 Lösung A.2.1 Aufgabe A.2.2 Aufgabe A.2.3 Aufgabe A.3 Kontext Literaturverzeichnis 27 Index 28 4

5 1 Einleitung Die Automatisierung von Prozessen in verteilten Systemen ist keine neue informationstechnologische Entwicklung der letzten Jahre. Es stehen viele Technologien zur Verfügung, die es Programmen ermöglichen über Rechnergrenzen hinweg mit anderen Programmen bzw. Programmteilen zu interagieren. Java RMI, Corba oder DCOM sind nur einige Vertreter dieser Art. Alle diese Systeme haben jedoch den Nachteil, dass die Kommunikationspartner stark aneinander gekoppelt sind und eng aufeinander abgestimmt sein müssen. Interessant ist es Komponenten in einem verteilen System miteinander kommunizieren zu lassen, ohne dass diese Komponenten vorher schwerwiegenden Anpassungen an die Umgebung unterzogen werden müssen, um so auch mit Komponenten zu interagieren, die zur Programmierzeit noch nicht existent waren. Einen Schritt in diese Richtung gehen die Webservices. So werden Webservices bevorzugt in der Kommunikation zwischen Reisebüros und den Buchungssystemen der Fluggesellschaften sowie in Bereichen des Gridcomputing eingesetzt. Webservices sind jedoch prinzipiell zustandslos, dürfen also keine clientbezogenen Informationen abspeichern. Dies führt gerade bei der Authentifizierung, der Einführung von Transaktionen oder anderen zustandsbezogenen Operationen zu Problemen. Das Webservice Resource Framework beschreibt eine Erweiterung der zustandslosen Webservices um zustandsgebundene Operationen. Im nächsten Kapitel werden die grundlegende Funktionsweise und die technische Realisierung von Webservices betrachtet. Zustände spielen hier noch keine Rolle. In Kapitel 3 werden die Konzepte des Webservice Resource Frameworks erläutert. Es wird ein Modell vorgestellt, das es ermöglicht zustandsbasierte Operationen mit Webservices durchzuführen. Das vierte Kapitel ist eine Zusammenfassung und soll Grenzen und Weiterentwicklungen dieser Technologie darstellen. 5

6 2 Einführung Webservices Webservices sind eine Kommunikationstechnologie für verteilte Systeme. Sie definieren eine standardisierte Kommunikation zwischen einem Client und einem Server und ermöglichen das Durchführen von Remote Procedure Calls. Anders als bei einem Mailclient oder einem Webbrowser findet die Kommunikation nur zwischen Applikationen statt, nicht zwischen einem Menschen und einer Applikation. Auch das Serverprogramm wird als Webservice bezeichnet. Dieses zeichnet sich durch folgende Kriterien aus: Die verwendeten Protokolle basieren ausschließlich auf XML, die Kommunikation findet in der Regel über HTTP statt und der Webservice ist über einen eindeutigen Namen, meist in Form einer URI, identifizierbar. Die Kommunikation ist nachrichtenbasiert, d.h., dass ein Client eine Anfrage an einen Webservice schickt, dieser die Nachricht bearbeitet und die Antwort in eine Nachricht verpackt und zurücksendet. Ein Webservice nutzt nur die Informationen, die in der Nachricht enthalten sind, und ist damit per Definition zustandslos. Dies bedeutet, dass durch einen plötzlichen Neustart des Services kein Informationsverlust auftreten kann, da es keine Informationen gibt, die temporär gehalten werden. 2.1 Service Orientierte Architektur Zentraler Aspekt der Webservicetechnologie ist eine Selbstbeschreibung der angebotenen Methoden, so dass andere Programme den Service nutzen können. Aus diesem Grund hat sich die Service-orientierte Architektur [3, S. 21] für Webservices durchgesetzt. Ein Dienstanbieter, also ein Webservice, reicht seine Beschreibung bei einem Verzeichnisdienst ein. Nun kann ein Client, der einen bestimmten Dienst sucht, eine Anfrage an das Verzeichnis richten. Wird ein passender Service gefunden, so sendet der Verzeichnisdienst die Adresse und die Interface-Beschreibung [3, S. 22] an den Client zurück. Dieser kann nun mittels des Interfaces mit dem Aufrufen von Methoden in dem Webservice beginnen. Alternativ schickt der Verzeichnisdienst nur eine Adresse an den anfragenden Client, und dieser muss den Service direkt auffordern seine Methodendefinitionen zu schicken. Das genaue Verhalten ist implementationsabhängig. 6

7 2.2 Die eingesetzten Protokolle und Sprachen Abbildung 2.1: Service Orientierte Architektur Verzeichnisdienst Dienst wird angefragt/ Adresse wird übermittelt registriert sich Client benutzt den Dienst Server 2.2 Die eingesetzten Protokolle und Sprachen Die oben dargestellte Kommunikation findet über das Simple Object Access Protocol (SOAP) statt (siehe Abbildung 2.2). Die Webservice Description Language (WSDL 1 ) wird für die Schnittstellendefinition eingesetzt, die beim Bekanntgeben des Dienstes und bei der Servicesuche übertragen wird. Die eigentlichen Methodenaufrufe finden ausschließlich über SOAP statt. Abbildung 2.2: Nutzung des SOAP Protokolls Verzeichnisdienst WSDL-Dokumente über SOAP WSDL-Dokumente über SOAP Client Methodenaufruf über SOAP Server 1 gesprochen: Whistle 7

8 2 Einführung Webservices Sowohl WSDL als auch SOAP sind XML -basiert. Dies führt zum einen zu Plattformunabhängigkeit, da XML Dateien überall einfach geparst werden können, zum anderen aber zu einem erhöhten Kommunikationsoverhead, da Binärformate platzsparender sind Die WSDL Sprache Mit Hilfe eines WSDL Dokumentes [5] kann ein Webservice die Spezifikation seiner angebotenen Methoden an andere Teilnehmer weitergeben. Listing 2.1: WSDL Dokument (Pseudocode) 1 <Type> 2 <ComplexType Name= MyInteger > 3 <Element Name= value Type= i n t /> 4 </ ComplexType> 5 </Type> 6 7 <Message Name= addrequest > 8 <Part Name= Number1 Type= MyInteger /> 9 <Part Name= Number2 Type= MyInteger /> 10 </Message> 11 <Message Name= addresponse > 12 <Part Name= r e turn Type= MyInteger /> 13 </Message> <PortType name= Adder > 16 <Operation name= add > 17 <Input message= addrequest /> 18 <Output message= addresponse /> 19 </ Operation> 20 </PortType> <Binding name= Adder type= Adder > 23 <soap:binding s t y l e= rpc t r a n s p o r t= HTTP /> 24 <Operation Name= add > 25 <Input> <body e n c o d i n g S t y l e= schemas. xmlsoap. org / soap / encoding / /> </ Input> 26 <Output> <body e n c o d i n g S t y l e= schemas. xmlsoap. org / soap / encoding / /> </Output> 27 </ Operation> 28 </Binding> <Service name= Adder > 31 <Port Binding= Adder name= AdderService > 8

9 2.2 Die eingesetzten Protokolle und Sprachen 32 <address l o c a t i o n= s e r v e r. com:80 /Adder /> 33 </Port> 34 </ Service> Ein WSDL Dokument besteht im wesentlichen aus fünf Bestandteilen: Den Typdefinitionen, den Nachrichtendefinitionen, den PortType Definitionen, dem Binden von Protokollen an die PortTypes (Bindings) und dem Konstrukt, das einem solchen Binding eine Adresse zuweist (Service). Über die Type Attribute ist es möglich, komplexere Datentypen zu erstellen, die beliebig viele andere komplexe und Basisdatentypen enthalten können. In diesem Beispiel ist nur eine Wrapperklasse für einen int namens MyInteger angelegt worden, der im Element value die eigentliche Zahl hält. Die Message Attribute legen das Format der Nachrichten fest, die vom Service empfangen und gesendet werden können. In den Parametern werden die zuvor erstellten Datentypen wieder aufgegriffen. Da die Nachrichten einen Remote Procedure Call darstellen, kann eine Anfragenachricht mehrere Parameter enthalten. Die Antwort kann jedoch nur eine Variable beinhalten, obwohl theoretisch auch mehrere Variablen im XML Dokument Platz finden würden. Der Typ der Variablen unterliegt jedoch keinen Beschränkungen, kann also auch ein komplexer Typ sein, der mehrere Werte enthält. Diese Variable hat immer den Namen return. Über den PortType werden einzelne Nachrichten zu Operationen zusammengefasst. In der Regel besitzt jede Operation eine Input und eine Output Nachricht. Es können jedoch alle Kombinationen von Input und Output Nachrichten auftreten. Dazu zählt auch die Vertauschung von Input und Output. So würde eine Operation beschrieben, die vom Server ausgeht und eine Antwort vom Client erwartet. Ein soches Verhalten wird z.b. von WS-BaseNotification[6] benutzt um Clients asynchron über Ereignisse zu informieren. Dabei nimmt der Client die Rolle des Notification Consumers ein, der dem Webservice (Notification Producer) eine Referenz auf sich selbst, und die Ereignisse, über die er informiert werden möchte, übergibt. Das Binding legt die zu verwendenden Protokolle und die benutzten Codierungen fest. Dabei bezieht sich ein Binding auf einen zuvor definierten PortType. Der Service Tag ist die höchste Ebene der Verschachtelung. Er beschreibt die volle Funktionalität des Webservices und gibt ihm einen Namen. In ihm werden Ports gebildet, die einem Binding eine Adresse zuweisen. Über diese Adresse können die Methoden unterhalb des Bindings aufgerufen werden. Die Adresse sieht wie eine ganz normale Web- Adresse aus, was nicht zuletzt an der Verwendung der selben Transporttechnologie TCP und HTTP, liegt. In einem Webbrowser eingegeben liefert die Adresse eines Webservices aber keine vernünftigen Informationen, wenn überhaupt. 9

10 2 Einführung Webservices Das SOAP Protokoll SOAP ist ein Protokoll, dass dazu eingesetzt wird, die eigentlichen Methodenaufrufe auf dem Server durchzuführen [4]. Jede Nachricht besteht aus einem Head und aus einem Body. Im Head-Bereich werden Metainformationen, wie die eingesetzte Verschlüsselung, Routinginformationen oder die Zugehörigkeit zu einer Transaktion vermerkt. Der Head enthält aber keinerlei Informationen die den Methodenaufruf betreffen. Die Head-Daten werden automatisch vom Protokoll ausgewertet, die Webservice-Applikation braucht sich nicht um die Metadaten zu kümmern. Der Body enthält die Nutzdaten, die an den Webservice zur Interpretation weitergegeben werden. Er enthält den Methodennamen und mögliche Parameter. Auch ist es möglich binäre Anhänge mit zu schicken. Dies geschieht meist unter Verwendung von MIME 2. Eine mögliche SOAP Nachricht zum Aufruf einer Methode könnte so aussehen: Listing 2.2: SOAP Aufruf (Pseudocode) 1 <Envelope> 2 <Head> 3 <Encryption>s s l</ Encryption> 4 </Head> 5 <Body> 6 <add> 7 <Number1> <value>3</ value> </Number1> 8 <Number2> <value>7</ value> </Number2> 9 </add> 10 </Body> 11 </ Envelope> Das Listing ist vereinfacht, so wurden die XML Namespaces nicht berücksichtigt, und die Informationen über XML Version und Encoding entfernt. Diese Informationen sind für das Verständnis der Abläufe nicht notwendig. Nachrichten sind immer in einem envelope Tag eingefasst. Im Head ist hier eine Information zur eingesetzten Verschlüsselung enthalten. Im Body wird die Methode increment mit dem Parameter number aufgerufen, der den Wert 3 hat. 2 Multipurpose Internet Mail Extensions, Standard, der das Kodieren von beliebigen Text- und Binärdateien in einer Textdatei beschreibt. 10

11 2.3 Umsetzung der Kommunikation Protokollarchitektur Das Layerdiagramm in Abbildung 2.3 zeigt die zum Einsatz kommenden Protokolle. Bis einschließlich zum Transport-Layer liegt eine ganz normale TCP/IP Verbindung vor. Interessant ist, dass zwei Anwendungsschichten gestapelt sind, also SOAP, wie auch das Alternativprotokoll XML-RPC, auf HTTP aufsetzen. Dies bietet sich an, da HTTP bzw. HTTPS schon für die Übertragung von Dokumenten über TCP ausgelegt wurde. So brauchte keine Neuentwicklung stattfinden. Durch die Popularität des HTTP Protokolls ist auch ein Höchstmaß an Plattformunabhängigkeit gegeben. Abbildung 2.3: Übersicht der Protokolle SOAP XML-RPC http https... TCP IP Ethernet Token Ring FDDI Umsetzung der Kommunikation Die Nachrichten werden über das HTTP Protokoll ausgetauscht. So können Probleme mit Firewalls umgangen werden, die die meisten anderen Technologien, wie z.b. Java RMI, haben. Webservices funktionieren grundsätzlich wie die anderen oben erwähnten Technologien. Es werden auf Client- und auf Serverseite Stubs eingeführt, die für das lokale Programm einen Repräsentanten der Gegenseite darstellen, transparent eine Verbindung herstellen und die Nachrichten abschicken, die der Gesprächspartner auswerten soll (siehe Abbildung 2.4. Probiert der Client einen Remote Procedure Call durchzuführen, so ruft er die Methode auf einem lokalen Repräsentaten auf. In Java kann dies eine Objektinstanz von dem entfernten Objekt sein. Dieses Dummyobjekt, der Stub, baut nun selbstständig eine Verbindung zum Server auf und teilt ihm mit, dass eine Methode ausgeführt werden soll. In diesem Fall wird der Client-Stub dazu eine SOAP Nachricht verschicken. Der Server Stub nimmt diese Nachricht entgegen, interpretiert sie und startet die geforderte lokale Methode mit den mitgeschickten Parametern. 11

12 2 Einführung Webservices Abbildung 2.4: Kommunikation über Stubs Client Methodenaufruf Server realer Aufruf Stub repräsentiert http über TCP/IP repräsentiert realer Aufruf Stub Die Stubs muss sowohl der Client als auch der Server generieren, wenn es Änderungen am Programm gegeben hat. Jedes Programm benötigt einen Stub. Dies führt gerade auf der Serverseite zu Unannehmlichkeiten, da für jeden Webservice ein eigener Stub aktiv sein müsste, der Verbindungen entgegennehmen kann. Um solche Konflikte zu vermeiden ist auf der Serverseite ein universeller Stub, die sogenannte SOAP-Engine aktiv. Abbildung 2.5: SOAP-Engine als Stubersatz Client realer Aufruf Stub repräsentiert Methodenaufruf http über TCP/IP repräsentiert Server Webserver Applikation- Server SOAP Engine Webservice Webservice Webservice Auf der Serverseite kann man auf viele Standardserver zurückgreifen und muss so nicht alle Funktionalitäten in dem Stub halten. Ein Webserver kümmert sich um das Empfangen und Senden der HTTP Nachrichten und reicht diese an einen Applikations Server, wie z.b. einen Tomcat Server, weiter. In diesem läuft die SOAP-Umgebung als ein übergeordneter Prozess. Der eigentliche Webservice kann in diesem Fall eine normale Java Applikation sein, deren Methoden von der SOAP-Umgebung aufgerufen werden, wenn diese die eingehenden Nachrichten interpretiert. Das Modell sieht bei anderen Sprachen 12

13 2.4 Zusammenfassung identisch aus. 2.4 Zusammenfassung Webservices sind eine Technologie um standardisiert Remote Procedure Calls in lose gebundenen Netzen durchzuführen. Dabei werden XML Nachrichten per HTTP übertragen, die durch die Protokolle SOAP und WSDL beschrieben werden. Durch den Einsatz dieser Protokolle und Transporttechnik sind Webservices plattformunabhängig. Webservices können keine Informationen vom Client speichern und sind somit zustandslos. 13

14 3 Zustandsbasierte Webservices Webservices sind grundsätzlich zustandslos, d.h., dass die Antwort nur von den Informationen abhängt, die der Client in seiner Anfrage mitgeschickt hat. Dies gilt auch für Webservices, die eine externe Datenquelle mitbenutzen, wie z.b. eine Datenbank für Telefonbucheinträge. Sie werden bei gleichem Namen immer die gleiche Telefonnummer als Antwort zurückschicken. Ein Verhalten, dass sie beim zweiten Aufruf eine andere Nummer von einer Person mit dem gleichen Namen liefern, ist nicht möglich. Sie können sich also nicht Informationen über einen Aufruf hinweg merken. Diese Unfähigkeit der Informationsspeicherung geht mit einer Vielzahl von Unannehmlichkeiten einher. Authentifizierung gestaltet sich als recht umständlich und unsicher, da die identifizierenden Informationen in jeder Nachricht enthalten sein müssten. Auch ist so keine Möglichkeit für Transaktionen gegeben. Abgesehen davon benötigen viele Anwendungen ein Gedächtnis auf der Serverseite. Als Beispiel dafür wird der in Kapitel 2 vorgestellte Addierer um zustandsgebundene Operationen erweitert. Die beiden zu addierenden Zahlen sollen jetzt nicht nur selbst addiert werden, sondern das Ergebnis soll auf das Ergebnis der vorherigen Addition aufaddiert werden. So werden einer Summe bei jedem Aufruf zwei weitere Summanden hinzugefügt. Abbildung 3.1: Zustandsbasierter Addierer 1,4 5 Client 7,3 15 3,2 20 Adder Viele Probleme ließen sich bisher nicht ohne die Benutzung von Zuständen lösen, was eine ganze Menge von unterschiedlichen Implementationen zur Folge hatte. Da die Informationen zur Zustandsverwaltung im Body der SOAP-Nachrichten auftauchen mussten, 14

15 3.1 Implied Resource Pattern hatte jeder Webservice Routinen zur Verarbeitung dieser Daten zu implementieren. Die Standardisierung über das Webservice Resource Framework ermöglicht zum einen die Verlagerung vom Body in den Header der Nachricht. Dies führt dazu, dass schon das SOAP Protokoll einen Teil der Verwaltungsarbeit übernehmen kann. Zum anderen wird schon in der Interfacedefinition auf die Verwendung von Ressourcen hingewiesen, die Zustandsinformationen speichern. Dies verbessert die Serviceauswahl während der Applikationserstellung, da die Services viel exakter beschrieben werden können. Designfehler können so vermieden werden, da das Verhalten klarer darstellbar ist. Ein weiterer Vorteil ist die Interoperabilität, die so zwischen Webservices gegeben ist, die WSRF-konform ihre Ressourcen benutzen. Die Zustandslosigkeit bietet jedoch auch einige Vorteile, die Webservices ziemlich robust machen. Der Service kann jederzeit neu gestartet oder durch einen anderen ersetzt werden, ohne dass Informationen verloren gehen können. Die Entwicklung von kleineren Applikationen ist so extrem einfach. Da auf die Vorteile der Zustandslosigkeit nicht verzichtet werden soll, die Nachteile aber ausgeräumt werden sollen, muss ein geschickter Ausweg gefunden werden: Die Zustandsinformationen werden auf der Serverseite strikt vom Webservice getrennt. 3.1 Implied Resource Pattern Das Implied Resource Pattern beschreibt die Trennung von den Zustandsinformationen und dem Webservice. Die Zustandsinformationen werden in sogenannten Ressourcen gespeichert, die den Zustand für die Kommunikation mit einem Kommunikationspartner repräsentieren Zustandsbasierte Ressourcen Der Zustand eines Computersystem kann durch unterschiedlichste Aspekte beeinflusst werden, z.b. durch Einträge in einer Datenbank, die aktuelle Operation eines Filehandles oder sogar die Temperatur des Prozessors. Um im Hinblick auf den Zustand möglichst flexibel zu bleiben, ist eine Ressource wie folgt definiert: Die Ressource muss einen definierten Satz von Zustandsdaten enthalten, die als ein XML Dokument darstellbar sind. Der erweiterte Addierer aus dem letzten Beispiel hätte in diesem Fall nur ein einziges Element in der Ressource, nämlich das Ergebnis der letzten Addition. Des weiteren besitzt eine Ressource einen festgelegten Lebenszyklus. Die Erstellung einer Ressource kann von einem Client in Auftrag gegeben werden, damit server- 15

16 3 Zustandsbasierte Webservices seitig Informationen für diese Kommunikation gespeichert werden können. Nach der Erstellung muss sichergestellt werden, dass die Ressource wieder freigegeben wird. Die letzte Anforderung an eine Ressource ist, dass sie mindestens einem Webservice zugeordnet ist, der sie kennt und mit ihr arbeiten kann. Abbildung 3.2: WS-Resource Resourcen Resource 1 WS-Resource Webservice OldSum=5 Resource 2 OldSum=13 Resource 3 OldSum=7 Ein Webservice kann mehrere Ressourcen verwalten (siehe Abbildung 3.2), die er für die Kommunikation mit unterschiedlichen Clients benötigt. Viele unterschiedliche Systemkomponenten können als Ressource modelliert werden, wie z.b. eine Datei im Dateisystem bzw. ein Eintrag in einer Datenbank oder ein gekapseltes Objekt, wie eine Java-Bean. Die konkrete Verbindung von einer Ressource zu einem Webservice nennt man WS- Resource. Findet eine Kommunikation zwischen einem Client und einem Server statt, so kann dies nur unter der Berufung auf eine spezielle WS-Resource geschehen. Es müssen folglich die Protokolle angepasst werden, um dies zu gewährleisten Kommunikation über Endpoint References Für die zustandsgebundene Kommunikation ist eine Ressource auf der Serverseite notwendig, die die notwendigen Informationen speichert. Diese Ressource bezieht sich in der Regel auf einen speziellen Client, und muss zunächst angelegt werden. Die Erstellung einer neuen Ressource kann entweder durch eine explizite Anweisung des Clients oder indirekt durch eine Nachricht, die in einem zustandsgebundenen Kontext 16

17 3.1 Implied Resource Pattern steht, ausgelöst werden. Legt ein Webservice Ressourcen an, so wird er als Factory bezeichnet. Als Resultat der Erzeugung schickt er eine Endpoint Reference an den Client zurück, die die WS-Resource, bestehend aus dem Webservice und der neu angelegten Ressource, addressiert. Listing 3.1: EndpointReference (Pseudocode) 1 <EndpointReference> 2 <Address> 3 s e r v e r. com:80 /Adder 4 </ Address> 5 <R e f e r e n c e P r o p e r t i e s> 6 <ResourceID> </ ResourceID> 9 <R e f e r e n c e P r o p e r t i e s> 10 <EndpointReference> Die Endpoint Reference ist ein zweigeteiltes Konstrukt. Sie besteht aus der Adresse des Webservices und aus einem ReferenceProperties Block. Die Adresse ist bereits in Kapitel 2 erwähnt worden, ist also identisch mit dem Eintrag im Port der WSDL Beschreibung des Webservices und enthält keine weiteren Informationen. Von größerer Bedeutung ist der ReferenceProperties Block. Er kann unterschiedliche zusätzliche Informationen zu der Adresse beinhalten. In diesem Fall spielt nur die ResourceID eine Rolle. Sie identifiziert im Kontext des Webservices eindeutig eine WS- Resource. Enthält eine Endpoint Reference eine ResourceID, so wird dieser Endpoint als WS-Resource qualified endpoint reference bezeichnet. Die ResourceID muss dem Client mitgeteilt werden, da der Webservice weiterhin zustandslos sein soll und nicht abpeichern darf, welche Ressource er welchem Client zugeordnet hat. Dies hat zur Folge, dass jeder Anfrage, die der Client abschickt, diese Information angehängt werden muss. Dieses Anhängen der ResourceID übernimmt das SOAP Protokoll für den Client automatisch. Die ResourceID wird in den Header der Nachricht aufgenommen. Listing 3.2: Zustandsbasierte SOAP Anfrage (Pseudocode) 1 <envelope> 2 <head> 3 <encryption>s s l</ encryption> 4 <resourceid> </ resourceid> 5 </ head> 6 <body> 7 <add> 8 <Number1> <value>3</ value> </Number1> 9 <Number2> <value>7</ value> </Number2> 17

18 3 Zustandsbasierte Webservices 10 </add> 11 </ body> 12 </ envelope> So könnte eine Anfrage aussehen, die der erweiterte Addierer sendet. Für die Anwendung sieht es so aus, als ob der Webservice zustandsbasiert arbeiten würde, der Webservice selbst verhält sich aber komplett zustandslos. Aus diesem Grund nennt man diese Art der Modellierung auch Implied Resource Pattern. 3.2 WS-Resource Lebenszyklus Wie bereits oben dargestellt, wird eine Ressource von einer Factory erstellt und muss wieder zerstört werden. Die Lebenszeit einer Ressource ist somit die Zeit von der Erstellung bis zur Zerstörung. Zum Lebenszyklus gehören folglich drei Abschnitte: Die Erstellung, die Zuweisung eines Identifiers zur WS-Resource und schließlich die Zerstörung. Die Factory erstellt die Ressource und liefert eine WS-Resource Qualified Endpoint Reference zurück. Dabei muss nicht zwangsläufig jeder Webservice, der eine Referenz liefert, eine Factory sein, da diese auch von Verzeichnisdiensten verschickt werden können, die aber nicht an der Erstellung der Ressourcen beteiligt sind. Die Factory gibt der neu erstellten Ressource einen Namen und speichert diesen ab. Dieser Name kann nun als Bezeichnung für die WS-Resource übernommen werden, muss aber nicht. Die Identität einer WS-Resource lässt sich auf zwei Sichtweisen betrachten. Zum einem vom Inneren des Webservices aus, zum anderen aus der Sicht des Clients. Für den Webservice hat der Identifier eine Bedeutung, er kann mit ihm auf die Identität der Ressource schließen. Für den Client ist der Identifier nur ein String, der in der Nachricht mitübertragen wird. Selbst das Vergleichen von unterschiedlichen Identifiern wird auf der Clientseite als ungültig bezeichnet. Der Client hat somit keine Möglichkeit die Identität der Ressource zu bestimmen. Ob der Client die Identität der Ressource abfragen kann, ist implementierungsabhängig. In diesem Fall muss sichergestellt werden, dass nur ein lesender Zugriff auf die Ressource möglich ist, da ein direktes Verändern des Zustandes verhindert werden muss. Ein Webservice könnte so Methoden zur Verfügung stellen um Ressourcen zu vergleichen. Wenn ein Client eine neue Ressource anfordert, so ist er normalerweise nur eine bestimmte Zeit an dieser interessiert. Nach dieser Zeit sollten die Systemressourcen des Servers wieder freigegeben werden. Es gibt zwei Möglichkeiten die Zerstörung durchzuführen. Der Client schickt, nachdem er alle Operationen durchgeführt hat, eine Zerstörungsnachricht indem er den WS-Resource Qualified Endpoint benutzt. Der Webservice kann so die Res- 18

19 3.3 WS-Resource Property Document source identifizieren und zerstören. Jede weitere Anfrage an diesen Endpoint wird mit einer Fehlermeldung beantwortet, dass die WS-Resource nicht existiert. In einigen Fällen hat der Client nicht die Möglichkeit die Ressource explizit zu zerstören. Dies ist der Fall, wenn man mit dem Ausfall der Verbindung oder des Clients rechnen muss. Ein denkbares Szenario sind per Funk angebundene Clients. In solchen Fällen besitzt die Ressource eine vordefinierte Lebenszeit, die der Client verlängern kann. Erledigt der Client dies nicht in der angegebenen Zeit, so wird die Ressource vom Webservice selbstständig zerstört. 3.3 WS-Resource Property Document Der Zustand einer Ressource kann durch mehrere Werte festgelegt sein. Der Zustand eines Punktes im Raum ist beispielsweise durch drei Koordinaten und eine Zeitangabe festgelegt. Der Client muss die Möglichkeit haben, die Werte einer Ressource auszulesen und notfalls zu verändern. Er benötigt also Informationen über den Aufbau der Ressource, die für ihn von der Factory angelegt wurde. Diese Informationen sind im WS-Resource Property Document abgelegt. Es enthält die Namen und Typen der Werte, die für den Zustand definierend sind und vom Client gelesen werden dürfen. Der Addierer aus den Beispielen besitzt nur einen einzigen Wert, der den Zustand definiert, und zwar das Ergebnis der letzten Summe. Listing 3.3: WS-Resource Property Document (Pseudocode) 1 <Schema> 2 <Element Name= oldsum type= MeinInteger /> 3 4 <Element Name= AdderResourceProperties > 5 <ComplexType> 6 <Element r e f= oldsum /> 7 <ComplexType> 8 </Element> 9 </Schema> Zunächst werden die einzelnen Typen, mittels Element Tags, definiert und diese dann zu einem Eintrag für die Ressource zusammengefasst. Der ComplexType Eintrag kann dabei auch beliebig viele Typen enthalten, um die Ressource exakt zu modellieren. 19

20 3 Zustandsbasierte Webservices 3.4 Zusammenfassung Um die Eigenschaften der Zustandslosigkeit mit den Funktionalitäten der Zustandsgebundenheit zu kombinieren wird die Ressource, die die Zustandsinformationen enthält, vom Webservice getrennt behandelt. Diese Trennung nennt man Implied Resource Pattern. Die Verbindung von einer Ressource und einem Service nennt man WS-Resource. Die WS-Resource bekommt einen eindeutigen Identifier, der in einer Endpoint Reference dem Client mitgeteilt wird. Der Client sendet diese ResourceID im Header jeder SOAP Nachricht mit, damit der Server die passende Ressource zuordnen kann. Abbildung 3.3: Gesamtüberblick Verzeichnisdienst = SOAP WSDL-Dokument WSDL- Dokument verlinkt Client RPC XML über HTTP Server [Factory] RPD WS1 erstellt WS-Resource qualified Endpoint WS2 WS-Resource Ressourcen Das Resource Properties Document enthält die Struktur der Informationen, die den Zustand in den Resourcen darstellt. Da es im WSDL Dokument verlinkt ist, stehen dies Informationen den Entwicklern und damit dem Client zur Verfügung. 20

21 4 Kontext Das WSRF erwähnt einige weitere Standards, die in dieser Arbeit nicht weiter ausführlich behandelt, an dieser Stelle jedoch erwähnt werden sollen. [1] Dazu gehört zum einen WS-Renewable-References. Dieser Standard definiert einen Mechanismus, mit dem eine Endpoint-Referenz erneuert werden kann, wenn diese ungültig geworden ist. So wird einem Client die Möglichkeit gegeben zu jedem Zeitpunkt auf die gleiche Ressource erneut zugreifen zu können. Dies ist gerade in Umgebungen wichtig, in denen Kommunikationsrichtlinien in der Endpointreferenz mitübertragen werden, die das Verhalten der Kommunikationspartner reglementieren. Sollten sich diese Richtlinien während des Nachrichtenaustausches verändern, muss die Endpointreferenz erneuert werden. WS-Notification erlaubt es dem Client sogenannte topics auf dem Server zu abonieren, mit deren Hilfe er sich asynchron vom Webservice benachrichtigen lassen kann. Dies ist besonders dann sinnvoll, wenn der Client auf die Veränderung einer Ressource wartet. WS-ServiceGroup legt Regeln fest, wie Webservices zu Gruppen zusammengefasst werden können. So kann es einer Gruppe von Webservicen erlaubt werden eine bestimmt Menge von WS-Resourcen kollektiv zu bearbeiten. Obwohl die Möglich der Zustandsspeicherung gegeben ist unterliegt das WSRF Grenzen. Authentifizierung und Transaktionen in verteilten Systemen benötigen eine serverseitige Speicherung von Informationen. Den Authentifizierungsvorgang selbst, oder den Ablauf einer Transaktion beschreibt das Framework jedoch nicht. Es ist viel mehr als eine Grundlage für andere Spezifikationen zu verstehen. Die obengengenannten Funktionen sind in WS-Auth und WS-AtomicTransaction[7] spezifiziert. WS-AtomicTransaction stellt die ACID Eigenschaften für die Kommunikation mit dem Webservice sicher. Der Client bekommt nun die Möglichkeit eine Transaktion zu starten und diese zu commiten, oder einen Abbruch (Abort) durchzuführen. Bis zum Commit sind die Veränderungen am Datenbestand nicht für andere Aktivitäten sichtbar. Der Standard beinhaltet drei mögliche Protokolle wie z.b. das Zwei-Phasen-Commit Protokoll. Das Konzept des WSRF ist nicht unter dem Aspekt der Sicherheit entworfen worden. So kann ein Angreifer durch das Abfangen einer einzigen Nachricht die Session übernehmen, die an die Resource-ID genüpft ist. Der Standard WS-Security füllt diese Lücke indem er durch Verschlüsselung die Übertragung sicherer gestaltet. Hierbei zeichnet sich ein 21

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

Web Services mit Java

Web Services mit Java Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08 XML-RPC & SOAP & Fabio Caprera Systemprogrammierung SS 08 Inhalt XML-RPC Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile SOAP Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Mobile und Verteilte Datenbanken

Mobile und Verteilte Datenbanken Mobile und Verteilte Datenbanken Java RMI Vorlesung Wintersemester 2013/2014 groppe@ifis.uni-luebeck.de Institut für Informationssysteme Universität zu Lübeck Kommunikations-Middleware Bietet höhere Kommunikations-Dienste

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Termin 4: Web Services Computing

Termin 4: Web Services Computing Arbeitsgruppe Übung Netzbasierte Informationssysteme Termin 4: Web Services Computing Prof. Dr. Adrian Paschke Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin

Mehr

Securing SOAP e-services

Securing SOAP e-services Securing SOAP e-services Nilson Reyes Sommersemester 2004 aus: E. Damiani, S. De Capitani di Vermercati, S. Paraboschi, P. Samarati, Securing SOAP e-sservices, IJIS, Ausgabe 1 (2002), S.110-115. Gliederung

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Block Web-Dienste. Beispiel: ohne Browser. ohne Browser. Beispiel: Definition

Block Web-Dienste. Beispiel: ohne Browser. ohne Browser. Beispiel: Definition Block Web-Dienste Web-Dienste Klaus Schild, 2004 1 heutige Vorlesung Was sind Web-Dienste (Web Services)? diensteorientierte Architekturen Was ist SOAP, WSDL und UDDI? Entfernte Prozeduraufrufe (RPCs)

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

Der Einsatz von CORBA in verteilten EDA-Tools

Der Einsatz von CORBA in verteilten EDA-Tools Der Einsatz von CORBA in verteilten EDA-Tools Frank Grützmacher Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Fachgebiet Mikroelektronische Schaltungen und Systeme

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

Howto. Konfiguration eines Adobe Document Services

Howto. Konfiguration eines Adobe Document Services Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Web Services. Dr. Wolfgang Süß

Web Services. Dr. Wolfgang Süß Service-orientierte Architektur (SOA) Architekturkonzept, da sich aus Diensten zusammensetzt. 3 Komponenten: Konnektoren: register Registrierung eines Dienstes bei einer Registry find Suchanfrage eines

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 2 05.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Das

Mehr

Web-Services Implementierung mit Java

Web-Services Implementierung mit Java Web-Services Implementierung mit Java J. Heinzelreiter WS 2004/05 Java-APIs für Web-Services (1) Anwendungs-Code JAXR JAXM JAX-RPC SAAJ SOAP/SwA JWSDL WSDL XML/XML-Schema Web-Services/Java - 2 Java-APIs

Mehr

Musterlösung Klausur SS 2004

Musterlösung Klausur SS 2004 Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

SOA, Webservices und SOAP für Schnelleinsteiger

SOA, Webservices und SOAP für Schnelleinsteiger SOA, Webservices und SOAP für Schnelleinsteiger (C)opyright 2005 by Jochen Vajda Inhalt Einführung I. Was ist SOA? II. Webservices, SOAP und WSDL SOAP mit PHP5 I. Benötigte Komponenten II. Client ohne

Mehr

SNMP und der MIB- Browser von MG-Soft

SNMP und der MIB- Browser von MG-Soft SNMP und der MIB- Browser von MG-Soft 1. SNMP 1.1 Was ist SNMP 1.2 Historie von SNMP 1.3 Einordnung in das OSI-Modell 1.4 Die Architektur von SNMP 1.5 Kommunikation von SNMP 1.6 SNMP-PDUs PDUs 2. MIB und

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Ein einfacher Server. .NET Remoting. Klassentypen

Ein einfacher Server. .NET Remoting. Klassentypen Einführung - eine Klienten-Applikation kann mit einer Komponente interagieren die hinter einer Grenze liegt - Remoting ermöglicht eine Kommunikation von Komponenten Kontext-, Applikationsdomänen- (leichtgewichtiger

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de XML-RPC, SOAP und Web Services Jörn Clausen joern@techfak.uni-bielefeld.de Übersicht Was ist RPC? Was hat XML mit RPC zu tun? Was sind XML-RPC und SOAP? Was sind Web Services? Wird das die Welt retten?

Mehr

Mehr als eine Email auf einem Rechner

Mehr als eine Email auf einem Rechner Vortrag PC Treff Böblingen am 12.02.2005 Email-Server daheim oder Mehr als eine Email auf einem Rechner Andreas Hoster Standard-Email (HTTP / IMAP Online) Damit ist der Standard-Online Zugriff via HTTP

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Client/Server-Systeme

Client/Server-Systeme Client/Server-Systeme Prof. Dr.-Ing. Wilhelm G. Spruth SS 2005 Teil 16 RMI, DCOM, Webservices cs 1100 ww6 sch 05-97 Remote Method Invocation (RMI) JVM JVM Client Server Stub Java Remote Skeleton Method

Mehr

KompaSbilität zu Standards (WS- I) Contracts. Interfaces und Generics Umfangreiche AXribuSerung. Mehr Spielraum auf Transportebene

KompaSbilität zu Standards (WS- I) Contracts. Interfaces und Generics Umfangreiche AXribuSerung. Mehr Spielraum auf Transportebene Komponenten WCF (.NET Framework) WCF Verfeinerung und Reifung der ursprünglichen Version Geringere Unterschiede zu ASMX 2.0 (.NET 2.0) + WSE 3.0 Schwerpunkte KompaSbilität zu Standards (WS- I) Contracts

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Tutorial zu WS-BPEL Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Universität Hamburg Department Informatik Arbeitsbereich VSIS Gruppe 01: Johannes Kuhlmann,

Mehr

FuE-Bereich IuK-Systeme im Gesundheitswesen

FuE-Bereich IuK-Systeme im Gesundheitswesen FuE-Bereich IuK-Systeme im Gesundheitswesen IG XML und Web Services Dipl.-Inform. Axel Schwolow IG Kommunikation im Web Entwicklung früher ausschließlich Kommunikation über Browser heute zunehmend direkt

Mehr

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät NAT und Firewalls Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April 2005

Mehr

Grundlagen zum Internet. Standarddienste der Bürowelt

Grundlagen zum Internet. Standarddienste der Bürowelt Grundlagen zum Internet Grundlagen zum Internet Standarddienste der Bürowelt Lehrstuhl für Automatisierungstechnik Dr.-Ing. A. Braune SS05 - Bra Übersicht Dienste Offene Standards der Bürowelt (z.b. Web,

Mehr

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle Version: 1.0.0 Datum: 2013-11-20 Autor: Bernd Ennsfellner, Renate Pinggera gizmocraft, design and technology GmbH

Mehr

Verteilte Systeme - 1. Übung

Verteilte Systeme - 1. Übung Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)

Mehr

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus]

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] ESB Open Source ESB: Mule Flightreservation Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] Inhalt 1. Open Source ESB: Mule... 2 1.1. Überblick... 2 1.1.1. Das Beispiel Zeigt:... 2 1.2. Installationsanleitung...

Mehr

Software Engineering Interaktionsdiagramme

Software Engineering Interaktionsdiagramme Software Engineering Interaktionsdiagramme Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Nachrichtenaustausch Welche Nachrichten werden ausgetauscht? (Methodenaufrufe)

Mehr

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST 2. Interaktive Web Seiten GET und POST Die Übertragungsmethoden GET und POST sind im http Protokoll definiert: POST: gibt an, dass sich weitere Daten im Körper der übertragenen Nachricht befinden: z.b.

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Handbuch Notruf. Notrufe über Voice over IP: Grundlagen und Praxis. www.handbuch-notruf.at. Karl Heinz Wolf nic.at GmbH. Ausschnitt aus dem

Handbuch Notruf. Notrufe über Voice over IP: Grundlagen und Praxis. www.handbuch-notruf.at. Karl Heinz Wolf nic.at GmbH. Ausschnitt aus dem Karl Heinz Wolf nic.at GmbH Ausschnitt aus dem Handbuch Notruf Notrufe über Voice over IP: Grundlagen und Praxis www.handbuch-notruf.at Handbuch Notruf 3 4 IETF-Notrufarchitektur Bei der IETF wird derzeit

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Ausarbeitung des Interpreter Referats

Ausarbeitung des Interpreter Referats Ausarbeitung des Interpreter Referats Gliederung 1. Programmiersprache 1.2. Syntax 1.2.1. Konkrete Syntax 1.2.2. Abstrakter Syntax Baum (Abstrakte Syntax) 2. Parser 2.1. Syntaktische Struktur einer Sprache

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler Web Services and Semantic Web - Introduction to Web Services von Andreas Weiler Definitionen Beispiele Technologien Vorteile Kritik Abschlussbeurteilung Fragen? Definition von IBM: Web services are a new

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Enterprise JavaBeans

Enterprise JavaBeans Enterprise JavaBeans Sebastian Pipping 18. Dezember 2006 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. Teil I J2EE J2EE Was ist J2EE? Was ist J2EE?

Mehr

XMPP: Extensible Messaging and Presence Protocol

XMPP: Extensible Messaging and Presence Protocol XMPP: Extensible Messaging and Presence Protocol (aka Jabber) 5. Dezember 2005 Einleitung Was ist XMPP? Architektur Allgemeines Kommunikation via XMPP: Streams, Stanzas Beispielanwendung

Mehr

R e m o t e A c c e s s. Cyrus Massoumi

R e m o t e A c c e s s. Cyrus Massoumi R e m o t e A c c e s s Präsentation im Seminar Internet-Technologie im Sommersemester 2008 von Cyrus Massoumi I n h a l t Was versteht man unter Remote Access Unsichere Remotezugriffe TELNET Remote Shell

Mehr

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System)

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System) -DNS (Domain Name System) Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Konzepte von Betriebssystem-Komponenten Middleware:.NET Remoting

Konzepte von Betriebssystem-Komponenten Middleware:.NET Remoting Konzepte von Betriebssystem-Komponenten Middleware:.NET Remoting André Frimberger 16.11.2004 1 Was ist.net Remoting?.NET Remoting ist ein Framework aus.net, welches die Interprozesskommunikation zwischen

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

JAXR Java API for XML Registries. Jasmin Hatteh

JAXR Java API for XML Registries. Jasmin Hatteh JAXR Java API for XML Registries Jasmin Hatteh Übersicht Web Service Architektur Rollenverteilung Interaktionen Business-Registry UDDI ebxml JAXR Architektur Interaktionen Pakete Was sind Web Services?

Mehr

VPN mit Windows Server 2003

VPN mit Windows Server 2003 VPN mit Windows Server 2003 Virtuelle private Netzwerke einzurichten, kann eine sehr aufwendige Prozedur werden. Mit ein wenig Hintergrundwissen und dem Server- Konfigurationsassistenten von Windows Server

Mehr

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 1 Verteilte Systeme Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 2 Verteilte Systeme 1. Innovative Beispiele aus der Praxis 2. Allgemeine Anforderungen und Techniken verteilter Systeme

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Service Oriented Architecture Teil 2. Web Services

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Service Oriented Architecture Teil 2. Web Services UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Service Oriented Architecture Teil 2 Web Services el0100 copyright W. G. Spruth, wgs 04-09

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Analyse von Sicherheitaspekten in Service-orientierten Architekturen

Analyse von Sicherheitaspekten in Service-orientierten Architekturen Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

TCP/IP-Protokollfamilie

TCP/IP-Protokollfamilie TCP/IP-Protokollfamilie Internet-Protokolle Mit den Internet-Protokollen kann man via LAN- oder WAN kommunizieren. Die bekanntesten Internet-Protokolle sind das Transmission Control Protokoll (TCP) und

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Markus Dopler Rainer Ruprechtsberger. Security und Trust Aspekte in Service-Orientierten Web-Applikationen

Markus Dopler Rainer Ruprechtsberger. Security und Trust Aspekte in Service-Orientierten Web-Applikationen Markus Dopler Rainer Ruprechtsberger Security und Trust Aspekte in Service-Orientierten Web-Applikationen SOSE: Vision Automatische Auswahl und Integration von angebotenen Services Inhalt Beispiel SOA

Mehr

Grundlagen DNS 1/5. DNS (Domain Name System)

Grundlagen DNS 1/5. DNS (Domain Name System) Grundlagen DNS 1/5 DNS (Domain Name System) Weltweit gibt es 13 zentrale DNS-Server (Root-Nameserver), auf denen die verschiedenen Domains abgelegt sind. Der Domönennamensraum bzw. das Domain Name Space

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Übersicht. Projekt DB-basierte, mobile Systeme. Übersicht. Was sind Web Services? Web Service - Kompakt. Warum das Rad neu erfinden?!

Übersicht. Projekt DB-basierte, mobile Systeme. Übersicht. Was sind Web Services? Web Service - Kompakt. Warum das Rad neu erfinden?! Übersicht HTML Projekt DB-basierte, mobile Systeme JAX-RPC via SOAP Aufgabenblatt 4 Web Services Übersicht Was sind Web Services? "A web service is any service that is available over the Internet, uses

Mehr

ICMP Internet Control Message Protocol. Michael Ziegler

ICMP Internet Control Message Protocol. Michael Ziegler ICMP Situation: Komplexe Rechnernetze (Internet, Firmennetze) Netze sind fehlerbehaftet Viele verschiedene Fehlerursachen Administrator müsste zu viele Fehlerquellen prüfen Lösung: (ICMP) Teil des Internet

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter Datensicherheit Vorlesung 5: 15.5.2015 Sommersemester 2015 h_da, Lehrbeauftragter Inhalt 1. Einführung & Grundlagen der Datensicherheit 2. Identitäten / Authentifizierung / Passwörter 3. Kryptografie 4.

Mehr

Vorlesung - Web Services

Vorlesung - Web Services Vorlesung - IVS Arbeitsgruppe Softwaretechnik Abschnitt 3.1.3 Grundlegende Web Service Technologien Seite 1 - Übersicht UDDI WSDL Requester SOAP over HTTP Provider Seite 2 - Übersicht A web service is

Mehr

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software FTP Übersicht Was ist FTP? Übertragungsmodi Sicherheit Öffentliche FTP-Server FTP-Software Was ist FTP? Protokoll zur Dateiübertragung Auf Schicht 7 Verwendet TCP, meist Port 21, 20 1972 spezifiziert Übertragungsmodi

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr