Entwurf eines Dienstes zur Dokumentenverwaltung auf Basis von Web Services

Transkript

1 Technische Universität Dresden Fakultät für Informatik Institut für Systemarchitektur Professur für Rechnernetze Entwurf eines Dienstes zur Dokumentenverwaltung auf Basis von Web Services Belegarbeit Name Jan Häußler Matrikelnummer Eingereicht am Verantwortlicher Hochschullehrer Wissenschaftliche Betreuerin Prof. Dr. Alexander Schill Dipl.-Inform. Iris Braun

2 Selbständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig verfasst, diese noch nicht anderweitig zu Prüfungszwecken vorgelegt, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie wörtlichen und sinngemäße Zitate als solche gekennzeichnet habe. Dresden, Jan Häußler i

3 Inhaltsverzeichnis 1 Web Services Einführung WSDL Komplexe Datentypen Interfaces Binding Service und Endpoint Modularisierung Zusammenfassung SOAP Das SOAP Nachrichtenformat UDDI Plattformen J2EE NET J2EE versus.net Ressource Description Framework RDF-Modell RDF-Schema Web Ontology Language Anwendungen Dublin Core Metadata Initiative RSS Dokumenten-Management-Systeme Einführung Dokumente Dokumenten-Management-Systeme Funktionsbereich Eingabe Funktion Dokumenteneingang Funktion Indizieren Funktionsbereich Ablage Funktion Verwaltung Funktion Archivierung Funktionsbereich Ausgabe Funktion Recherche Funktion Reproduktion Funktionsbereich Administration Vorhandene Implementierungen ii

4 3.6.1 STS.net Saperion AG Klassifizierung Entwicklung des Dienstes Anforderungsanalyse Grundlegende Strukturen Dokumente und Dokumenten-Management Indizierung Retrieval Zugriffs-Management Monitoring Features Entwurf Ontologien Package doc.documentmanager Package doc.retrievalmanager Package sys.accessmanager Package sys.monitormanager Package sys.toolmanager Fazit und Ausblick Anhang Verwendete Software iii

5 Abbildungsverzeichnis 1.1 Das Web Service Modell Message Exchange Pattern [Dhe05] Das SOAP Nachrichtenformat Das J2EE Schichtenmodell Die Komponenten des.net Frameworks Funktionsbereiche eines Dokumenten-Management-System Grundschema Retrievalfunktion Use Case: Dokument einladen Use Case: Check-Out Use Case Check-In Use Case: Suche Übersicht Dokument-Ontologie Klassendiagramm: Document-State-Beziehung Klassendiagramm: DocumentManager-Schnittstellen Klassendiagramm: RetrievalManager-Schnittstelle Klassendiagramm: AccessManager-Schnittstelle Klassendiagramm: MonitorManager Klassendiagramm ToolManager Klassendiagramm: DocumentManager Klassendiagramm: AccessManager WSDL: AccessManager-Schnittstelle iv

6 Tabellenverzeichnis 1.1 Fault Generation Rules UDDI Kernkomponenten Gegenüberstellung J2EE und.net Container-Elemente des RDF-Modells Klassen des RDF-Schemas Eigenschaften des RDF-Schemas Elemente des Dublin Core Metadata Element Set Ausgewählte Elemente der RSS 2.0 Spezifikation Porter-Stemming Algorithmus Einfache Anwendungsfälle des Dokument-Lebenszyklus Ausführliche Anwendungsfälle des Dokument-Lebenszyklus Anwendungsfälle für die Indizierung Anwendungsfälle für das Retrieval Anwendungsfälle für das Zugriffs-Management Anwendungsfälle für das Zugriffs-Management (2) Anwendungsfälle für das Monitoring Anwendungsfälle für zusätzliche Features v

7 Quellcodeverzeichnis 1.1 Grundstruktur WSDL Dublin Core in RDF/XML Dokument-Ontologie: doc:document WSDL: checkouturi WSDL: adddocumenttocontainer vi

8 Abkürzungsverzeichnis API BCL BPEL4WS BPML CI CLI CLR CLS CTS DCMI DM DMS EAI ECM ECMA EJB FCL HTML HTTP IDM IIS J2EE JDBC JMS JNDI JRE JSP MEP MIME MOM MSIL NCI OCR OWL RAID RDF RDFS RPC SOAP UDDI Application Programming Interface Base Class Libary Business Process Execution Language for Web Services Business Process Management Language Coded Information Common Language Infrastructure Common Language Runtime Common Language Specification Common Type System Dublin Core Metadata Initiative Dokumenten Management Dokumenten-Management-Systeme Enterprise Application Integration Enterprise Contentent Management European Computer Manufacturers Association Enterprise Java Beans Framework Class Libary Hypertext Markup Language Hypertext Transfer Protocol Integriertes Dokumenten-Management Internet Information Server Java 2 Enterprise Edititon Java Database Connectivity Java Message Service Java Naming and Directory Interface Java Runtime Enviroment Java Server Pages Message Exchange Pattern Multipurpose Internet Mail Extensions Message-orientated-Middleware Microsoft Common Intermediate Language Non Coded Information Optical Character Recognition Web Ontology Language Redundant Array of Inexpensive / Independent Disks Resource Description Framework RDF-Schema Remote Procedure Call Simple Object Access Protocol Universal Description, Discovery and Integration vii

9 UML URB URI URL VB VM W3C WfMS WSCI WSDL WSFL XML XMLP Unified Modeling Language UDDI Business Registries Uniform Resource Identifier Uniform Resource Locator Visual Basic Virtual Machine World Wide Web Consortium Workflow-Management-Systemen Web Service Choreography Interface Web Service Description Language Web Services Flow Language extensible Markup Language XML Protocol viii

10 Motivation Das Ziel dieser Arbeit soll der Entwurf eines Dienstes auf Basis der Web Service Technologie sein. Die Idee Web Services für ein Dokumenten-Management-System (DMS) einzusetzten ist nicht neu und wurde in Teilen schon von einigen Anbietern aufgegriffen. Größtenteils jedoch ist dies nur eine Erweiterung zu bestehenden Altsystemen und kein vollständig mit dieser Technik realisiertes System. Die Vorteile der serviceorientierten Implementierung eines DMS sind folgend aufgezeigt. Die vom System zur Verfügung gestellten Schnittstellen können von unterschiedlichsten Clients genutzt werden. Dabei ist es irrelevant ob die Informationen, die der entfernte Methodenaufruf liefert, auf einem Handy, einem SmartPhone oder mit einem Webbrowser (Thin Client) bzw. einem Thick Client auf einem Computer dargestellt werden. Die Verantwortlichkeiten für die eigentliche Präsentation liegt individuell bei jedem Service-User. Die Präsentationsschicht wurde sozusagen ausgelagert. Das der Service-Provider dem Serivce-User eine Standardlösung für die Dartsellung anbieten kann, sei dahingestellt. Die Anzeige eines vollständigen Dokuments auf einem Handy ist sicherlich nicht praktikabel. Um den Dienst dessen ungeachtet benutzen zu können wäre es denkbar, das Dokument im DMS zu suchen und sich den Ablageort in einer Favoritenliste zu einem schnelleren Wiederauffinden zu speichern. Des weiteren sind die Informationen über einige Dokumenten-Attribute, zum Beispiel die letzte Änderung oder die vorliegende Version für den Anwender hinreichend genug. Sollen bestehende (Alt-)System bzw. andere Web Services um Funktionen, welche der DMS-Dienst anbietet, erweitert werden, ist die Integration bzw. Komposition der Dienste ebenso möglich. Somit könnte beispielsweise eine kostenintensive Neuanschaffung oder eigene Implementierung gespart werden. Das DMS selbst kombiniert eigene einfache Dienste, um komplexere zur Verfügung stellen zu können. Dieses Konzept erlaubt weiterhin jedem Service-User, ein DMS zusammenzustellen, was an seine individuellen Bedürfnisse angepasst ist. So können die Funktionen Verwendung finden, welche als notwendig erachtet werden und aus Sicht des Anwenders überflüssige Funktionalitäten brauchen nicht genutzt werden. Entsprechend wird sich das in der Abrechnung widerspiegeln. Somit entfallen aufwendige Anpassungen eines DMS beim Kunden, wenn dieser sich selber die Funktionen zusammenstellen kann.

11 1 Web Services Dieses Kapitel wird eine Zusammenfassung der Technologie der Web Services geben. Fernerhin werden die einzelnen Komponenten erläutert und ein Überblick über die zur Implementierung zur Verfügung stehenden Plattformen und ein anschließender Vergleich dieser gegeben. 1.1 Einführung Die Technologie des Web Service mit den Basiskomponenten WSDL als Schnittstellenbeschreibungssprache, SOAP als Nachrichtenübertragungsformat und UDDI für die Publikation des Services finden im Besonderen Verwendung bei Anwendungen, die über das Internet oder Intranet kommunizieren. Dabei lassen sich nicht nur browserbasierte Anwendungen realisieren. Genauso kann die Integration der Web Services auf der Funktionsebene einer nichtbrowserbasierten Anwendung erfolgen. [Ebe03] beschreibt den Begriff der Web Services folgendermaßen: Ein Web Service ist eine durch einen URI eindeutig identifizierte Softwareanwendung, deren Schnittlstellen als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte Interaktion mit anderen Sotfwareagenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden. Abbildung 1.1 gibt einen Überblick des Web Service Modells. Die einzelnen Komponenten werden in den nachfolgenden Kapiteln näher erläutert. Durch die Verwendung von bereits etablierten Standards, wie HTTP oder XML ensteht eine offene Architektur zur Kommunikation zwischen verschiedenen Systemen unabhängig von der verwendeten Programmiersprache und Plattform. Durch die Verwendung von HTTP als Transportprotokoll ist eine Kommunikation über Firewalls hinweg möglich, denn Port 80 wird regelmäßig zum Browsen im Internet verwendet. Die Anwendungsgebiete der serviceorientierten Web Services liegen hauptsächlich im B2B-Bereich (Business-To-Business) um Geschäftsprozesse über Unternehmensgrenzen hinweg ausführen zu können. Weiteres Potential liegt in der Enterprise Application Integration (EAI) und im Grid-Computing. 1.2 WSDL Die Web Service Description Language (WSDL) ist ein XML Schema zur Beschreibung der Schnittstelle eines Web Services und wie mit ihnen interagiert wird. Ur- 1

12 1.2 WSDL WSDL Registry Recherchieren UDDI Publizieren UDDI Service- User Kommunikation SOAP / HTTP Service- Provider Abbildung 1.1: Das Web Service Modell sprünglich von IBM, Microsoft und Ariba entwickelt, wurde es im März 2001 der Web Services Description Working Group des W3C 4 zur Quasi-Standardisierung übergeben. Die aktuell vorliegende Version des Working Draft 5 vom August 2004 spezifiziert WSDL 2.0 und ist inhaltlich in drei Teile gegliedert: WSDL 2.0 Core Language (Part 1) beschreibt die Eigentliche Spezifikation für WSDL. Darin wird die Sprache für die Beschreibung der Funktionalität definiert. [W3C04g] WSDL 2.0 Predifined Extensions (Part 2) beschreibt die Erweiterungen für die Web Services. [W3C04h] WSDL 2.0 Bindings (Part3) definiert wie WSDL in Verbindung mit SOAP 1.2 und HTTP benutzt wird. [W3C04i] Die Grundstruktur eines WSDL-Dokuments hat in der XML-Darstellung den in Listing 1.1 gezeigten Aufbau. Die Funktionalität wird in WSDL in zwei Teilen definiert. Im ersten Teil wird die abstrakte Funktionalität mit den Elementen types, operation und interface beschrieben. Der zweite Teil behandelt die eigentliche Service-Implementierung und kein Standard, lediglich eine Diskussionsnotiz 2

13 1.2 WSDL 1 < definitions targetnamespace =" xs: anyuri " > 2 < documentation / >? 3 [ <import / > < include / > ]* 4 <types / >? 5 [ < interface / > < binding / > < service / > ]* 6 </ definitions > Listing 1.1: Grundstruktur WSDL definiert den konkreten Service. Die dafür verwendeten Elemente sind binding, service und endpoint Komplexe Datentypen Das types-element beinhaltet die in den Nachrichten verwendeten komplexen Datentypen. Einfache Datentypen wie string, integer, float, etc. werden bereits vom XML Schema zur Verfügung gestellt Interfaces Ein Interface beschreibt eine Sequenz von Nachrichten die ein Service senden und/oder empfangen kann. Diese Nachrichten sind innerhalb von operation-elementen gruppiert. Ein Interface kann über das optionale extends-attribut von einem oder mehreren Interfaces erben. Das operation-element muss eindeutig bzgl. seines name-attribut identifizierbar sein. Sie sind sozusagen die Methoden, welche von einem Service aufgerufen werden können. Innerhalb der Methoden werden Eingangs- (input) und Ausgangsnachrichten (output)definiert. Die Abfolge der Nachrichten wird dabei durch das pattern-attribut, welches ein eindeutiges Message Exchange Pattern (MEP) referenziert, festgelegt. Zur Zeit existieren acht MEPs, die in [W3C04h] definiert und in Abbildung 1.2 dargestellt sind. Tritt während des Nachrichtenaustausches ein Fehler auf, werden folgende drei Fault Generation Rules zur Anzeige verwendet Binding Durch die binding-komponente wird das konkrete Datenformat und Protokoll für jede Operation eines interface definiert. Die in [W3C04i] definierten möglichen Protokolle sind SOAP und HTTP und werden mit Hilfe des Attributes type spezifiziert. Es kann eine beliebige Anzahl von Bindungen für ein Interface oder eine Operation beschrieben werden. Soll die Bindung für ein Interface erfolgen, muss zusätzlich noch das interface-attribut eine definierte Komponenten referenzieren. 3

14 1.2 WSDL A A Client Server Client Server In-Only (No Faults) Robust-In-Only (Message Triggers Fault) Client Server Client Server A Out-Only (No Faults) A Robust-Out-Only (Message Triggers Fault) A A Client Server Client Server B In-Out (Fault Replaces Message) B-optional In-Optional-Out (Message Triggers Fault) B B-optional Client Server Client Server A Out-In (Fault Replaces Message) A Out-Optional-In (Message Triggers Fault) Abbildung 1.2: Message Exchange Pattern [Dhe05] 4

15 1.2 WSDL Regel Fault Replace Message Message Trigger Fault No Faults Beschreibung Jede Nachricht, außer der ersten kann durch eine Fehlermeldung ersetzt werden. Diese wird zum Aufrufenden zurück geschickt. Jede Nachricht (auch die erste) kann eine Fehlernachricht verursachen. Ist der Pfad zum Aufrufenden nicht bekannt, kann die Nachricht auch verworfen werden. Es werden keine Fehlernachrichten ausgegeben. Tabelle 1.1: Fault Generation Rules Diese Bindungen werden innerhalb eines Endpunktes (endpoint) explizit umgesetzt. Bei der HTTP-Bindung kann über das method-attribut die Methode angegeben werden. Dieses definiert ob die Nachricht über POST oder GET übertragen wird. Wird keine Methode angegeben, wird standardmäßig HTTP GET verwendet Service und Endpoint Zu der Beschreibung eines Dienstes finden die Komponenten service und endpoint Gebrauch. Ein service setzt sich aus mehreren Endpunkten zusammen und wiederum jeder Endpunkt ist mit einer Bindung assoziiert. Die drei verschiedenen Wege, über die ein Service ansprechbar ist (SOAP, HTTP POST und HTTP GET), worden in der Bindung definiert und in diesem Schritt erfolgt nur noch die Definition der Adresse Modularisierung Um die WSDL-Datei lesbarer und strukturierter zu gestalten und um die Wiederverwendbarkeit der einzelnen Teile zu erhöhen, bietet die Spezifikation zwei Methoden an: Das include-element eignet sich, um Elemente eines anderen URI in demselben Namensraum anzugeben. Wohingegen bei dem import-element die Ressourcen aus verschiedenen Namensräumen stammen können Zusammenfassung Normalerweise kommt ein Benutzer eines Web Service nicht mit den WSDL-Dokumenten in Berührung. Auch Entwickler von Web Services können auf existierende Tools zur Erzeugung von WSDL-Definitionen zurück greifen. Aber es gibt auch Ansätze mit denen aus WSDL-Dateien Programmierschnittstellen, sozusagen Bottom-Up, erzeugt werden können. 5

16 1.3 SOAP Die Grenzen von WSDL sind klar zu erkennen. So ist es nicht möglich, mehrere Web Services miteinander zu kombinieren oder komplexere Kommunikationen als Request-Response aufzubauen. Als Abhilfe dazu werden verschiedene Ansätze vorgeschlagen, auf die in der vorliegenden Arbeit nicht weiter eingegangen werden soll: WSFL, XLANG, BPEL (eine Weiterentwicklung auf Basis von WSFL und XLANG), BPML und WSCI. 1.3 SOAP Das Simple Object Access Protocol oder kurz SOAP ist ein Protokoll zum Austausch strukturierter Informationen in einer verteilten, dezentralisierten Umgebung. (Vgl. [Leb03]) Im Bereich der Web Services wird es für die Kommunikation im Rahmen eines Aufrufs genutzt. Die Basis bildet wiederum XML, weshalb SOAP auch als XML Protocol (XMLP) oder XML over HTTP bezeichnet wird. Die aktuell vorliegende Version 1.2 wurde im Juni 2003 vom W3C standardisiert. Diese SOAP-Norm wird in zwei Dokumenten beschrieben: Part 1: Messaging Framework [W3C03b] Part 2: Adjuncts [W3C03c] Zur eigentlichen Übertragung der SOAP-Nachrichten kann ein beliebiges Transportprotokoll verwendet werden. In der Praxis wird dazu überwiegend HTTP eingesetzt. Eine Übertragung über SMTP (SOAP over Mail) ist ebenso möglich. (Vlg. [W3C03a]) Das SOAP Nachrichtenformat Das SOAP Nachrichtenformat lässt sich in drei Hauptblöcke einteilen, die in Abbildung 1.3 veranschaulicht werden. Der SOAP Envelope kennzeichnet den Anfang und das Ende der SOAP Nachricht, bildet also eine Art virtuellen Umschlag für die anderen zwei Komponenten. Der SOAP Header ist optional und kann einen oder mehrere Header Block beinhalten. Diese tragen die Attribute der Nachricht oder definieren sogenannte Qualities of Service (QoS) für die Nachricht. Also Informationen, die nicht direkt als Anwendungsdaten zu charakterisieren sind und Angaben darüber spezifizieren, wie die Nachricht zu verarbeiten ist. Dazu gehört beispielsweise Transaktionsidentifikatoren, Authentifizierungs- oder Abrechnungsinformationen. 6

17 1.4 UDDI SOAP Envelope SOAP Header Header Block Header Block SOAP Body Message Body Abbildung 1.3: Das SOAP Nachrichtenformat Der SOAP Body muss zwingend vorhanden sein und enthält einen oder mehr Message Body die die eigentliche Nachricht tragen die zwischen zwei Kommunikationspartnern ausgetauscht wird. 1.4 UDDI UDDI steht für Universal Description, Discovery and Integration und ist der Verzeichnisdienst für Web Services der auf eine Initiative von IBM und Microsoft zurück zu führen ist. Mit SOAP und WSDL gehört dieser Dienst zu den drei Technologiesäulen im Umfeld von Web Services. Die aktuell vorliegende Version [CHvR04] wurde im Okober 2004 von der UDDI-Arbeitsgruppe des OASIS 6 Konsortium veröffentlicht. Für die Rolle eines Dienstanbieters (Service-Provider) wird UDDI verwendet um seinen Web Service bekannt zu machen, wohingehend auf der Seite des Dienstnutzers (Service-User) das Verzeichnis genutzt wird um einen seinen speziellen Anforderungen genügenden Web Service zu finden. Prinzipiell verfolgt UDDI drei Ziele: 1. Die Bereitstellung einer Datenstruktur für die effiziente Suche nach einem Web Service

18 1.4 UDDI 2. Die Möglichkeit, allgemeine und spezielle Web Service Informationen inklusive der technischen Zugriffsspezifikationen zu finden und bereitzustellen. 3. Die Definition einer Schnittstelle um Kommunikation zwischen Clients und UDDI-Registries zu ermöglichen. Die UDDI-Registries stellen den eigentlichen Verzeichnisdienst dar. In dieser erweiterbaren Datenbank können Clients Web Service-Informationen publizieren oder nach vorhanden Einträgen recherchieren. Es wird in zwei Arten von Registries unterschieden (Vgl. [Ebe03]). Die öffentlichen Registries sind der Allgemeinheit, meist nach einer kostenlosen Anmeldung, zugänglich und können zur Veröffentlichung und/oder zur Suche nach einem Service genutzt werden. Die privaten Registries werden beispielsweise nur in einem Firmen-Intranet für in diesem verfügbare Dienste aufgesetzt und sind nicht für die Öffentlichkeit zugänglich. Zur Definition eines Begriffes in diesem Sinne wurde ebendfalls die Bezeichnung UDDI Business Registries (URB) geprägt. Die Datenstruktur ist XML-geprägt und kann in folgende Kategorien eingeteilt werden: 1. White Pages enthalten die allgemeinen Informationen über einen Dienstanbieter (Unternehmen), wie Adresse, Telefonnummer oder Kontaktpersonen und sind wie ein Telefonbuch aufgebaut. 2. Yellow Pages sind vergleichbar mit den Gelben Seiten bzw. dem Branchenverzeichnis. Über die Art eines Dienstes kann ein bestimmter Anbieter herausgesucht werden. 3. Green Pages beinhalten die technischen Informationen eines Web Services, wie z.b. die URI, die WSDL-Beschreibung oder die textuelle Beschreibung des Dienstes. Das in XML beschriebene Datenmodell von UDDI stellt sechs Kernelemente bereit, die in Tabelle 1.2 aufgelistete sind. Auf die zur Kommunikation der Clients mit den UDDI-Registries geschaffenen Schnittstellen können diese in folgenden sechs Formen zugreifen: 1. UDDI Inquiry API für das Absetzen und Beantwortung von Suchanfragen und zur Ermittlung von Details. 2. UDDI Publishers API zum Modifizieren und Löschen von vorhanden und Hinzufügen von neuen UDDI Einträgen 8

19 1.5 Plattformen 3. UDDI Security API zur Durchführung von Authentifikationen. 4. UDDI Replication API zur Replikation und Synchronistation von UDDI-Elementen verschiedener UDDI-Knoten. 5. UDDI Custody and Ownership Transfer API ermöglicht die Übergabe von Verantwortlichkeiten zwischen zwei UDDI-Knoten eines UDDI-Verbandes. 6. UDDI Subscription API ermöglicht die weitere Eintragung von Web Service Anbietern. Die wohl wichtigste API für den Nutzer ist die UDDI Inquiry API. Diese ermöglicht eine einfache Abfrage von Web Service Informationen. Komponente businessentity businessservice bindingtemplate tmodel Beschreibung Enthält Informationen über das Unternehmen, wie Name, Kontaktdaten angebotene Services, etc. Enthält eine Beschreibung eines Web Services oder einer zusammenhängenden Gruppe dieser auf nicht-technischer Ebene, wie Beschreibung und Klassifikationsinformationen. Neben diesen optionalen Argumenten muss ein Name, ein eindeutiger Schlüssel sowie der Schlüssel des Anbieters aufgeführt werden. Repräsentiert einen individuellen Web Service und enthält die technischen Informationen, welche eine Applikation zur Bindung und Interaktion mit diesem benötigt. Beschrieben wird demnach der Zugangspunkt eines Services mit dem obligatorischen Schlüssel für die Bindung und den Schlüssel des Web Services. Steht für das technische Modell des Dienstes und fasst die detaillierten Service-Informationen zusammen. Dieser generische Container enthält einen eindeutigen Schlüssel zur Identifikation und einen Namen. Zusätzlich können eine Beschreibung oder ein externer Verweis auf eine Beschreibung enthalten sein. Tabelle 1.2: UDDI Kernkomponenten 1.5 Plattformen Die zwei ausgereiftesten Plattformen, die zur Implementation eines Web Services zur Verfügung stehen sind die Java 2 Enterprise Edititon (J2EE) und.net von Microsoft. 9

20 1.5 Plattformen J2EE Die Java 2 Enterprise Edition ist eine Java-Teilspezifikation für eine ganze Palette von Middleware-Diensten. Mit dieser Spezifikation wird ein allgemeiner Rahmen zur Verfügung gestellt um unternehmensweite, 3-tier Anwendungen mit modularen Komponenten zu entwickeln. J2EE erleichtert die Implementierung von serverseitigen Anwendungen durch die Bereitstellung von Werkzeugen, Diensten und Entwurfstrukturen. Interoperabilität von Softwarekomponenten unterschiedlicher Hersteller sollen durch klar definierten Schnittstellen zwischen den Komponenten und Schichten gewährleistet werden. Der Java Quellcode wird beim Kompilieren in maschinenunabhängigen Bytecode übersetzt, welcher dann zur Laufzeit durch eine Virtual Machine (VM) in die für den jeweiligen Prozessortyp und Betriebssystem geeignete Maschinencode interpretiert wird. Dieses Konzept ermöglicht eine plattformunabhängige, also unabhängig von dem Betriebssystem und der Hardware, Entwicklung von Java-Anwendungen. Die wichtigsten J2EE APIs sind folgend aufgelistet: Java Naming and Directory Interface (JNDI) ein Namens- und Verzeichnisdienst zum Referenzieren entfernter Objekte oder zum Lookup gebundener Objekte. Enterprise Java Beans (EJB) serverseitige Anwendungskomponenten welche die Geschäftslogik einer Anwendung implementieren. Java Server Pages (JSP) zum Einbinden von Java-Quellcode in ein HTML- Seite. Java Message Serivce (JMS) für die asynchrone Nachrichtenverteilung in Messageorientated-Middleware-Systemen (MOM-Systeme). Java Database Connectivity (JDBC) zum Zugriff auf relationale Datenbanken mit SQL. Java Transaction API (JTA) zur Steuerung der Transaktionsverwaltung. u.v.m. Abbildung 1.4 gibt einen kleinen Überblick über das J2EE Schichtenmodell. J2EE war bis zur Veröffentlichung von.net der einzige Ansatz zur Realisation von Web-Anwendungen, der es zu einer Marktreife und einer starken Verbreitung gebracht hat ([BRW03]). Mit dem Erscheinen der Web Service Technologie wurde das J2EE Framework um hinreichende Komponenten erweitert. Insbesondere wird seit 10

21 1.5 Plattformen Enterprise Information System-Schicht Browser Applet Applet- Container Servlet EJB ERP- Systeme Datenbank JSP Web- Container Darstellungsschicht Geschaeftslogikschicht EJB- Container Legacy- Systeme Abbildung 1.4: Das J2EE Schichtenmodell daher der Umgang mit XML und auf XML basierende Technologien umfassend unterstützt. Besondere Erwähnung sollen nach [New02] folgende Komponenten finden: Java API for XML (JAXP) bietet Hilfe zur Bearbeitung (Parsen und Transformieren) von XML-Dokumenten. Unterstützt beide Parserstandards DOM und SAX. Java API for XML-Registries (JAXR) definiert Schnittstellen und Klassen zum Zugriff auf Registries (UDDI Registries, ebxml Registries). SOAP with Attachements API for Java (SAAJ) zum versenden von XML- Dokumenten über das Internet. Java API for XML-based RPC (JAX-RPC) steuert für Remote Procedure Calls (RPC) das Mapping von SOAP und WSDL-Spezifikationen auf Java Klassen. Java Architecture for XML Binding (JAXB) to bind an XML schema to a representation in Java code Zur Implementierung von Java-Anwendungen stehen verschiedene Werkzeuge, wie 11

22 1.5 Plattformen beispielsweise ANT, JUnit JavaDoc, sowie die kostenlose integrierte Entwicklungsumgebung Eclipse 7, zur Verfügung NET Der Begriff.NET steht für die Microsoft Plattform zur Entwicklung von Web Services und wurde Mitte 2000 das erste Mal geprägt. Im Oktober 2000 wurden Teile bei der Europäischen Standardisierungsorganistation ECMA 8 eingereicht..net umfasst folgende Komponenten um Informationen, Systeme und Geräte miteinander zu verbinden ([Gra03]):.NET Services sind verschiedenen Services, welche durch Microsoft als Hoster angeboten werden..net Enterprise Server umfasst die hauseigenen Server von Microsoft, wobei keine technischen Änderungen gegenüber den Vorgängern vorgenommen, sondern sie lediglich mit einem.net-logo versehen worden sind..net Framework entpricht der Plattform zur Entwicklung von Web Services.NET Development Tools die integrierte Entwicklungsumgebung Visual Studio.NET mit dem.net Framework. Unterstützt werden alle.net-fähigen Programmiersprachen. Das Konzept der.net-plattform ist ähnlich zu Java/J2EE. Die Common Language Infrastructure (CLI) stellt die Basis zur Ausführung von Programmen, welche mit unterschiedlichen Sprachen entwickelt wurden (bspw. C#, Visual Basic,... ), dar. Mit Hilfe eines entsprechenden Compilers wird das.net-programm zunächst in die Microsoft Common Intermediate Language (MSIL) übersetzt. Zur Laufzeit, quasi Just-in-Time (JIT), wird diese MSIL-Darstellung in nativen Code für den jeweiligen Prozessor übersetzt, wodurch die Sprachneutralität und trotzdem effizienter Code realisiert werden. Um sprachübergreifende Programme erstellen zu können reicht MSIL alleine nicht aus. Darüber hinaus muss noch eine gemeinsames Typsystem definiert werden. Dieses ist nötig um ein gemeinsames Verständnis für die in den einzelnen Programmiersprachen verwendeten Datentypen zu erreichen. Mit dem Common Type System (CTS) wird in.net dieses Ziel erreicht und sogar noch ein Schritt weiter gegangen. Die sprachübergreifende Integration ermöglicht es, Vererbungsbeziehungen zwischen Klassen zu beschreiben, welche in verschiedenen Sprachen programmiert European Computer Manufacturers Association 12

23 1.5 Plattformen VB C# u.v.a..net Klassenbibliothek Compiler Compiler Compiler IL Code CLR Compiler Laufzeitdaten Betriebssystem Abbildung 1.5: Die Komponenten des.net Frameworks worden sind. Um die Interoperabilität sicher zu stellen, genügt es bereits eine Teilmenge der CTS, die so genannte Common Language Specification (CLS), zu erfüllen. Die gemeinsame Klassenbibliothek, die so genannte Base Class Libary (BCL) oder auch Framework Class Libary (FCL) bildet die Basis für die Anwendungsentwicklung in allen.net-programmiersprachen. Sie ist in Namensräumen (Namespaces) organisiert und gehört inklusive der zugehörigen Dokumentation zum Lieferumfang des kostenlosen Software Develop Kit (SDK) oder zur kostenpflichtigen integrierten Enwicklungsumgebung (IDE) in Form des Microsoft Visual Studion.NET. Die Abbildung 1.5 zeigt die Komponenten des.net Frameworks. Für die dynamische Generierung von Web-Seiten steht ASP.NET, eine Weiterentwicklung der Active Server Pages (ASP), zur Verfügung. Der Zugriff auf Informationsquellen, wie relationale Datenbanken, wird in der.net-welt mit Hilfe von ADO.NET realisiert. Die angestrebte Plattformunabhängigkeit von.net ist so umgesetzt und wohl auch von Microsoft so verstanden worden, dass.net auf verschiedenen Windows- Varianten laufen kann. Demnach ist diese offiziell nicht wirklich gegeben. Das Open- 13

24 1.5 Plattformen Source-Projekt Mono 9 will eine tatsächliche Plattformunabhängigkeit des.net Framework erreichen und entwickelt eine quelltextoffene Implementierung für Unix- Derivate und Windows, auf Basis der ECMA-Standards für CLI und C#. Für weitergehende Informationen zum Mono Projekt wird die Webseite bzw. [SW05] empfohlen. Eine weitere Initiative zum Erstellen und Ausführen von CLI-Applikationen gibt das dotgnu Project 10 mit dem aktuellem Release des DotGNU Portable.NET in der Version J2EE versus.net Die fundamentalsten Unterschiede beider Plattformen sind nach [KBS03a], die Plattformunabhängigkeit, die unterstützten Programmiersprachen und die Anzahl der Lösungsanbieter. Unterschiede sind auch in der Standardisierung zu finden. Während J2EE vollständig standardisiert wurde, legt Microsoft lediglich die Teilspezifikationen CIL und C# des.net-framework einem offiziellen Gremium vor. Die Tabelle 1.3 gibt eine Übersicht der relevantesten Unterschiede. Das Konzept des Applikationsservers, welches dem Entwickler von Java-Anwendungen einiges an Arbeit abnimmt, ermöglicht es sich im Schwerpunkt auf die Geschäftslogik der Anwendung zu konzentrieren. Durch das serverseitige Komponentenmodell der EJBs muss dieser sich nicht mehr mit der Verarbeitung von Transaktionen nach dem ACID 12 -Prinzip, dem Remoting oder den Zugriff auf Datenbanken auseinander setzen..net bietet diese Funktionalität ebenfalls, jedoch die Grenzen zwischen Betriebssystem, Framework und Webserver sind fließend, so das eine Portierung auf andere Betriebssystem schwierig ist. (Vgl. [SM02],[Gra03]) Ein wesentlicher Vorteil der.net-technologie ist die native Unterstützung für XML, WSDL, SOAP und UDDI, welche es dem Benutzer relativ leicht macht, einen ersten Web Service zu implementieren und zu veröffentlichen. J2EE wurde lediglich um die XML und Web Service Technologie erweitert und ist nicht grundlegend, wie.net, für diesen Technologieansatz entworfen worden. Das Potential der Mono-Initiative ist immens und ermöglicht schon heute die Portierung zahlreicher Anwendungsarten. Jedoch sind rechtliche Schritte von Microsoft atomicity, consistency, isolation, durability 14

25 1.5 Plattformen Parameter J2EE.NET Allgemein Industriestandard eine Sprache, viele Anbieter Produkt-Suite viele Sprachen, ein Anbieter Sprachen Java C#, VB, C++, Java, J#,... Komponentenmodell Enterprise Java Beans.NET Web Services; COM+ Interpreter JRE (Java TM Runtime CLR (Common Language Enviroment) Runtime) Anbieter BEA, IBM, SUN, Orcale, Microsoft... Betriebssystem UNIX, Windows, Linux,... Windows Mono-Initiative zur Portierung auf Linux Browser beliebig, mit Java-Support beliebig Webserver Beliebig MS IIS Webserver- JSP, Servlets ASP.NET Komponenten Datenbank-Zugriff JDBC ADO.NET Verzeichnisdienst beliebig, über JNDI Active Directory Tabelle 1.3: Gegenüberstellung J2EE und.net 11 gegen diese Implementierung möglich, da auch Teile nachprogrammiert werden, die nicht der Standardisierung unterliegen. (Vgl. [SW05]) Eine Entscheidung für eine der beiden Plattform kann nur schwierig getroffen werden. Beide Ansätze habe Befürworter und Gegner. Anhand der Fakten kann nicht immer eine Technologie favorisert werden. Beide haben ihre Stärken und Schwächen. So bietet.net einen leichteren Einstieg für die ersten Schritte mit der Web Service Technologie. Bezüglich der Flexibilität und der Plattformunabhängigkeit, ausgenommen dem Mono Projekt, wäre J2EE der Vorzug zu geben. Die Koordinierungsund Beratungsstelle der Bundesregierung für Informationstechnik, kurz KBSt 13 gibt nach [KBS03b] J2EE aufgrund dieser Argumente den Vorrang

26 2 Ressource Description Framework Das Ressource Description Framework (RDF) [W3C04b] ist ein Modell zur Beschreibung von Objekten und Ressourcen und wurde 1999 erstmals dem W3C vorgelegt. Das RDF gibt eine Struktur vor und bildet somit den Rahmen zur Präsentation verschiedener Metadatenformate. Diese wiederum können als DTD, XML-Schema oder RDF-Schema definiert werden. Die Beschreibung des Frameworks erfolgt üblicherweise in Form einer XML-Sprache oder in einem graphischen Modell. 2.1 RDF-Modell Die Informationen dieses Modells sind in so genannten Statements oder Assertions zusammen gefasst. Ein Statement (eine Aussage) besteht aus einem Tripel zusammengesetzt aus den Komponenten Subjekt, Prädikat und Objekt. Jede dieser Ressourcen wird durch eine URI identifiziert. Das Objekt einer Aussage kann einen literalen Wert enthalten oder eine andere Ressource sein. Das Prädikat einer Aussage definiert die Eigenschaft einer Ressource (Properties) und ist selbst eine Ressource, welche durch Referenzierung von weiteren RDF-Angaben verwendet werden kann. Die Aussage selber ist ebenfalls eine Ressource, welche von weiteren Aussagen verwendet werden kann. Diese Aussagen über Aussagen werden in RDF als Reification bezeichnet. RDF-Syntax Das syntaxneutrale Datenmodell kann u.a. mit Hilfe von gerichteten Graphen dargestellt werden. Zur Identifizierung erfolgt die Beschriftung der Knoten und gerichteten Kanten mit einer URI, wobei Subjekt und Objekt durch Knoten und die Prädikate mittels Kanten repräsentiert werden. Modelliert werden können nur binäre Beziehungen. Werden mehrwertige Beziehungen von Ressoucren benötigt, oder ist eine Bezeichnung eines Knoten mit einer URI nicht zweckmäßig, werden Hilfsknoten, so genannte blank nodes in den Graphen eingefügt. Darüber hinaus ist eine Darstellung des RDF-Modells in maschinenlesbarer Form notwendig. Dafür stehen beispielsweise die Notation 3 (N3) oder die RDF/XML-Form zur Verfügung, welche unter Zuhilfenahme eines Parsers serialisiert werden können. Container Um gleichartige Beschreibungen zusammenzufassen wird die Funktionalität der Container benötigt. Dazu stehen in RDF die in Tabelle 2.1 aufgelisteten Container-Elemente zur Verfügung. Ein Container kann beliebig viele Elemente enthalten, wobei der Alt-Container mindestens ein Element beinhalten muss. 16

27 2.2 RDF-Schema Element rdf:seq rdf:bag rdf:alt Beschreibung Definiert eine geordnete Liste von Ressourcen. Definiert eine ungeordnete Liste von Ressourcen. In dieser Multimenge können Elemente auch doppelt vertreten sein. Definiert eine Menge von alternativen Ressourcen. 2.2 RDF-Schema Tabelle 2.1: Container-Elemente des RDF-Modells Das RDF-Schema (RDFS) [W3C04a] ermöglicht es, ein Typenmodell, ähnlich dem Klassenprinzip der Objektorientierung, für die RDF-Tripel zu spezifizieren. So ist es möglich Klassen, Eigenschaften und einfache Beziehungen der Aussagen zu beschreiben um so eine Begriffshierarchie bzw. Taxonomien 14 zu bilden. Ein wichtiges Konzept des Klassenprinzips, welches hier eine explizite Erwähnung finden sollen, sind die Klasse-Unterklasse- bzw. Eigenschaft-Untereigenschaft-Beziehungen oder auch der Vererbungsmechanismus. Dabei sind alle Untereigenschaften in der Obereigenschaft enthalten aber nicht umgekehrt. Des weiteren gilt (Vgl. [Abe03]): Ist eine Klasse A Unterklasse von B und eine Klasse B Unterklasse von C, so ist A eine Unterklasse von C (so genannte Transitive Hülle) Ist R eine Ressource einer Instanz von A, so ist R auch eine Instanz von B und C. Das RDF-Schema kennt die in Tabelle 2.2 gezeigten Klassen, wobei die Klassen rdfs:resource, rdfs:property und rdfs:class in [EE04] als die zentralen Klassen bezeichnet werden. Daneben werden in der Tabelle 2.3 die Eigenschaften genannt, die das RDFS kennt. 2.3 Web Ontology Language Die Web Ontology Language (OWL) wurde entwickelt um die in vielen Fällen nicht ausreichende Modellierung von Vokabularen mit Hilfe von RDF-Schemara abdecken zu können. OWL ist demnach eine Erweiterung von RDF, dessen erster Sprachentwurf im Juli 2002 als Working-Draft und im Oktober 2004 als Empfehlung (Recommendation) publiziert wurde [W3C04c, W3C04e, W3C04d, W3C04f]. OWL existiert in drei Gattungen (OWL Lite, OWL DL und OWL Full), die für jeweils unterschiedliche Benutzergruppen gestaltet wurden. Sie unterscheiden sich in der Mächtigkeit und somit auch in ihrer Komplexität des Vokabulars und sind aufwärtskompatibel. Somit gelten nach [W3C04c] folgende Aussagen, jedoch nicht deren Umkehrung : 14 Klassifikationssysteme, bzw. Systematiken des Klassifizierens 17

28 2.3 Web Ontology Language Klasse Beschreibung rdfs:resource Die Oberklasse aller Ressourcen, eine Instanz von rdfs:class rdfs:class Die Oberklasse aller im RDFS definierten Klassen rdfs:literal In dieser werden alle literalen Werte definiert (Strings, Integer,... ). Diese Literale können plain oder typed sein. rdfs:datatype Die Oberklasse aller Datentypen. rdfs:xmlliteral Alle XML-Datentypen werden in dieser Oberklasse zusammengefasst. rdfs:property Die Oberklasse aller RDF-Eigenschaften Tabelle 2.2: Klassen des RDF-Schemas Eine legale OWL Lite Ontologie ist eine legale OWL DL Ontologie. Eine legale OWL DL Ontologie ist eine legale OWL Full Ontologie. Das primäre Entwurfsziel der Entwicklung ist der Grundgedanke des evolutionären Wachstums der Ontologien. So sollen Ontologien zum einem öffentlich zugänglich sein und zum sich zum anderem sich auf Datenquellen und Ontologien beziehen können. Dies setzt eine Kompatibilität zwischen OWL und Beschreibungs- und Modellierungsstandards wie XML, RDF und UML voraus. Um die Interoperabilität der verschiedenen Ontologien oder Versionen von Ontologien gewährleisten zu können, müssen Inkonsistenzen automatisch erkannt und verarbeitet werden. Ferner ist eine exakte Versionssteuerung notwendig, um Inkompatibilität zu Vorgängerversionen zu vermeiden. Das Klassenkonzept baut auf dem von RDF auf. So ist owl:class eine Unterklasse von rdfs:class und die rdfs:subclassof-eigenschaft wird direkt übernommen. Überhaupt werden einige Konstrukte aus der RDF-Elementmenge übernommen. Nennenswert wäre beispielsweise rdf:range, rdf:domain und rdf:type. Eigenschaften in OWL werden als Untereigenschaften von rdf:property definiert. Die zur Verfügung stehenden Elemente hierzu sind owl:objectproperty und owl:datatypeproperty. Objekteigenschaften beschreiben Relationen zwischen Instanzen von zwei Klassen, wohingehend Datentypeigenschaften sich auf RDF-Literale sowie XML-Schema Datentypen beziehen. Mit Hilfe von OWL können komplexe Beziehungen zu Klassen und Eigenschaften beschrieben werden. Zum Beispiel sind die Eigenschaftscharakteristiken (Property Characteristica) (TransitiveProperty, SymmetricProperty, FunctionalProperty, inverseof 18

29 2.3 Web Ontology Language Eigenschaft rdfs:range rdfs:domain rdf:type rdfs:subclassof rdfs:subpropertyof rdfs:label rdfs:comment rdfs:seealso rdfs:isdefinedby Beschreibung Beschränkt den erlaubten Wertebereich, bei denen die Eigenschaft genutzt werden darf. Beschränkt die Klassen, bei denen die Eigenschaft genutzt werden darf. Definiert die Zugehörigkeit der Ressource als Instanz zu einer Klasse. Kennzeichnet die Zugehörigkeit einer Klasse zu einer Oberklasse. Definiert die Zugehörigkeit einer Eigenschaft zu einer Obereigenschaft. Nennt den menschenlesbaren Namen einer Ressource. Bezeichnet den menschenlesbaren Kommentar einer Ressource. Spezifiziert zusätzliche Informationen zu einer Ressource. Verweist auf eine definierte Ressource. Tabelle 2.3: Eigenschaften des RDF-Schemas und InverseFunctionalProperty) ein Hilfsmittel um Schlussfolgerungen über Eigenschaften (Property) treffen zu können. Einschränkungen einer Eigenschaft (Property Restrictions) werden im Kontext einer owl:restriction mit der im Elemente owl:onproperty spezifizierten Eigenschaft getroffen. Unter anderem kann auf diese Weise die Kardinalität 15 owl:cardinality definiert werden. Damit Ontologien mit anderen zusammengesetzt werden können (Mapping von Ontologien) um somit die logischen Schlussfolgerungen zu maximieren, ist es wiederum notwendig Äquivalenzen zwischen Klassen bzw. Eigenschaften abzubilden (owl:equivalentclass bzw. owl:equivalentproperty). Somit können zwei unabhängig voneinander entwickelte Ontologien, welche dieselbe Klasse bzw. Eigenschaft referenzieren, miteinander kombiniert werden. 15 die quantitative Ausprägung eines Merkmals 19

30 2.4 Anwendungen 2.4 Anwendungen Dublin Core Metadata Initiative Die Dublin Core Metadata Initiative 16 (DCMI) ist eine Organisation, die sich engagiert, um die Verbreitung von interoperablen und domänenunabhängigen Metadaten- Standards und Metadaten-Vokabularen zu fördern. Diese Standards und Vokabulare sollen Ressourcen so beschreiben, dass intelligente Suchmaschinen bzw. Agenten in der Lage sind, Informationen im World Wide Web einfacher zu finden. Um diese Interoperabilität zwischen den verschiedenen Metadaten-Mengen zu gewährleisten bzw. zu unterstützen werden von der DCMI grundlegende Strukturen definiert. Ein Beispiel hierfür ist der Dublin Core, welcher eine Menge von Eigenschaften zur Beschreibung von Dokumenten, Datenquellen, etc. definiert. Dublin Core Element Set Insgesamt bietet der Dublin Core Element Set [DCM04] 15 Elemente zur Beschreibung von Ressourcen, welche in Tabelle 2.4 aufgezeigt werden. Wird dieser so genannte einfache Dublin Core um diverse DC-Elemente u.a. zur Verfeinerung und die Encoding Schemes [DCM05] erweitert, spricht man vom qualifizierten Dublin Core [EE04]. Ursprünglich wurde der Dublin Core unabhängig von RDF entwickelt, mittlerweile jedoch hat dieser Standard die Entwicklung von RDF beeinflusst und wird heute oft mit Hilfe von RDF dargestellt. In der RDF/XML-Darstellung des einfachen Dublin Core werden nur in dem Element rdf:description die Dublin-Core-Elemente in beliebiger Reihenfolge und Häufigkeit verwendet. Da im einfachen Dublin Core keine Verschachtelungen oder Container erlaubt sind, müssen für beispielsweise mehrere Autoren eines Dokumentes das Creator-Element entsprechend oft verwendet werden. Der qualifizierte Dublin Core hingegen erlaubt es, Verfeinerungen und Kodierungsschemata bei der Beschreibung von Ressourcen zu verwenden. Somit ist die Verwendung von Multimengen, Sequenz und Alternativen, also den bekannten Containern aus dem RDF, wieder möglich. Die Dublin-Core-Darstellung in RDF/XML für diese Arbeit könnte wie in Listing 2.1 aussehen RSS Die Darstellung von so genannten RSS-Feeds basiert seit der Version 2.0 nicht mehr auf RDF, das Protokoll soll an dieser Stelle aber trotzdem erwähnt werden

31 2.4 Anwendungen Element Beschreibung Title Bezeicnet den Namen der Ressource. Creator Gibt den Hauptverantwortlichen/Ersteller der Ressource an. Subject Beschreibt den Inhalt einer Ressource, häufig mit Hilfe von Schlagwörtern. Description Enthält den verbalen Überblick einer Ressource in verschieden möglichen Formaten, bspw. als Freitext oder als Inhaltsverzeichnis. Publisher Definiert den Herausgeber, verantwortlich für die Veröffentlichung der Ressource an. Contributor Person, Institution oder Service welche(r) einen Beitrag zur Ressource leistet. Date Spezifiziert das Datum eines Ereignisses für die Ressource. Denkbare Zeitpunkte wären Erstellungs-, Veröffentlichung-, oder Änderungsdatum. Type Definiert die Einordnung in eine Taxonomie. Format Beschreibt das physische Format einer Ressource. Identifier Wird zur eindeutigen Indentifizierung benötigt. Source Gibt die Quelle von der die Ressource abgeleitet wurde an. Language Kennzeichnet die Sprache in der die Ressource verfasst ist. Empfohlen wird die Verwendung der ISO639, welche die Abkürzungen in 2- oder 3-Buchstaben-Sprachcodes definiert. Relation Nennt verwandte Ressourcen. Coverage In diesem Element wird die Ausdehung oder Bereich des Inhaltes einer Ressource angegeben. Rights Definiert die allgemeinen Eigentumsrechten bzw. die Copyright-Bestimmungen. Tabelle 2.4: Elemente des Dublin Core Metadata Element Set 21

32 2.4 Anwendungen 1 <? xml version =" 1.0 "?> 2 < rdf:rdf 3 xmlns:rdf =" http: // /1999/02/22 - rdf - syntax -ns#" 4 xmlns:dc =" http: // purl. org /dc/ elements /1.1/ "> 5 < rdf: Description 6 rdf:about =" http: // www. inf.tu - dresden.de /~ jh / beleg /"> 7 < dc:title > 8 Entwurf eines Dienstes zur Dokumentenverwaltung auf Basis von Web Services 9 </ dc:title > 10 < dc: description > 11 http: // www. inf.tu - dresden.de /~ jh / beleg / inhalt. xml 12 </ dc: description > 13 < dc:subject >Web Service ; DMS ; RDF </ dc:subject > 14 < dc:date > </ dc:date > 15 < dc:language >de </ dc:language > 16 < dc:creator >Jan Haeussler </ dc:creator > 17 </ rdf: Description > 18 </ rdf:rdf > Listing 2.1: Dublin Core in RDF/XML Der Begriff, für den die Abkürzung RSS steht, variierte im Laufe der unterschiedlichen RSS-Versionen. Beginnend mit der Version 0.9x des XML-basierten Kommunikationsprotokolls wurde dieses als Rich Site Summary bezeichnet. Darauf folgte Version 1.0, in welcher der Begriff RDF Site Summary verwendet wurde. In der aktuellen Version 2.0 des Protokolls [Cen] wird RSS als Really Simple Syndication benannt. Entwickelt wurde das plattformunabhängige, XML-basierte Protokoll RSS um Nachrichten und andere Informationen, welche auf eine Webseite dargestellt werden können, in einem maschinenlesbaren Format auszutauschen. Der Aufbau von RSS ist auf die Darstellung und den Transport von Informationen angelegt und frei, im Gegensatz von HTML, von jeglichen Layout- und Design-Komponenten. Zahlreiche Portale und online-nachrichten bieten bereits die Funktionalitäten von RSS an, beispielsweise oder Moderne Web-Browser, bspw. Firefox 17 können die RSS-Feeds als ein Lesezeichen importieren, so dass der Nutzer immer über die aktuellsten Entwicklungen des abonnierten RSS-Feeds Bescheid weiß, ohne das er die Webseite besuchen muss. Darüber hinaus gibt es noch integrierte Lösungen für gängige Terminverwaltungsprogramme (Kontact, MS Outlook) diverse Stand-Alone-Lösungen (Free RSS Reader 18 ), so genannte News-Aggregators, mit denen RSS-Feeds gelesen und synchronisiert werden können