Teleseminar „Web Services“ Bereitstellung von Business-Funktionen aus SAP Internet Sales als Web Services unter Berücksichtigung von Formfaktoren heterogener Clients Markus Uhlig 20. Juli 2004

Inhalt Inhalt Übersicht SAP Einsatz von Web Services bei SAP Einführung Internet Sales Application (ISA) Anforderungsspezifikation Systemarchitektur von Web Services für ISA Datenadaption durch Content Repurposing Design Implementierung Performance Fazit Begrüßung Inhalt erläutern

Operations Management 1. Übersicht SAP SAP NetWeaver mySAP SCM mySAP PLM mySAP SRM mySAP CRM mySAP ERP Financials Human Resources Corporate Services Operations Management Zentrale Komponente: Web Application Server Ziel der Einführung: Motivation der präsentierten Technologien Dienste im Internet heute: Vielzahl interaktiver Dienste verschiedenster Anbieter Gemeinsamkeit, dass sie in Web-Anwendungen integriert sind und die Darstellung durch den Einsatz der Hypertext Markup Language(HTML) komplett auf menschlichen Benutzer zugeschnitten Herkömmliche Nutzungsformen Zu 1. Darstellung der Dienste erfolgt in einem Web-Browser über grafisch aufgearbeitete Formularfelder Wie erfolgt Benutzung oder Bereitstellung solcher Dienste: öffentlichen Web-Seiten der Anbieter aufzusuchen -> direkt den Dienst auszuführen oder per Link einzubinden keineswegs automatisierbar bzw. im Falle eines Links durch den bedingten Seitenwechsel recht aufwändig zudem wäre diese Lösung zwar für einen Menschen benutzbar, aber für eine automatische Verarbeitbarkeit völlig ungeeignet, Grund: HTML fehlen Semantikinformationen Zu 2.) direkter Zugriff auf die vorhandenen Datenbanken und Backendsysteme und daraus die Daten zu gewinnen in den wenigsten Fällen möglich sein, weil Unternehmen in der Vergabe von Zugriffsberechtigungen auf die internen Datenbanken generell externe Benutzer standardmäßig über Web Seite gezielte Funktionalität Angenommen wird jedoch gewährt -> nächstes Problem: Wie kann man die Schnittstelle des verwendeten Informationssystems bzw. der Datenbank verfügbar machen? Verwendung unterschiedliche Programmiersprachen mit eigenen Schnittstellenbibliotheken (engl. Application Programming Interface = APIs) und Abfragesprachen (SQL, ABAP für SAP R/3-Systeme) -> Für jede Systemverbindung neue Schnittstelle -> Vielzahl unterschiedlichster Schnittstellenvarianten + extremer Wartungsaufwand Besser: Middleware, Nachteil vieler Middleware-Lösungen: komplexe Ablaufumgebungen, relativ komplexe und oft proprietäre Protokolle, einzelnen Ansätze zueinander inkompatibel Verbesserung: Web Services als eingesetzte Middleware - Menge wohl strukturierter Daten, dessen Semantik bekannt ist (anders als bei HTML) keine direkten und unerwünschten Zugriffe auf internen Datenbestände eines Unternehmens -> Web Server Benutzung einfacher und vor allem standardisierter Protokolle, nicht wie bei anderen Middleware-Ansätzen

2. Einsatz von Web Services bei SAP SAP Mitglied der WS-Interoperability Group (WS-I) Web Services bei SAP „business driven“ Ziel: Lösung von Kundenproblemen bzgl. heterogener Systemlandschaften  Innerhalb eines Unternehmens: Vielzahl unterschiedlicher Systeme im Einsatz  Vielzahl unterschiedlicher Schnittstellen, Programmiersprachen, Betriebssysteme und Hardware Bisher teure und komplexe Enterprise Application Integration (EAI) – Lösungen (Bsp.: WebSphere, BizTalk etc.) Verbesserung bestehender EAI – Lösungen  Enterprise Service Architecture  Über Firmennetzwerk hinaus: Business-to-Business (B2B) – Integration  Verwendung der Internet-Infrastruktur zur Kommunikation  Web Services ideal geeignet (Bsp.: Erweiterung von Web Anwendungen (ISA) durch Web Services)  Web Services als Schnittstellentechnologie / Integrationswerkzeug Enterprise Portal Exchange Infrastructure Web Application Server

3. Einführung Internet Sales Application (ISA) ISA aus betriebswirtschaftlicher Sicht: Web Shop (Bsp.: Conrad, Sony etc.) Funktionen aus CRM über Kommunikationskanal Internet Steuerung Einkaufsprozess für B2B/B2C: Suche nach Produkten / Produktdetails Verfügbarkeitsprüfung Preisberechnung (konditionenabhängig) Auftragsgenerierung / Statusabfrage ISA aus technischer Sicht: 3-Tier-Anwendung basierend auf J2EE-Plattform  JSPs, Servlets zur Darstellung dynamischer Webseiten  Struts zur Steuerung der Anwendung  Trennung von Präsentation und Anwendungslogik (MVC) Laufzeitumgebung J2EE Engine des WAS (deployed auf J2EE-Server) Backendsystem R/3,CRM-System (ABAP), kombiniert mit bel. DBMS Kommunikation mit Backend über JCo und JDBC

4. Anforderungsspezifikation ISA bisher: Zugang nur für browserfähige Endgeräte Keine Automatisierung für Power-User (Zwischenhändler) Keine Berücksichtigung von Formfaktoren heterogener Endgeräte  keine Anpassung der übermittelten Daten (Bsp.: mulimediale Daten)  Bereitstellung von Business-Funktionen als Web Services Anforderungen: Integration WS in ISA-Architektur Erweiterung der bestehenden Funktionalität Erweiterbarkeit durch generische Architektur Verwendung Generischer Datentypen (GDT CCT  XML Data Types) für Schnittstellenbildung Optionaler Adaptionsprozess Fragestellungen: Interoperabilität von Web Services (J2EE / .Net) Evaluierung Web Services für Produktiveinsatz in ISA (Grenzen von WS) Komplexität Implementierung Performanceaspekte Restriktionen: Keine Verwendung von UDDI Kein XML-Encryption Kein Session-Handling (keine Cockies bzw. Session-Ids), BPEL4WS

5. Systemarchitektur von Web Services für ISA PC ( Internet Browser ) SAP Client SAP Web Application Server (WAS) RFC Power User / Distributor Mobile Devices (PDAs etc.) Internet Communication Manager (ICM) SMTP Java Personality J2EE Engine ABAP Personality HTTP SOAP over HTTP SOAP Framework SOAP Framework JSPs / Servlets Business Server Pages JCo Session / Entity Beans Business Objects DBMS

6. Datenadaption durch Content Repurposing Ziel: Berücksichtigung von unterschiedlichen Formfaktoren der Clients Definition: Content Repurposing automatische Aufbereitung bzw. Anpassung von Daten für unterschiedliche Formfaktoren von Endgeräten bestehende Daten meist für spezielle Anwendung erstellt lediglich eine einzige Kopie der unveränderten Daten Aufbereitung der Daten in Echtzeit Adaptionsstrategien Adaption beim Client Adaption über Proxy Adaption beim Sender Adaptionsprozess 1. Analyse und Charakterisierung von Daten  Einteilung in Kategorien 2. Adaption der Daten durch Translations- und Kompressionsmethoden  Abhängig von Clientprofil und Adaptionsfähigkeit der Daten Client-Informationen müssen vorab übermittelt werden ! Motivation: Vielfalt internetfähiger Endgeräte  Heterogenität steigt an Technisch variieren diese Geräte von High-Performance PC bis zu einfachen Smartphones Tradeoff bei der Entwicklung  Kompromisse bei technischer Ausstattung  nicht in der Lage Daten darzustellen oder zu verarbeiten Anpassung der bestehenden Daten für jedes Gerät im Voraus zu komplex und aufwändig (Zeit + Speicher) + Gefahr der Dateninkonsistenz

7. Design Prozessfolge eines adaptiven WS für ISA nicht das Ziel neue Technologien oder Algorithmen im Bereich der Adaption zu entwickeln sondern erweiterbare Architektur, die Web Services und Adaptionsprozess kombiniert Was verbindet WS und CR ? Was fehlt beiden ? Problem vieler gängiger Ansätze für CR  beschränkt auf bestimmte Formate Eigenschaften: modular  lose entkoppelt erweiterbar  Plugin-Prinzip

Analyse und Systemarchitektur ISA 7. Design Analyse und Systemarchitektur ISA J2EE Engine Interaction & Presentation Abbildung der Business- logik, ohne Backend- berücksichtigung Abbildung der Business- logik, mit backendspezifischer Implementierung ISA: Beschränkt auf Darstellung und Interaktionsfluss des Benutzers im Shop Business-Logik bleibt im Backendsystem Drei-Schicht-Architektur Interaktion mit Benutzer über Struts  Model View Controller Pattern Business Objects enthalten Business-Logik unabhängig vom Backendsystem Businesslogik

Integration von Web Services in die Architektur von ISA 7. Design Integration von Web Services in die Architektur von ISA / J2EE Engine Möglichkeiten : - komplette Funktionalität ersetzen  keine Lösung  ISA lediglich erweitern Unterschiede WS zu gewöhnlicher Web Anwendung  keine grafische Benutzeroberfläche in WS Beschreibung Modell

Sequenzdiagramm adaptiver Web Services in ISA 7. Design Sequenzdiagramm adaptiver Web Services in ISA Folie überarbeiten ….

8. Implementierung Technologien W3C, .Net, J2EE (JAX-RPC/B/P etc.) Benötigte Werkzeugsammlung (Service-Provider) J2EE-Server  J2EE Engine (WS Toolkit) im Web Application Server Web Service Toolkit im WAS, basierend auf JWSDP Bean- / EJB-Methoden als WS Generierung WSDL-Beschreibungen für installierte Beans Integration Engine (Monitoring-, Logging-, Tracing-, Analysefunktionen) Dynamisches Aufrufen von WS durch SOAP-Framework (WS-Navigator) IDE  NetWeaver Developer Studio (Eclipse) Basierend auf Eclipse 2.0 (Open Source Produkt von IBM) Erweiterung der Plug-In Architektur (Extension-Points = Zugangspunkte für Erweiterungen) Entwicklung Java-basierter (Web-)Anwendungen (J2EE-Toolset, WS-Toolset) Unterstützung J2EE-Engine (Direct Deploy, Remote Debugging)

8. Implementierung Implementierung der (adaptiven) Web Services in ISA Beschränkt auf Laufzeitumgebung von ISA  J2EE-Engine Vorgehensweise definiert durch JWSDP: Java Beans als Basis für Schnittstellenbeschreibung Interface-Kompatibilität durch Generic Data Types aus XI Implementierung Anwendungslogik bzw. Funktionalität Erzeugung WSD (Virtual Interface, Web Service Definition, Web Service Configuration) Komprimierung Web Service Archive (WSAR) Zusammenführung WAR (ISA) und WSAR in Enterprise Archive (EAR) Deployment EAR Verfügbarkeit WSD auf J2EE Engine Clientimplementierung Einsatz beliebiger Tools und Programmiersprachen (Bsp.: Excel-Integration, Standalone-App) Voraussetzung: Standardeinhaltung des W3C Prinzipielle Vorgehensweise: Lokalisierung WSD Generierung Proxy- bzw. Stubklassen (.Net, JAX-RPC) Einbindung in Programmcode und Aufruf der Service-Methoden über Service-Proxy classs{ }

9. Performance Viele Faktoren: WS-Implementierungen (JAX-RPC, .Net), Systemumgebung (Netzwerk, J2EE-Server, etc.) Ziel: Allgemeine Aussagen über die Performance von WS-Technologien Speicherplatz: SOAP textbasiert, Verwendung SOAP-Template  Daten-Overhead (Bsp. Grafik, Integer-Array) Zeit: Marshalling- und Parsing-Pozesse (75 % der Gesamtprozesszeit, nach Abzug Netzwerkdelay)  hohe Verarbeitungszeit von SOAP-Nachrichten im Vgl. zu andern Middleware-Ansätzen  hohe Latenzzeit (Nullfunktionen mind. um Faktor 10 höher als bei CORBA und RMI) ungeeignet für zeitkritische Anwendungen (hierfür auch nicht entworfen!)

10. Fazit Web Services heute Einsatzgebiete: Vorteile: Probleme: Geschäftsschnittstellen (Bsp.: B2B) Integrationswerkzeug (Ad-hoc-Integration per SOAP) Vorteile: Einfache Verwendung durch Vielzahl von Tools (Bsp.: Remote Debugging, WSNavigator) standardisiert: offene Standards  benutzen Internet-Infrastruktur (Bsp. Firewalls, Lastverteiler)  einfache Integration in Web- und Applikationsserver (vgl. Integration in ISA) vermiedene Komplexität  stabile Implementierungen Interoperabel (Bsp. Verbindung J2EE, .Net  Excel-Integration) Security-Aspekt: Freigabe gezielter Funktionen (dadurch aber Application-Level Firewalls notwendig) Probleme: Fehlende Standards Session-Handling für übergreifendes Transaktionsverhalten (evt. BPEL4WS) Sicherheitsproblem (offenes XML-Format  WS Security Implementierung oft nicht kompatibel zueinander) Attachements ( DIME/MIME) Implementierung: Java Serializable Interface  Verwendung Byte-Array mit Einschränkungen verwendbar Verbesserungspotential bei Performance (Marshalling-, Parsingprozesse)

10. Fazit Web Services in Zukunft Einsatzgebiete: Erfolgsindikatoren: Middleware-Lösung und Integrationswerkzeug verschiedenster Anwendungen (über B2B hinaus) Bsp.: Synergieeffekte durch Kombination von Middleware und Content Repurposing WS-basierte Grids (Bsp. Globus Toolkit) Kontrollprotokoll in Multiprotokollumgebung ( Versendung nicht-textbasierter Datenformate ) Erfolgsindikatoren: Vielfältigkeit der möglichen Einsatzgebiete und einfache Verwendung Beteiligung und Unterstützung aller großen Softwarehersteller (Indigo in MS Longhorn, IBM WebShpere, SAP NetWeaver etc.)  wichtige Komponente für global verteilte Systemarchitektur

Fragen? Kontakt: Markus.Uhlig@sap.com