Web Services
Werbung
Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 4: Web Services I Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda ([email protected]) (Vorläufiger) Aufbau der Vorlesung Kapitel Thema 1 2 3 Organisation, Einführung in Software-Architekturen 4 (11.5.) Web Services I (SOAP, WSDL) 5 (18.5.) Web Services II (Axis2,...) 6 (25.5.) Modellierung von Geschäftsprozessen (BPEL, BPMN) 7 (1.6.) Vertiefung und Backup Web Services 8 (8.6.) OSGi Service Plattform 9 (15.6.) Einführung in Swordfish 10 11 (22.6.) Einführung in Service-Orientierte Architekturen Design Prinzipien von Service-Orientierten Architekturen REST Architekturen Exception Handling in SOA (Gastvortrag) 12 (29.6.) SOA Point of View von Accenture (Gastvortrag) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 2 Ziele dieser Unterrichtseinheit Grundlagen des Web Services Framework verstehen Die beiden wichtigsten Web Services Standards verstehen und anwenden (SOAP und WSDL) Implementierungen eines Web Service basierend auf gängigen Technologien verstehen und eigenständig anwenden können Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 3 Aufbau dieser Veranstaltung Kapitel 4: Einführung in Web Services, Teil 1 1 Überblick über Web Services 2 Einführung in SOAP 3 Einführung in WSDL 4 Implementierung von Web Services: AXIS2 und 5 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 4 Web Services Technologie-Framework für die Entwicklung und Integration von verteilten Systemen Seit ca. 2000 bekannt Festlegung der Standards durch Web Service Interoperability Organization (WS-I) - - - Aktueller Standard: Basic Profile (BP) 1.1 Draft Version: Basic Profile (BP) 1.2 Getrieben durch IBM, Microsoft, Bea, Fujitsu, Oracle u.a. Web Services repräsentieren eine Möglichkeit zur Implementierung einer SOA Stand heute: De-Facto Framework für die Implementierung Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 5 Aufbau einer SOAP-basierten Web Services Architektur UDDI (-compatible) Directory Return“possibleservices” : WSDL[ ] Discover “aService” SOAP SOAP Publish “aService” : WSDL SOAP Service Consumer Service Bind / Interaction Web Service Provider Web Service “aService” : WSDL SOAP • XML-basiertes Nachrichtenformat für den Aufruf / Interaktion mit einem Web Service WSDL (Web Service Description Language) • XML-basierte Meta-Sprache zur Beschreibung der Schnittstelle eines Web Service UDDI (Universal Description, Discovery and Integration) • Directory-Service für die Publikation und Suche von Web Services Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 XML – Basis für Web Services Architekturen • XML (exTensible Markup Language) ist die Grundlage einer Vielzahl der Web Services Standards. - Metasprache zur Definition von (Austausch-)Dokumenten - Hohe Interoperabilität (plattform- und programmiersprachenneutral) - Hierarchische Dokument-Struktur „lesbare“ Darstellung - Typirisierung von Dokument-Elementen und Attribute durch Namensräume XML-Typ Deklaration f. Zeichensatz Typ-Definition (XML-Schema) Hierarchische Struktur eines XML-Dokuments Deklaration des Namensraums <?xml version = „1.0“ encoding = „UTF-8“ ?> <schema xmlns = „http://www.w3.org/2001/XMLSchema“ <?xml version = „1.0“ encoding = „UTF-8“ ?> xmlns : mySchema = „http://myweb.de/types“ <database xmlns = „http://myweb.de/types“ > <person> <vorname>Sascha</vorname> <nachname>Alda</nachname> </person> </database> targetNamespace = „„http://myweb.de/types“ Type-System für <element name „person“ type = „mySchema:PersonType“ /> <complexType name = „PersonType“ > <sequence> <element name = „vorname“ type = „string“/> <element name = „nachname“ type = „string“/> </sequence> </complexType> </schema> Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 XML – Basis für Web Services Architekturen • XML (exTensible Markup Language) ist die Grundlage einer Vielzahl der Web Services Standards. - Metasprache zur Definition von (Austausch-)Dokumenten - Hohe Interoperabilität (plattform- und programmiersprachenneutral) - Hierarchische Dokument-Struktur „lesbare“ Darstellung - Typirisierung von Dokument-Elementen und Attribute durch Namensräume XML-Typ Deklaration f. Zeichensatz Hierarchische Struktur eines XML-Dokuments (mit Präfix f. Namensraum) Typ-Definition (XML-Schema) Deklaration des Namensraums <?xml version = „1.0“ encoding = „UTF-8“ ?> <schema xmlns = „http://www.w3.org/2001/XMLSchema“ <?xml version = „1.0“ encoding = „UTF-8“ ?> xmlns : mySchema = „http://myweb.de/types“ <database xmlns:d= „http://myweb.de/types“ > <d:person> <d:vorname>Sascha</vorname> <d:nachname>Alda</nachname> </d:person> <database> targetNamespace = „„http://myweb.de/types“ Type-System für <element name „person“ type = „mySchema:PersonType“ /> <complexType name = „PersonType“ > <sequence> <element name = „vorname“ type = „string“/> <element name = „nachname“ type = „string“/> </sequence> </complexType> </schema> Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Aufbau dieser Veranstaltung Kapitel 4: Einführung in Web Services, Teil 1 1 Überblick über Web Services 2 Einführung in SOAP 3 Einführung in WSDL 4 Implementierung von Web Services: AXIS2 und 5 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 9 SOAP XML-basiertes Nachrichtenformat für den Aufruf / Interaktion mit einem Web Service Die Bezeichnung „Protokoll“ ist bedingt richtig: SOAP basiert auf bekannten Protokollen wie HTTP, TCP usw. Versionen: - - - - Ursprüngliche Bezeichnung in 1.1: „Simple Object Access Protocol“ Ab 1.2: keine Bedeutung! - - SOAP 1.1 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) SOAP 1.2 (http://www.w3.org/TR/soap12-part1/), seit 2007 SOAP 1.2 ist abwärtskompatibel zu 1.1 SOAP 1.1 ist (noch) weiter verbreitet als 1.2 SOAP spezifiziert keine Objekte SOAP legt kein Protokoll fest SOAP sieht zwei grundlegende Nachrichtenformate vor: - - Methodenbasiert, RPC-Style (RPC / literal) Dokumentbasiert (document / literal) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 10 SOAP – Struktur und Beispielcode • SOAP ist ein Nachrichtenformat für die Interaktion mit Web Services - - XML-basiertes Nachrichten-Format XML-Fragmente werden verschickt SOAP-Nachrichten haben einen hierarchischen Aufbau Service-Aufruf Rückantwort Service Consumer Envelope Header Übertragungsspezifische Daten -optional- SOAPNachricht Web Service Provider Web Service “aService” : WSDL <?xml version="1.0"?> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> … </s:Header> <s:Body> Body Anwendungsspezifische Daten -required- </s:Body> </s:Envelope> Hierarchischer Aufbau (Meta-Modell) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 XML-Struktur SOAP – RPC-Style SOAP Request • Der RPC-Style von SOAP impliziert, dass das ausgetauschte XML-Fragment auf einem Operationsaufruf sowie auf eine entsprechende Rückantwort basiert Service-Aufruf Rückantwort Service Consumer SOAPNachricht Envelope Header Übertragungsspezifische Daten -optional- Body Operation definiert in Anwendungsspezifische Daten WSDL -required- file Web Service Provider Web Service “aService” : WSDL <?xml version="1.0"?> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> … </s:Header> <s:Body> <m:GetAddress xmlns:m="http://www.myserver.de/soap"> <m:surname> Alda </m:surname> <m:/GetAddress> </s:Body> </s:Envelope> Meta-Modell Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 XML-Struktur (SOAP Request für Service-Aufruf, RPC-Style) SOAP – RPC-Style SOAP Response • Der RPC-Style von SOAP impliziert, dass das ausgetauschte XML-Fragment auf einem Operationsaufruf sowie auf eine entsprechende Rückantwort basiert Service-Aufruf Rückantwort Service Consumer SOAPNachricht Envelope Header Übertragungsspezifische Daten -optional- Body Anwendungsspezifische Daten -required- Rückgabewert definiert in WSDL file Web Service Provider Web Service “aService” : WSDL <?xml version="1.0"?> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> … </s:Header> <s:Body> <m:GetAddressResponse xmlns:m="http://www.myserver.de/soap"> <m:city> Bonn, NRW </city> </m:GetAddressResponse> </s:Body> </s:Envelope> Meta-Modell Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 XML-Struktur (SOAP Response für Service-Aufruf, RPC-Style) SOAP – RPC-Style SOAP Fault • Der RPC-Style von SOAP impliziert, dass das ausgetauschte XML-Fragment auf einem Operationsaufruf sowie auf eine entsprechende Rückantwort basiert Service-Aufruf Fehler! Service Consumer Envelope Header Übertragungsspezifische Daten -optional- Body Anwendungsspezifische Daten -required- SOAPNachricht Web Service Provider Web Service “aService” : WSDL <?xml version="1.0"?> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Body> <s:Fault> <s:Reason> <s:Text> Invalild Method </s:Text> </s:Reason> <s:Detail> <!– ggf. Eigene Daten mit eigenem Namespace -> </s:Detail> </s:Fault> </s:Body> </s:Envelope> Meta-Modell Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 XML-Struktur (SOAP Response für Fehlermeldung) SOAP – Document-Style • • Der Document-Style von SOAP impliziert, dass das ausgetauschte XMLFragment ein Dokument ist und nicht auf einem Methodenaufruf basiert. Nur One-Way Kommunikation Service-Aufruf Service Consumer SOAPNachricht Envelope Header Übertragungsspezifische Daten -optional- Body Operation definiert in Anwendungsspezifische Daten WSDL -required- file Web Service Provider Web Service “aService” : WSDL <?xml version="1.0"?> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> … </s:Header> <s:Body> <p:Person xmlns:p="http://www.myserver.de/soap"> <p:surname> Alda </p:surname> </p:Person> </s:Body> </s:Envelope> Meta-Modell Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 XML-Struktur (SOAP Document, Document-Style) Verarbeitungsmodell bei SOAP Eine SOAP-Nachricht kann über mehrer Zwischenknoten (Intermediaries) geleitet werden Intermediaries können in den Verarbeitungsprozess einer SOAP-Nachricht eingreifen Intermediaries sollten nur auf SOAP-Header zugreifen SOAP Request Service Client SOAP Request Intermediary A SOAP Response SOAP Request Intermediary B Service Provider (ultimate SOAP receiver) SOAP Response Intermediary B Intermediary Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 16 Aufbau einer SOAP-basierten Architektur mit HTTP POST web/my HTTP/1.1 Host myserver.com Content-Type: application/ soap+xml <<entity>> Person SOAP Envelope …. Client Host • <<WebService>> ERPService Application Server Web Service “ERPService” : WSDL SOAP verwendet bekannte Web-Protokolle zur Übertragung von SOAP-Nachrichten - - • HTTP <<Service Consumer>> getAddress() Standard ist HTTP: Verwendung der POST-Methode Alternative: SMTP, TCP / IP Web Service übernimmt Dispatcher Rolle Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 <<entity>> Address getCity() <<control>> Process Relocation performRelocation() Aufbau dieser Veranstaltung Kapitel 4: Einführung in Web Services, Teil 1 1 2 Überblick über Web Services Einführung in SOAP 3 Einführung in WSDL 4 Implementierung von Web Services: AXIS2 und 5 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 18 Überblick zu WSDL Die Web Service Description Language (WSDL) ist ein XML-Format, um die Schnittstelle eines Web Services zu beschreiben - - Abstrakte Beschreibung von Operationen und deren Parametern (Nachrichten) Anbindung an ein bestimmtes Netzwerk-Protokoll für den Zugriff auf einen Web Service - Interface Definition Language (IDL) Abbildung auf gängige Programmiersprachen möglich Standard: SOAP über HTTP Spezifikation des Endpunktes (Endpoints) um auf einen speziellen Web Services zugreifen zu können Zwei Standards: - - WSDL 1.1 (aktueller Standard) WSDL 2.0 (in vielen Server-Implementierungen bereits übernommen) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 19 WSDL – Grundlegende Struktur port-type abstrakt operation b operation a inMessage outMessage binding (SOAP over SMTP) konkret binding (SOAP over HTTP) service port port Meta-Modell Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Aufbau einer WSDL-Beschreibung Datentypen (types) - - - Nachrichten (message) - - Beschreibung der Datentypen der Nachrichten, die für den Aufruf eines Web Service verwendet werden Nur komplexe Datentypen müssen definiert werden, einfache Datentypen wie integer, float, double oder string sind bereits durch das grundlegende XMLSchema vorgegeben Wiederverwendung von externen Schemata (import-Befehl) Beschreibung der Nachrichten, die zwischen Client und Web Service beim Aufruf einer Operation ausgetauscht werden Eine Nachricht kann mehrere Teile haben, wobei jeder Teil einem Datentyp zugeordnet ist Schnittstellen (portType) - - In einer Schnittstellen werden eine Reihe von Operationen zusammengefasst Jede Operation ist definiert auf Basis der zuvor definierten Nachrichten und Datentypen Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 21 Aufbau einer WSDL-Beschreibung Protokoll (binding) - - Kommunikationsendpunkt (port) - Festlegung, wie mit der abstrakten Schnittstelle des Web Service kommuniziert werden kann Angabe des Kommunikationsformat (z.B. SOAP-Nachrichten) und das Transportprotokoll (z.B. HTTP) Ein einzelner Service-Endpunkt für eine Kommunikation durch die Angabe einer Adresse (z.B. eine URL) für eines der zuvor definierten Bindings. Service (service) - - Zusammenfassung einer Menge von einzelnen Endpunkten (ports) unter einem logischen Namen Mehre Ports können auf den gleichen PortType verweisen, jeweils mit anderen Binding-Alternativen Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 22 XML-basierter Aufbau einer WSDL-Beschreibung <?xml version=„1.0“> <definitions name = „StockQuote“> <types> <schema> .... </schema> </types> <message name = „PriceInput“> .... </message> <portType name = „StockQuotePortType“> <operation name = „GetLastTradePrice“> ... <operation> </portType> <binding name = „StockQuoteSoapBinding“> ... </binding> <service name = „StockQuoteService> <port name = „StockQuotePort“> .... </port> <service> <definitions> Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 23 WSDL – Struktur und Beispielcode <message name=„PersonData"> <part name=„surname" type="xsd:string"/> </message> port-type abstrakt operation b operation a inMessage outMessage binding binding (SOAP over HTTP) (SOAP over SMTP) <message name=„AddressData"> <part name=„city" type="xsd:string"/> </message> <portType name=„ERPManager"> <operation name=„GetAddress"> <input message=„PersonData "/> <output message=„AddressData"/> </operation> </portType> konkret WSDL Dokument (Ausschnitt) <s:Body> service port port Meta-Modell <GetAddress> <surname> Alda </surname> </GetAddress> </s:Body> SOAP Request (RPC-Style) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Muster für den Nachrichtenaustausch WSDL unterstützt vier verschiedene Muster zum Nachrichtenaustausch (Message Exchange Pattern, MEP) Client Web Service <input> RequestResponse Client Web Service <input> <output> SolicitResponse Client Web Service <output> <input> Notification Client Web Service <output> One-way Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 25 WSDL – Binding an Netzwerkprotokoll und Nachrichtenformat <binding name=„AdressBinding“ type = „ERPManager“ > <soap:binding style = „rpc“ // Nachrichtenformat SOAP/rpc. Alternative: document transport = „http://schemas.xmlsoap.org/soap/http“/> // HTTP als Protokoll <operation name=„GetAddress"> <soap:operation soapAction = „GetAddress“> <input> <soap:body parts=„GetAddressRequest“ ... > </input> <output> <soap:body parts=„GetAddressResponse“ ... > </output> </operation> .... </binding> WSDL-Dokument (Ausschnitt) zur Definition von Bindings Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 WSDL – Definition des Ports <service name = „ERPService“> <port name = „ERPService_http“ binding = „AdressBinding“> <soap: address location=„http://myserver.com/axis2/services/ERPService“/> </port> .... </service> WSDL-Dokument (Ausschnitt) zur Definition eines Service Zu jedem Binding wird ein Port definiert Ein Binding kann das gleiche PortType (Schnittstelle) mehrfach binden mit unterschiedlichen Protokollen / Formaten Aus der Adresse des Service und aus SOAPAction (siehe Binding) wird der betreffende HTTP_Request erstellt Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Binding - SOAP over HTTP • SOAP kann HTTP zur Übertragung von SOAP-Nachrichten verwenden - - - Standard-Binding, da transparente Übertragung über Port 80 Ausschließliche Verwendung der POST-Methode des HTTP Protokolls Übernahme der Adress-Daten aus WSDL POST /axis2/services/ERPService HTTP 1.1 Host myserver.com Content-Type: application/soap+xml SOAPAction: “urn:GetAddress” <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> … </s:Header> <s:Body> <GetAddress xmlns:m="http://www.myserver.de/soap"> <m:nachname> Alda </m:nachname> </m:GetAddress> </s:Body> </s:Envelope> HTTP-Request inkl. SOAP Nachricht Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 HTTP Header HTTP entity-body = SOAP Nachricht Software Bibliotheken für SOAP • Eine Vielzahl von Software Bibliotheken für die Entwicklung einer SOAPbasierten Web Services Architektur stehen zur Verfügung - • Unterstütze Programmiersprachen: Java, Python, PHP, C, C++ … Open Source Software Bibliotheken in Java: - - Gängige Frameworks: Apache Axis2, Apache CXF Sun Java Web Services Developer Pack (JWSDP) Name Package Java API for XML Web Services (JAXWS) javax.xml.ws Java Architecture for XML Binding (JAXB) javax.xml.bind SOAP with Attachments API for Java (SAAJ) javax.xml.soap Java Web Services Metadata (JSR 181) javax.jws Download für J2SE 1.4.2 sowie J2SE 5.0 verfügbar Ab Java SE 6 standardmäßig integriert 29 Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Code-Demo: Verwendung des JWSDP (1/2) Implementierung des Service und des Server package com.bonn.erp; package com.bonn.erp; import import import import import javax.xml.ws.Endpoint; javax.jws.WebMethod; javax.jws.WebService; javax.jws.soap.SOAPBinding; javax.jws.soap.SOAPBinding.Style; @WebService @SOAPBinding(style=Style.RPC) public class ERPManager { @WebMethod public String getAddress( String NachName ){ String Address = AdressStore.getAddress( NachName ); return Address; } } public class MyAppServer { public static void main(String[] args) { ERPManager server = new ERPManager(); Endpoint endpoint = Endpoint.publish("http://localhost:8080/ services", server); System.out.println("Server is started"); } } Java Code Web Service Coding Java Code „Application Server“ Compile Run Server javac *.java java MyAppServer Generate Stubs for Client wsimport -keep http://localhost:8080/ erpmanager?wsdl ERPManager.class Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 ERPManagerService.class Code-Demo: Verwendung des JWSDP (2/2) Implementierung des Client package com.client; import com.bonn.erp.ERPManager; import com.bonn.erp.ERPManagerService; Import der zuvor erzeugten Klassen public class MyClient { public static void main(String args[]) { // Initialisierung Web Service mit generierten Klassen ERPManagerService service = new ERPManagerService(); ERPManager manager = service.getERPManagerPort(); // Verwendung des Web Service String adresse = manager.getAddress( "Alda" ); System.out.println("Adresse von Hr. Alda: " + adresse); } } Java Code Client Import Stubs ERPManager.class ERPManagerService.class Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Compile Run Client javac *.java java MyClient (Vorläufiger) Aufbau der Vorlesung Kapitel 1 2 3 4 (11.5.) Thema Organisation, Einführung in Software-Architekturen Einführung in Service-Orientierte Architekturen Design Prinzipien von Service-Orientierten Architekturen Web Services I (SOAP, WSDL) 5 (18.5.) Web Services II (Axis2,...) 6 (25.5.) Modellierung von Geschäftsprozessen (BPEL, BPMN) 7 (1.6.) Vertiefung und Backup Web Services 8 (8.6.) OSGi Service Plattform 9 (15.6.) Einführung in Swordfish 10 11 (22.6.) REST Architekturen Exception Handling in SOA (Gastvortrag) 12 (29.6.) SOA Point of View von Accenture (Gastvortrag) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 32 Zeitplan der Team-Präsentationen Kapitel 8.6. Thema Vortrag 1: (Team ) Vortrag 2: (Team ) 15.6. Vortrag 3: (Team ) Vortrag 4: (Team ) Vortrag 5: (Team ) 22.6. Vortrag 6: (Team ) Vortrag 7: (Team ) 29.6. Vortrag 8: (Team ) Vortrag 9: (Team ) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 33 Überblick Team-Präsentationen Team Fanta5 Temporär Blau Gummibärenbande ichweissnicht Jajowada Mars Massup Sprint Temporär Thema Finanzbuchhaltung in einem ERP-System Persistente Speicherung von Daten Verarbeitung elektronischer Rechnungen Zukunftsweisende Hardware-Struktur Software für Digitale Signatur Bearbeitung von KPI Portal-Integration Scannen und Integration von Dokumenten Zugriff auf LDAP-Verzeichnis Persistente Speicherung von Daten Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 34
