Das erste Kapitel der Arbeit erklärt das zu bearbeitende Thema und die Aufgabenstellung. Es wird aufgezeigt, was die Diplomarbeit leisten sollte und warum sie durchgeführt wurde.
Die praktische Aufgabenstellung kam aus dem Geschäftsbetrieb der FirmaSamsung Semiconductor Europe.
Samsung Semiconductor Europe vertreibt die in Korea hergestellten Halbleiterprodukte und TFT-Panels für den europäischen Markt. Das Kundenspektrum reicht von Großkonzernen wie IBM, DELL, Hewlett Packard, Nokia und Siemens, über Wiederverkäufer bis hin zu kleinen Computerläden.
Während des Vertriebsprozesses fallen eine Vielzahl von Informationen und Daten an, die im SAP R/3 System von Samsung gespeichert sind. Am Anfang des Prozesses steht die Bestellung, daraus ergibt sich die Lieferung und endet in der Rechnungsstellung.
Möchte ein Kunde sich einen Überblick über diese Daten verschaffen, so kontaktiert er Samsung telefonisch, per Fax oder Email. Diese Vorgehensweise ist jedoch nicht nur fehleranfällig, weil man sich beispielsweise missverstehen kann oder das Fax schlecht zu lesen ist. Weiterhin bindet es teure Arbeitszeit eines Mitarbeiters bei Samsung.
Die Idee von Samsung war es, ein Kundeninformationssystem zu schaffen. Die benötigten Informationen können so über das Internet dem Kunden zur Verfügung gestellt werden. Dieser kann in einem Self-Service-Szenario seineDaten jederzeit und immer aktuell einsehen.
Als weiteres Einsatzgebiet sollte das Kundeninformationssystem dazu genutzt werden, eine Reklamation über das Internet anzustoßen.
Inhaltsverzeichnis
- 1 EINLEITUNG
- 1.1 AUFGABENSTELLUNG
- 1.2 ANFORDERUNGEN
- 1.3 ZIELE
- 1.4 MOTIVATION
- 1.5 BEDEUTUNG VON KUNDENINFORMATIONSSYSTEMEN
- 1.6 KAPITELÜBERSICHT
- 2 KOMPONENTENARCHITEKTUREN
- 2.1 EINFÜHRUNG
- 2.2 EINORDNUNG
- 2.3 KONZEPTE
- Microsofts Component Object Model (COM)
- Microsofts Anforderungen
- Sun Microsystems Enterprise JavaBeans (EJB)
- Suns Anforderungen
- Zusammenfassung
- 2.4 COM / DCOM
- Allgemeine Konzepte
- Sprachunabhängigkeit
- Technische Realisierung
- Schnittstellen
- Statische Bindung
- Dynamische Bindung
- Schnittstellenbasierte Programmierung
- Unveränderlichkeit von Schnittstellen
- Die Standardschnittstelle IUnknown
- Abfragen von Schnittstellen
- Objekterstellung und Destruktion
- IDL – Interface Definition Language
- Implementierung
- COM-Klassen
- Klassenobjekte
- COM-Server
- Apartments / Threading in COM
- Apartment-Threading
- Free-Threading
- Threading in C++ und Visual Basic
- Neutrale Apartments
- COM und die Windows-Registrierungsdatenbank
- DCOM transparent verwenden
- Interoperabilität von C++ und VB Komponenten
- Typbibliotheken (Typelibraries)
- C/C++ Client
- Visual Basic Client
- C/C++ Server
- Visual Basic Server
- Proxy / Stub Code
- Fehlerbehandlungsmechanismen
- Bewertung der Interoperabilität zwischen Visual Basic und C++
- 3 APPLIKATIONSSERVER
- 3.1 EINFÜHRUNG
- 3.2 DEFINITION
- 3.3 GRÜNDE FÜR DEN EINSATZ
- 3.4 MEHRSCHICHTIGE ANWENDUNGSSYSTEME
- 3.5 ALLGEMEINES KONZEPT
- 3.6 MICROSOFT TRANSACTION SERVER
- Bedingungen für COM-Komponenten zur Ausführung im MTS
- Verwaltung der Komponenten im MTS
- 3.7 ENTERPRISE JAVABEANS
- Konzepte der EJB
- Session Beans
- Entity Beans
- Verwaltung von EJBs durch den Applikationsserver
- EJB-Server
- EJB-Container
- Transaktionsunterstützung
- Persistenz
- Sicherheitsfunktionen
- Management für konkurrierenden Zugriff und viele Instanzen
- 3.8 TRANSAKTIONSMECHANISMEN
- ACID Kriterien
- Einfache und verteilte Transaktionen
- Einfache Transaktionen
- Verteilte Transaktionen
- Zwei-Phasen Commit (2PC) Protokoll
- Architektur verteilte Transaktionen
- Standards
- IBM LU6.2
- ISO OSI-TP
- X/Open DTP
- OLE Transactions
- Transaktions-Manager
- Ressource-Manager
- Transaktions-Modelle
- Flat Transaction (Flache Transaktion)
- Chained Transaction (Gekettete Transaktion)
- Nested Transaction (Eingebettete Transaktion)
- Distributed Transaction (Verteilte Transaktion)
- Mulit-Level Transaction (Multi-Level Transaktion)
- Open-nested Transaction (Offen eingebettete Transaktion)
- Long-lived Transaction (Langlebige Transaktion)
- Sperrmechanismen
- Isolations-Level
- Read Uncommitted (Unbestätigtes lesen)
- Read Committed (Bestätigtes lesen)
- Repeatable Read (Wiederholbares lesen)
- Serializable (Serialisierbares lesen)
- Isolations-Level
- Vergleich von EJB und MTS
- Applikationsserver Transaktionen
- Traditionelles Prinzip
- Applikationsserver Prinzip
- Transaktions-Kontext
- MTS
- Anwendung
- EJB
- Verwendung
- Verteilte Transaktionen
- Bewertung
- 3.9 EINBINDUNG VON EXTERNEN PROGRAMMEN
- MTS
- EJB
- Zusammenfassung
- 3.10 PERSISTENZ
- MTS
- EJB
- 3.11 ZUSAMMENFASSUNG
- 4 WRAPPING VON LEGACY-SYSTEMEN
- 4.1 DEFINITION
- 4.2 VARIANTEN DES LEGACY-WRAPPING ZUGRIFFS
- Datenschnittstellen
- Graphische Benutzerschnittstellen
- Programmierschnittstellen (API)
- Kommandozeilen Benutzerschnittstellen
- 4.3 SAP R/3
- Charakteristiken
- Eigenständigkeit:
- Echtzeitfähigkeit:
- Mehrbenutzerfähigkeit:
- Client-Server System
- Multi-Plattformsystem
- Modularität
- Das SAP Business Framework
- Business-Komponenten
- Business-Objekte
- Business Application Programming Interfaces (BAPIs)
- Integrationsdienst ALE (Application Link Enabling)
- Kommunikationsdienste
- Business Objekte
- BAPI
- Gründe für die Verwendung für BAPI
- Kommunikation mit dem R/3 System
- RFC SDK - C Bibliothek
- RFC C++ SDK
- COM-Objekte für SAP-Zugriff
- DCOM-Connector
- RFC Java Class Library
- IBMs Access Builder for SAP R/3
- COM-Objekte für SAP-Zugriff
- SAP Logon Komponente
- SAP RFC Komponente
- BAPI-Komponente
- Hilfskomponenten für Tabellen und Strukturen
- Berechtigungen für BAPI-Aufrufe
- Transaktionsverarbeitung mit BAPIs
- Outbound Aufrufe
- Intermediate Document (IDOC)
- Ausblick
- Charakteristiken
- 4.4 MICROSOFTS UNIVERSAL DATA ACCESS ARCHITEKTUR
- ADO
- OLE DB
- ODBC
- 5 REALISIERUNG DES KUNDENINFORMATIONSSYSTEMS
- 5.1 ANALYSE
- Konzeptionelle Anforderungen
- Analyse der Szenarien
- Lieferstatus
- Zielsetzung
- Analyse der darzustellenden Informationen
- Reklamationen
- Zielsetzung
- Analyse der darzustellenden Informationen
- Lieferstatus
- 5.2 DESIGN DES SYSTEMS
- Architektur des Kundeninformationssystems
- Webserver Skripte und Webformular
- Benutzerverwaltung
- Wrapperkomponenten für den SAP R/3 Zugriff
- 5.3 IMPLEMENTIERUNG
- Admininistrationsfrontend
- Microsoft Management Console (MMC)
- COM
- SAP Business Objekt-Wrapper
- Datenbankkomponente
- EJB
- 5.4 RESÜMEE DES PRAKTISCHEN TEILS
- 5.1 ANALYSE
- 6 AUSBLICK
- ANHANG
- A QUELLENVERZEICHNIS
- A.1 Literatur, Zeitungs- und Internetartikel
- A.2 Technische Referenzen
- A.3 Wissenschaftliche Literatur
- B ABKÜRZUNGSVERZEICHNIS
- C QUELLCODE
- C.1 IDL – Beschreibung der COM-Komponenten für die SAP BO Wrapper
- C.2 COM-Komponte – SAP BO Wrapper „Offene Rechnungen“
- C.3 Enterprise Java Bean – SAP BO Wrapper „Auftragsstatus“
- C.4 Implementierung der Datenbank-Komponente
- A QUELLENVERZEICHNIS
Zielsetzung & Themen
Die vorliegende Diplomarbeit befasst sich mit der Entwicklung und vergleichenden Analyse eines verteilten Kundeninformationssystems für Samsung Semiconductor Europe. Das Hauptziel ist es, ein System zu realisieren, das Kunden über das Internet aktuelle Informationen aus dem SAP R/3 System bereitstellt und Reklamationen ermöglicht, wobei zwei Technologiestränge – Microsoft COM/MTS und Java/EJB – zur Bewertung und Einschätzung ihrer Eignung gegenübergestellt werden.
- Vergleichende Analyse von Komponentenarchitekturen (Microsoft COM und Sun Enterprise JavaBeans).
- Detaillierte Untersuchung von Applikationsservern (Microsoft Transaction Server und Gemstone/J) sowie deren Transaktions- und Persistenzmechanismen.
- Methoden und Herausforderungen des Wrappings von Legacy-Systemen, insbesondere die Integration von SAP R/3 mittels verschiedener Schnittstellen.
- Analyse der Interoperabilität zwischen unterschiedlichen Programmiersprachen (C++ und Visual Basic) in der COM-Programmierung.
- Praktische Implementierung eines Kundeninformationssystems mit Fokus auf SAP R/3-Anbindung und Benutzerverwaltung.
- Design und Realisierung eines Administrations-Frontends für die Systemverwaltung.
Auszug aus dem Buch
Microsofts Component Object Model (COM)
Entnommen aus der COM-Spezifikation [Mic95, Kapitel 1 - Seite 3], sieht Microsoft folgende nachteilige Gründe an traditionellen Anwendungen, welche durch eine Komponentenarchitektur verbessert werden sollen:
„I. Today’s applications are large and complex — they are time-consuming to develop, difficult and costly to maintain, and risky to extend with additional functionality.
II. Applications are monolithic — they come pre-packaged with a wide range of features but most features cannot be removed, upgraded independently, or replaced with alternatives.
III. Applications are not easily integrated — data and functionality of one application are not readily available to other applications, even if the applications are written in the same programming language and running on the same machine.
IV. Programming models are inconsistent for no good reason. Even when applications have a facility for cooperating, their services are provided to other applications in a different fashion from the services provided by the operating system or the network. Moreover, programming models vary widely depending on whether the service is coming from a provider in the same address space as the client program (via dynamic linking), from a separate process on the same machine, from the operating system, or from a provider running on a separate machine (or set of cooperating machines) across the network.“ [Mic95 – Kapitel 1, Seite 3]
Microsofts Anforderungen
Welche Anforderungen an eine Komponentenarchitektur können hieraus abgeleitet werden?
Ist ein Anwendungssystem in einzelne, unabhängige Komponenten zerteilt, so sind Teile des Systems besser wiederverwendbar. Das gesamte System ist besser erweiterbar und die Implementierung einzelner Komponenten ist besser änderbar, wobei die Schnittstellen dieser Komponenten konstant bleiben müssen.
Zusammenfassung der Kapitel
1 EINLEITUNG: Stellt das zu bearbeitende Thema, die Aufgabenstellung von Samsung Semiconductor Europe, die Anforderungen und die Ziele der Diplomarbeit vor, die die Entwicklung eines Kundeninformationssystems unter Einsatz moderner Komponentenarchitekturen umfasst.
2 KOMPONENTENARCHITEKTUREN: Erläutert das Konzept von Komponentenarchitekturen, insbesondere Microsofts Component Object Model (COM), und untersucht die Interoperabilität zwischen verschiedenen Programmiersprachen sowie technische Grundlagen wie Schnittstellen und Threading-Modelle.
3 APPLIKATIONSSERVER: Beschreibt Applikationsserver im Allgemeinen, vergleicht Microsoft Transaction Server (MTS) und Enterprise JavaBeans (EJB) detailliert hinsichtlich Transaktionsunterstützung, Persistenzmechanismen und Integrationsmöglichkeiten externer Programme.
4 WRAPPING VON LEGACY-SYSTEMEN: Definiert den Begriff des Wrappings von Altsystemen, beleuchtet verschiedene Zugriffsvarianten und konzentriert sich auf die Integration von SAP R/3 sowie Microsofts Universal Data Access (UDA) Architektur.
5 REALISIERUNG DES KUNDENINFORMATIONSSYSTEMS: Beschreibt die Analyse, das Design und die Implementierung des Kundeninformationssystems, das als praktischer Teil der Arbeit entstand, einschließlich der Benutzerverwaltung und der SAP R/3 Wrapper-Komponenten in zwei Technologie-Ansätzen.
6 AUSBLICK: Bietet eine abschließende Einschätzung und einen Ausblick auf zukünftige Entwicklungen im Bereich der behandelten Themen.
Schlüsselwörter
Kundeninformationssystem, Verteilte Systeme, Applikationsserver, Component Object Model (COM), Enterprise JavaBeans (EJB), Legacy-Systeme, Wrapping, SAP R/3, Transaktionsmanagement, Persistenz, Interoperabilität, N-Tier Architektur, DCOM, Microsoft Transaction Server (MTS), Java 2 Enterprise Edition (J2EE)
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
In dieser Arbeit geht es um die Entwicklung und vergleichende Analyse eines verteilten Kundeninformationssystems für Samsung Semiconductor Europe, das Daten aus einem SAP R/3 Legacy-System über moderne Komponentenarchitekturen zugänglich macht.
Was sind die zentralen Themenfelder?
Die zentralen Themenfelder sind Komponentenarchitekturen (COM, EJB), Applikationsserver (MTS, Gemstone/J), das Wrapping von Legacy-Systemen (insbesondere SAP R/3) und die Interoperabilität zwischen verschiedenen Programmiersprachen.
Was ist das primäre Ziel oder die Forschungsfrage?
Das primäre Ziel ist die Realisierung eines Kundeninformationssystems in einer mehrschichtigen Architektur unter Verwendung und Bewertung von Microsoft- und Java-Technologien, um einen Überblick über deren Möglichkeiten zur Integration von SAP R/3 zu erhalten.
Welche wissenschaftliche Methode wird verwendet?
Die Arbeit umfasst eine tiefgehende Analyse der Anforderungen, ein detailliertes Design und die Implementierung des Systems auf Basis zweier unterschiedlicher Technologiestränge (Microsoft-Produkte und Javatechnologien) für einen direkten Vergleich.
Was wird im Hauptteil behandelt?
Der Hauptteil behandelt ausführlich Komponentenarchitekturen wie COM, die Konzepte und Vergleiche von Applikationsservern wie MTS und EJB, das Wrapping von Legacy-Systemen am Beispiel von SAP R/3 und die konkrete Realisierung des Kundeninformationssystems.
Welche Schlüsselwörter charakterisieren die Arbeit?
Schlüsselwörter sind Kundeninformationssystem, Verteilte Systeme, Applikationsserver, Component Object Model (COM), Enterprise JavaBeans (EJB), Legacy-Systeme, Wrapping, SAP R/3, Transaktionsmanagement, Persistenz, Interoperabilität, N-Tier Architektur, DCOM, Microsoft Transaction Server (MTS), Java 2 Enterprise Edition (J2EE).
Warum wurde das Kundeninformationssystem mit zwei unterschiedlichen Technologiesträngen realisiert?
Das System wurde mit zwei Technologiesträngen (Microsoft-Produkte und Javatechnologien/J2EE) realisiert, um einzelne Produkte und Technologien einschätzen und bewerten zu können und eine Vergleichbarkeit der Ansätze zu ermöglichen.
Welche Rolle spielt SAP R/3 bei der Entwicklung des Kundeninformationssystems?
SAP R/3 dient als zentrale Datenquelle für das Kundeninformationssystem, da hier alle relevanten Informationen aus den Geschäftsprozessen von Samsung Semiconductor Europe gespeichert sind. Die Integration von SAP R/3 ist daher eine Kernaufgabe der Arbeit.
Was sind die Hauptunterschiede in der Persistenzunterstützung zwischen MTS und EJB?
Der Microsoft Transaction Server (MTS) in Version 2.0 unterstützt keine Persistenz für COM-Komponenten, erfordert also manuelle Synchronisation. Enterprise JavaBeans (EJB) hingegen unterstützt Persistenz durch Entity Beans, entweder bean-managed oder container-managed, wobei letztere die Synchronisation transparent durch den Applikationsserver handhabt.
- Arbeit zitieren
- Oliver Klaus Kurt (Autor:in), 2000, Entwicklung eines verteilten Kundeninformationssystems , München, GRIN Verlag, https://www.grin.com/document/185416
