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 Uhlig20. Juli 2004

SAP AG 2004, Teleseminar “Web Services” (Universität Mannheim), Markus Uhlig 2

Inhalt

Inhalt1. Übersicht SAP

2. Einsatz von Web Services bei SAP

3. Einführung Internet Sales Application (ISA)

4. Anforderungsspezifikation

5. Systemarchitektur von Web Services für ISA

6. Datenadaption durch Content Repurposing

7. Design

8. Implementierung

9. Performance

10.Fazit


1. Übersicht SAP

SAP NetWeaver

mySAP SCM

mySAP PLM

mySAP SRM

mySAP CRM

mySAP ERPFinancials

Human ResourcesCorporate Services

Operations Management

Zentrale Komponente: Web Application Server


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

SAP Client

SAP Web Application Server (WAS)

Java Personality J2EE Engine

ABAP Personality

JCoBusiness Server Pages

Business Objects

JSPs / Servlets

Session / Entity Beans

Internet Communication Manager (ICM)

DBMS

PC ( Internet Browser )

Power User / Distributor RFC

SMTP

HTTP

SOAP over HTTP

Mobile Devices (PDAs etc.)

SOAP Framework SOAP Framework


6. Datenadaption durch Content Repurposing

Ziel: Berücksichtigung von unterschiedlichen Formfaktoren der Clients1. 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

2. Adaptionsstrategien Adaption beim Client Adaption über Proxy Adaption beim Sender

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


7. Design

Prozessfolge eines adaptiven WS für ISA


7. Design

Analyse und Systemarchitektur ISA

J2EE Engine

Businesslogik

Interaction & Presentation

Abbildung der Business-logik, ohne Backend-berücksichtigung

Abbildung der Business-logik, mit backendspezifischer Implementierung


7. Design

Integration von Web Services in die Architektur von ISA

/ J2EE Engine


7. Design

Sequenzdiagramm adaptiver Web Services in ISA

ClientApp WSmyService MyServiceImpl ISA ApplicationInitWSIF CAP

new InitWSIFstartService

getDataObjects

StructureOfDataObjects

getAdaptedObject

AdaptedDataObject

AdaptedDataObject

Response withadaptedDataObjectin XML/SOAP

Request withParametersin XML/ SOAP

Stub (Proxy) Stub (Skeleton)

Method ()

Response

Java,VB, c++

etc.

(Un)Marshaling

Java

Method()

(Un)Marshaling

Response

controlsAdaption:DCF, ACG,CAE


8. Implementierung

1. TechnologienW3C, .Net, J2EE (JAX-RPC/B/P etc.)

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

1. Java Beans als Basis für Schnittstellenbeschreibung

2. Interface-Kompatibilität durch Generic Data Types aus XI

3. Implementierung Anwendungslogik bzw. Funktionalität

4. Erzeugung WSD (Virtual Interface, Web Service Definition, Web Service Configuration)

5. Komprimierung Web Service Archive (WSAR)

6. Zusammenführung WAR (ISA) und WSAR in Enterprise Archive (EAR)

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

1. Lokalisierung WSD

2. Generierung Proxy- bzw. Stubklassen (.Net, JAX-RPC)

3. Einbindung in Programmcode und Aufruf der Service-Methoden über Service-Proxy


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:

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:

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: [email protected]

Documents

Teleseminar „Web Services“