1 / 18

Teleseminar „Web Services“

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

jacob-potts
Download Presentation

Teleseminar „Web Services“

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. SAP NetWeaver mySAP PLM mySAP ERP Financials Human Resources Corporate Services Operations Management mySAP CRM mySAP SRM mySAP SCM 1. Übersicht SAP Zentrale Komponente: Web Application Server

  4. 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

  5. 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

  6. 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

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

  8. 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 !

  9. 7. Design Prozessfolge eines adaptiven WS für ISA

  10. 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 Businesslogik

  11. 7. Design Integration von Web Services in die Architektur von ISA / J2EE Engine

  12. 7. Design Sequenzdiagramm adaptiver Web Services in ISA

  13. 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)

  14. 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

  15. 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!)

  16. 10. Fazit Web Services heute • Einsatzgebiete: • 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)

  17. 10. Fazit Web Services in Zukunft • Einsatzgebiete: • 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

  18. Fragen? • Kontakt: Markus.Uhlig@sap.com

More Related