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

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Wiederholung: Beginn

Wiederholung: Beginn B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP)

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP) Enterprise Applikation Integration und Service-orientierte Architekturen 09 Simple Object Access Protocol (SOAP) Anwendungsintegration ein Beispiel Messages Warenwirtschaftssystem Auktionssystem thats

Mehr

Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java

Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java von Christian Brand Kennnummer: 09376 November 2005 Abkürzungen Abkürzungen API - Application Programming Interface

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

Verteilte Systeme: Übung 4

Verteilte Systeme: Übung 4 Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist

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

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2)

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2) Referat im Rahmen des Proseminars Internettechnologie WS 2007/2008 Thema: Web Services und serviceorientierte Architekturen (SOA) vorgelegt von: Intelligente Web Services sind für das Informationszeitalter,

Mehr

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer *Was sind Web Services? *Beispiele für Web Services *Web Service Architektur *Web Services Technologien *Fazit 2 *Übertragungsstandard

Mehr

WSDL. Web Services Description Language. André Vorbach. André Vorbach

WSDL. Web Services Description Language. André Vorbach. André Vorbach André Vorbach WSDL Web Services Description Language André Vorbach Übersicht Was ist WSDL? Dokumentenstruktur Elemente Definitions Types Messages porttype Binding Service SOAP-Bindings Beispiel Was ist

Mehr

3-schichtige Informationssystem-Architektur

3-schichtige Informationssystem-Architektur 3-schichtige Informationssystem-Architektur plattformunabhängig beliebige Endgeräte Client als Applikation & Applet XML über SOAP Standard plattformunabhängig objektorientierte Architektur multiuserfähig

Mehr

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

SOA. Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik

SOA. Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik SOA Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik Laderampen müssen passen Modularisieren Softwarearchitektur Modul A Modul B Modul C Modul D Große Anwendung im Unternehmen Modul

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

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

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

.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

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

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

Seminar E-Services WS 02/03 WSDL. Web Services Description Language. Moritz Kleine SES 02 - WSDL

Seminar E-Services WS 02/03 WSDL. Web Services Description Language. Moritz Kleine SES 02 - WSDL Seminar E-Services WS 02/03 WSDL Web Services Description Language SES 02 - WSDL Zum Ablauf Einleitung Webservices und WSDL Grundlagen (XML - Schema und Namespaces) WSDL Syntax Beispiel Zusammenfassung

Mehr

Software Reuse Sommer 2004

Software Reuse Sommer 2004 8. Web Services Peter Sturm Universität Trier Ausgangspunkt Client/Server-Systeme Traditioneller RPC OO-Pendant RMI (CORBA) Probleme Installationbedarf auf Clientseite Aufwendige Installation auf Serverseite

Mehr

Seminarvortrag Serviceorientierte Softwarearchitekturen

Seminarvortrag Serviceorientierte Softwarearchitekturen Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?

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

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

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

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

Web-Sevices : WSDL Entwicklung von Web-Anwendungen

Web-Sevices : WSDL Entwicklung von Web-Anwendungen Web-Sevices : WSDL Entwicklung von Web-Anwendungen Axel Reusch : ar047 MIB page 1 : 50 Agenda! Allgemeines! Prinzip! Anwendung! Details! WSDL und SOAP! Beispiel mit Java! Erweiterungen! Vorteile! Nachteile!

Mehr

Webservices Ein Vortrag von:

Webservices Ein Vortrag von: Webservices Ein Vortrag von: Andreas Münstermann Michael Reiher Markus Buschky Gliederung Einführung in Webservices Technische Grundlagen SOAP UDDI WSDL Sicherheitskonzepte Blick in die Zukunft Einführung

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

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis Heutige Vorlesung SOAP und WSDL in der Praxis Aufbau von WSDL-Beschreibungen Protokoll-Bindungen in WSDL Google-WSDL lesen und erweitern können Vor- und Nachteile von WSDL heute Wie wird SOAP/WSDL verwendet?.net,

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

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2013 CS108 Programmier-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante eines verteilten Systems (also

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

Multiuser Client/Server Systeme

Multiuser Client/Server Systeme Multiuser /Server Systeme Christoph Nießner Seminar: 3D im Web Universität Paderborn Wintersemester 02/03 Übersicht Was sind /Server Systeme Wie sehen Architekturen aus Verteilung der Anwendung Protokolle

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

Asynchrone Webservices mit Axis 1.x in Java

Asynchrone Webservices mit Axis 1.x in Java Asynchrone Webservices mit Axis 1.x in Java 1. Übersicht Architektur Da Webservices nach relativ kurzen Timeouts Anfragen abgearbeitet haben müsse, sind komplexe Anfragen wie sie in der Bioinformatik üblich

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

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

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

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

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

WCF Services in InfoPath 2010 nutzen

WCF Services in InfoPath 2010 nutzen WCF Services in InfoPath 2010 nutzen Abstract Gerade wenn man schreibend von InfoPath aus auf eine SQL-Server Datenbank zugreifen will, kommt man quasi um einen Web Service nicht herum. In diesem Post

Mehr

Thema: Web Services. Was ist ein Web Service?

Thema: Web Services. Was ist ein Web Service? Willkommen zum Component Ware Seminar Thema: Achim Grimm & Fabian Unterschütz Folie 1 Was ist ein Web Service? Web Services sind selbstbeschreibende, modulare Softwarekomponenten im Internet, die sich

Mehr

Web- und Gridservices zur Überwindung von Heterogenität. Bearbeiter: Lei Xia 16.07.2004

Web- und Gridservices zur Überwindung von Heterogenität. Bearbeiter: Lei Xia 16.07.2004 Web- und Gridservices zur Überwindung von Heterogenität Bearbeiter: Lei Xia 16.07.2004 Gliederung Einleitung Formen von Heterogenität Grundlagen Web Services als Schnittstelle zu DBMS Grid Data Services

Mehr

Web-Applications mit SOAP und RSS. Vortrag 8, Jonas Mitschang, 15.6.2005

Web-Applications mit SOAP und RSS. Vortrag 8, Jonas Mitschang, 15.6.2005 Web-Applications mit SOAP und RSS Vortrag 8, Jonas Mitschang, 15.6.2005 Inhalt Motivation Web Applications / Web Services SOAP - Simple Object Access Protocol RSS - Really Simple Syndication Bewertung

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

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

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen?

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? Großer Beleg Christian Wurbs Zwischenbericht http://www.inf.tu-dresden.de/~cw6 cw6@inf.tu-dresden.de Überblick 2 Aufgabenstellung CORBA

Mehr

Technische Anforderungen. zum Empfang. von XML-Nachrichten

Technische Anforderungen. zum Empfang. von XML-Nachrichten Technische Anforderungen zum Empfang von XML-Nachrichten 25.11.2004 Peer Uwe Peters 2 1 Inhaltsverzeichnis 1 INHALTSVERZEICHNIS... 2 2 ZIEL DIESES DOKUMENTS... 3 3 KONTEXT... 3 4 SENDEWEG... 4 5 ERREICHBARKEIT...

Mehr

Implementierung von Web Services: Teil I: Einleitung / SOAP

Implementierung von Web Services: Teil I: Einleitung / SOAP Implementierung von Web Services: Teil I: Einleitung / SOAP Prof. Dr. Kanne - FSS 2007 Carl-Christian Kanne, February 25, 2007 Web Services - p. 1/12 Web Services: Allgemein XML Datenaustauschformat plattformunabhängig

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

Szenario 3: Service mit erweiterter Schnittstelle

Szenario 3: Service mit erweiterter Schnittstelle 2. Hintergrundverarbeitung in Android: Services und Notifications Szenarien für lokale Services Szenario 3: Service mit erweiterter Schnittstelle Ein Service bietet zusätzliche Methoden an, über die sich

Mehr

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing. www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks

Mehr

XML-Webservices & SOAP

XML-Webservices & SOAP Definition Motivation 12.07.2010 Definition Motivation Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface

Mehr

SWT II Projekt. Chat - Anwendung. Pflichtenheft 2000 SWT

SWT II Projekt. Chat - Anwendung. Pflichtenheft 2000 SWT SWT II Projekt Chat - Anwendung Pflichtenheft 2000 SWT i Versionen Datum Version Beschreibung Autor 3.11.2000 1.0 erste Version Dietmar Matthes ii Inhaltsverzeichnis 1. ZWECK... 1 1.1. RAHMEN... 1 1.2.

Mehr

Java Web Services. Seminarunterlage. Version 4.02 vom

Java Web Services. Seminarunterlage. Version 4.02 vom Seminarunterlage Version: 4.02 Version 4.02 vom 4. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

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

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

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Java RMI Remote Method Invocation

Java RMI Remote Method Invocation Java RMI Remote Method Invocation Ziel: Aufruf von Instanzmethoden entfernter Objekte basierend auf Java. Paket: java.rmi und Unterpakete Topologie: RMI Registry RMI Server RMI Client Der Server registriert

Mehr

Information über die WebServices der Parlamentsdienste

Information über die WebServices der Parlamentsdienste Parlamentsdienste Services du Parlement Servizi del Parlamento Servetschs dal parlament Information über die WebServices der Parlamentsdienste Version 4 Verlauf Version Datum Kommentar Person 0.1 25.03.11

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

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

PHP Kurs Online Kurs Analysten Programmierer Web PHP

PHP Kurs Online Kurs Analysten Programmierer Web PHP PHP Kurs Online Kurs Analysten Programmierer Web PHP Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses PHP Modul 1 - Einführung und Installation PHP-Umgebung Erste Lerneinheit Introduzione

Mehr

Man unterscheidet zwischen LAN (Local Area Network) und WAN (Wide Area Network), auch Internet genannt.

Man unterscheidet zwischen LAN (Local Area Network) und WAN (Wide Area Network), auch Internet genannt. Netzwerk Ein Netzwerk wird gebildet, wenn mehrere Geräte an einem Switch mit Netzwerkkabeln angeschlossen werden. Dabei können die einzelnen Geräte miteinander kommunizieren und über ein Netzwerkprotokoll

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Mobility Support by HIP

Mobility Support by HIP Mobile Systems Seminar Mobility Support by HIP Universität Zürich Institut für Informatik Professor Dr. Burkhard Stiller Betreuer Peter Racz 8 Mai 2008 Svetlana Gerster 01-728-880 1 Gliederung OSI und

Mehr

Netzwerk Technologien in LabVIEW

Netzwerk Technologien in LabVIEW Netzwerk Technologien in LabVIEW von Dirk Wieprecht NI Germany Hier sind wir: Agenda Agenda Bedeutung des Ethernet für die Messtechnik Ethernet-basierende Technologien in LabVIEW Low Level- TCP/IP Objekt

Mehr

Ein Vergleich zwischen SCA,JBI und WCF. Marcello Volpi

Ein Vergleich zwischen SCA,JBI und WCF. Marcello Volpi Service Component Architecture Ein Vergleich zwischen SCA,JBI und WCF Marcello Volpi Agenda Einführung Service Component Architecture (SCA) Java Business Integration (JBI) Windows Communication Foundation

Mehr

WSDL. 7363 - Web-basierte Anwendungen WSDL WSDL. Eine Vertiefungsveranstaltung mit Schwerpunkt auf XML-Technologien. Web Services Description Language

WSDL. 7363 - Web-basierte Anwendungen WSDL WSDL. Eine Vertiefungsveranstaltung mit Schwerpunkt auf XML-Technologien. Web Services Description Language Fachhochschule Wiesbaden - Fachhochschule Wiesbaden - 7363 - Web-basierte Anwendungen Eine Vertiefungsveranstaltung mit Schwerpunkt auf XML-Technologien Web Services Description Language 10.06.2004 H.

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

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

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

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

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

ARCHITEKTUR VON INFORMATIONSSYSTEMEN

ARCHITEKTUR VON INFORMATIONSSYSTEMEN ARCHITEKTUR VON INFORMATIONSSYSTEMEN File Transfer Protocol Einleitung Das World Wide Web war ja ursprünglich als verteiltes Dokumentenverwaltungssystem für die akademische Welt gedacht. Das Protokoll

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

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

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

Web-Konzepte für das Internet der Dinge Ein Überblick

Web-Konzepte für das Internet der Dinge Ein Überblick Web-Konzepte für das Internet der Dinge Ein Überblick Samuel Wieland sawielan@student.ethz.ch ETH Zürich Seminar Das Internet der Dinge Historisches Tim Berners-Lee Erster Web-Server Bildquelle: Wikimedia

Mehr

Erlernbarkeit. Einsatzbereich. Preis. Ausführungsort

Erlernbarkeit. Einsatzbereich. Preis. Ausführungsort 1.3 PHP Vorzüge Erlernbarkeit Im Vergleich zu anderen Sprachen ist PHP relativ leicht erlernbar. Dies liegt hauptsächlich daran, dass PHP im Gegensatz zu anderen Sprachen ausschließlich für die Webserver-Programmierung

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

2.5.2 Primärschlüssel

2.5.2 Primärschlüssel Relationale Datenbanken 0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110

Mehr

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de s & Servlet Integration Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Motivation Das Interface Stateful und Stateless s Programmierung einer Stateful

Mehr

TimeMachine. Time CGI. Version 1.5. Stand 04.12.2013. Dokument: time.odt. Berger EDV Service Tulbeckstr. 33 80339 München

TimeMachine. Time CGI. Version 1.5. Stand 04.12.2013. Dokument: time.odt. Berger EDV Service Tulbeckstr. 33 80339 München Time CGI Version 1.5 Stand 04.12.2013 TimeMachine Dokument: time.odt Berger EDV Service Tulbeckstr. 33 80339 München Fon +49 89 13945642 Mail rb@bergertime.de Versionsangaben Autor Version Datum Kommentar

Mehr

Zeiterfassung für Projekte. SOAP-Schnittstelle. Juli 2013 Version 4.7

Zeiterfassung für Projekte. SOAP-Schnittstelle. Juli 2013 Version 4.7 Weil Zeit Geld ist Zeiterfassung für Projekte SOAP-Schnittstelle Juli 2013 Version 4.7 provantis IT Solutions GmbH Siemensstr. 1 71254 Ditzingen Tel. +49 (0)7156/43623-0 Fax. +49 (0)7156/43623-11 zep@provantis.de

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 11 Dr. H. Ehler, S. Wagner 23. Januar 2004 Übungen zu Softwaretechnik Aufgabe 16 Qualitätseigenschaften Broker-Pattern Beurteilen Sie das in Aufgabe 15 benutzte

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

BeamYourScreen Sicherheit

BeamYourScreen Sicherheit BeamYourScreen Sicherheit Inhalt BeamYourScreen Sicherheit... 1 Das Wichtigste im Überblick... 3 Sicherheit der Inhalte... 3 Sicherheit der Benutzeroberfläche... 3 Sicherheit der Infrastruktur... 3 Im

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

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

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

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

TimePunch. TimePunch Command. Benutzerhandbuch 14.08.2013. TimePunch KG, Wormser Str. 37, 68642 Bürstadt

TimePunch. TimePunch Command. Benutzerhandbuch 14.08.2013. TimePunch KG, Wormser Str. 37, 68642 Bürstadt TimePunch TimePunch Command Benutzerhandbuch 14.08.2013 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, TimePunch Command Revisions-Nummer 37 Gespeichert

Mehr

51. Jahrestagung der. Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds)

51. Jahrestagung der. Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds) 51. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds) 10.-14. September 2006, Leipzig DICOM Proy zur Kommunikation von DICOM Objekten über Einrichtungsgrenzen

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