Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business

Transkript

1 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business Studienarbeit von Norman Messina aus Freiburg i. Br. BERUFSAKADEMIE LÖRRACH STAATLICHE STUDIENAKADEMIE UNIVERSITY OF COOPERATIVE EDUCATION Ausbildungsbereich Wirtschaft Betreuender Dozent: Prof. Dr. Jürgen Treffert Abgabetermin: 8. März 2004 Kurs: WWI 01 B Fachrichtung Wirtschaftsinformatik Unternehmen Agilisys Automotive GmbH Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 1

2 EINLEITUNG Ehrenwörtliche Erklärung Ich versichere hiermit, dass ich meine Studienarbeit mit dem Thema Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Bad Krozingen, 6. März 2004 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 2

3 EINLEITUNG Danksagung Für die immer freundliche Unterstützung bei der Anfertigung dieser Arbeit danke ich insbesondere Herrn Dr. Prof. Jürgen Treffert. Ein Dank gilt auch meiner Mutter, Sylvia Messina, für das Korrekturlesen. Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 3

4 EINLEITUNG Inhaltsverzeichnis Seite Ehrenwörtliche Erklärung...2 Danksagung...3 Abkürzungsverzeichnis...6 Abbildungsverzeichnis...8 Tabellenverzeichnis Einleitung Motivation Problemstellung und -abgrenzung Ziel der Arbeit Vorgehen Einordnung E-Business und C-Business Informationssystemarchitektur Der Integrationsgedanke Analyse der bisherigen Integrationslösungen Proprietäre Schnittstellen Klassische Middleware RPC und MOM Verteilte Objekttechnologien (CORBA, EJB und COM) Middleware für den Datenbankzugriff Fazit Integrationsanforderungen an künftige Softwaresysteme Data Integration People Integration Process Integration Application Integration Zusammenfassung Moderne Lösungsansätze XML WebServices Frameworks J2EE NET Build-to-integrate-Lösungen BizTalk-Server WebSphere Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 4

5 6 Zusammenfassung und Ausblick Erreichte Ergebnisse Ausblick Quellenverzeichnis...36 Stichwortverzeichnis...38 EINLEITUNG Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 5

6 EINLEITUNG Abkürzungsverzeichnis API B2B B2C B2A bzw. C-Business CLR COM CORBA CRM DB DCOM d.h. DV EAI E-Business EDI EDV EJB ERP HTML HTTP IS IT J2EE JDBC Application Programming Interface Business-to-Business Business-to-Consumer Business-to-Administration beziehungsweise Collaborative Business Common Language Runtime Component Object Model Common Object Request Broker Architecture Customer Relationship Management Datenbank Distributed Object Component Model das heißt Datenverarbeitung Enterprise Application Integration Electronic Business Electronic Data Interchange Elektronische Datenverarbeitung Enterprise JavaBeans Enterprise Resource Planning Hyper Text Markup Language Hyper Text Transfer Protocol Informationssystem Informationstechnologie Java 2 Enterprise Edition Java Database Connectivity Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 6

7 EINLEITUNG JSP ODBC OLE RMI RPC SCM SOAP SQL TCP/IP UDDI WSDL WWW XML z.b. Java Server Pages Open Database Connectivity Object Linking and Embedding Remote Method Invocation Remote Procedure Call Supply Chain Management Simple Object Access Protocol Structured Query Language Transmission Control Protocol / Internet Protocol Universal Description, Discovery and Integration Web Services Definition Language World Wide Web Extensible Markup Language zum Beispiel Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 7

8 EINLEITUNG Abbildungsverzeichnis Abbildung 1: Hauptfaktoren für die C-Business-Entwicklung Abbildung 2: Arten von Informationssystemen Abbildung 3: Der Integrationsgedanke Abbildung 4: Request-/Reply-Kommunikation Abbildung 5: Asynchrone Kommunikation Abbildung 6: Lose Koppelung Abbildung 7: Zusammenfassung der Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business Abbildung 8: Die Ebenen eines WebService Abbildung 9: Aufbau des.net Frameworks Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 8

9 EINLEITUNG Tabellenverzeichnis Tabelle 1: Vergleich der verteilten Objekttechnologien Tabelle 2: Vergleich von EAI-Systemen und WebServices Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 9

10 EINLEITUNG 1 Einleitung Das Kapitel Einleitung dient der Einstimmung in das Thema Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business. Nach einer kurzen Motivation werden in der Problemstellung die Begriffe C-Business und Integration definiert. Daraufhin wird auf bestehende Integrationsprobleme in Unternehmen eingegangen und die Thematik klar abgegrenzt. Des weiteren wird das Ziel dieser Studienarbeit erklärt. Im Anschluss wird das Vorgehen beschrieben. 1.1 Motivation Wachsende Kundenanforderungen, intensiver Wettbewerb und zunehmende technische und organisatorische Komplexität erfordern ein effektives und effizientes Zusammenspiel auf allen organisatorischen und technischen Ebenen. Integration gilt dabei als zentraler Ansatz, um diesen Anforderungen gerecht zu werden. 1 Die Integration unterschiedlicher Anwendungen ist so alt wie die Datenverarbeitung selbst. Welches Unternehmen kann heute seine Finanzbuchhaltungssoftware ohne die Verknüpfung mit Warenwirtschaft und Logistikanwendungen Gewinn bringend einsetzen? Verschiedenste Softwaresysteme im Verbund sind heute genauso Status quo wie der Einsatz heterogener Hardund Betriebssystemplattformen. 2 Mehr als 35 Prozent ihrer IT-Budgets geben Unternehmen für die Integration von Anwendungen aus. Rund 70 Prozent des insgesamt programmierten Codes werden für den Informationsaustausch zwischen DV-Systemen erstellt. 3 Enterprise Application Integration (EAI) ist mehr als ein Marketing-Hype. Festzustellen ist, dass die Entwicklungen im Bereich Integrationssoftware nicht stehen geblieben sind. Bedingt durch den vermehrten Einsatz von Standardsoftwarelösungen im Bereich Enterprise Resource Planning (ERP), Customer-Relationship- (CRM) und Supply-Chain-Management (SCM), erhält die Integration von Lösungen eine neue Qualität. Mussten bis dato unterschiedlichste Individualanwendungen, die in der Regel nicht über definierte Interfaces verfügten, mittels aufwändiger Schnittstellen-Programmierung zusammengebunden werden, so ist bei modernen Standardprodukten eine Vielzahl von Andockpunkten vorgesehen. Der EAI-Markt birgt laut Analysten von Gartner Group und IDC ein Potenzial von weltweit rund 82 Milliarden Dollar. 1 [MeCR02], S [CoWo00], S. 1 3 [CoWo00], S. 1 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 10

11 EINLEITUNG Neben der starken Verbreitung von Standardsoftware forcierte die Anbindung von Altanwendungen an das Web sowie die zunehmende Zahl von Firmenzusammenschlüssen den EAI-Gedanken, so die Marktforscher weiter. 4 Mit dem Internetboom in den 90-er Jahren lässt sich der Integrationsgedanke noch besser umsetzen. Mit der inzwischen ubiquitären Internettechnologie bieten sich erstmals Standards an, die es ermöglichen, technologische Insellösungen umfassend miteinander zu kombinieren. 5 Portale spielen hierbei eine wichtige Rolle. Nach einer Umfrage von Piper Jaffray zufolge werden zukünftig 87 Prozent aller Applikationen über Portale integriert Problemstellung und -abgrenzung Im Rahmen der Problemstellung und abgrenzung gilt es zunächst einmal die Begriffe Collaborative Business (C-Business) und Integration zu definieren. Michal Wettklo und Marc-Andreas Schultze erklären C-Business in der Detecon-Studie ERP- Strategien im collaborative Business ERP in der Sackgasse? mit dem folgenden Satz: Die Weiterentwicklung der Internettechnologien und deren zunehmende Standardisierung führen zu einer effektiveren und effizienteren Gestaltung aller von der unternehmensübergreifenden Wertschöpfung betroffenen unternehmensinternen wie externen Prozesse und bildet darüber hinaus die Grundlage für neue Geschäftsmodelle, die mit dem Namen C-Business bezeichnet werden. 7 Gemeint ist die überbetriebliche Zusammenarbeit zwischen verschiedenen Unternehmen in einer Wertschöpfungskette. Ferner steht noch der Begriff der Integration im Raum. Claus Rautenstrauch definiert Integration aus der Sicht der Wirtschaftsinformatik als die Herstellung oder Wiederherstellung eines Ganzen durch Vereinigung oder Verbindung logisch zusammengehörender Teile. 8 Die Verknüpfung von Elementen zu einem homogenen System ist also das Ziel, wenn man von Integration spricht. Viele Unternehmen stehen heute vor dem Problem, dass sie eine Fülle von Anwendungen benötigen, um die immer komplexeren Geschäftsprozesse zu bewältigen. Beispielsweise wird ein ERP-System (Enterprise Resource Planning) für die tägliche Materialdisposition, für die Produktion und den für Versand eingesetzt. Für die Kommunikation und den Informationsaustausch dient ein Groupware-System und darüber hinaus verwaltet eventuell eine CRM-Software (Customer-Relationship-Management) alle Aktivitäten mit den Kunden. Hinzu kommen möglicherweise noch Alt-Systeme (Legacy-Systeme), auf die man noch nicht verzichten möchte. Diese verschiedenen Softwaresysteme sind meist von unterschiedlichen Herstellern und hinterlassen teilweise proprietäre Datenstrukturen. Die Informationssystemarchitektur wird unübersichtlich und uneinheitlich. Der Integrationsgedanke ist zwar in vielen Unternehmen schon sehr fortgeschritten, dennoch führt der Einsatz komplexer Middleware nur bedingt zur inner- und überbetrieblichen Integration. Die Schnittstellenprogrammierung der letzten Jahre haben den Verruf des 4 [CoWo00], S. 1 5 [SiCB03], S. 9 6 [PuCP03], S. 7 7 [ScWe03], S [RaIE93], S. 24 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 11

12 EINLEITUNG Spaghetti-Charakters und führen ungewollt zu einer noch größeren Inflexibilität der verzahnten Systeme. Außerdem scheitern viele Unternehmen an der Abdeckung von unternehmensübergreifenden Prozessen, weil sich der Fokus historisch gewachsen - immer noch auf die innerbetriebliche Integration ausrichtet. Das Umsetzen der C-Business-Strategie bis ins letzte Detail ist demnach zum heutigen Zeitpunkt noch nicht vollzogen. Eine weitere Strömung, die die Integration von Software zu einer häufig geübten Sportart macht, die jeder EDV-Profi beherrschen muss, sind die Unternehmenszusammenschlüsse und Fusionen. Dabei gilt es, ein EDV-System der Fusionspartner zu behalten und die Bestände des anderen Partners in das beibehaltene System zu migrieren. 9 Integration lässt sich durch die Internettechnologien und den zahlreichen Standards noch besser umsetzen. Dabei geht es aber vielmehr um Strategien, die die Kommunikation zwischen Einzelsystemen regeln. Das Gesamtsystem soll flexibel und offen auf Änderungen der Geschäftsprozesse oder die Entwicklung neuartiger Technologien reagieren können. In dieser Arbeit werden Sie keine Details zur Architektur und Funktionsweise moderner Lösungsansätze erfahren. Sie werden nur oberflächlich abgehandelt, da es sonst den Rahmen dieser Studienarbeit sprengen würde. Praxisbeispiele werden nicht genannt. Ebenso werden die verschiedenen Sichtweisen großer IT-Unternehmen, wie beispielsweise Microsoft, IBM oder SAP, außer Acht gelassen. 1.3 Ziel der Arbeit In dieser Studienarbeit werden zunächst bisherige Integrationsansätze beleuchtet und auf ihre Schwachstellen hin überprüft. Daraus resultierend sollen grundlegende Aussagen über die Integrationsanforderungen an künftige Softwaresysteme in Zeiten des C-Business getroffen werden. Das Hauptaugenmerk liegt eindeutig auf der Erarbeitung der Integrationsanforderungen. Im Anschluss daran soll noch kurz auf moderne Lösungsansätze eingegangen werden. 1.4 Vorgehen Das Kapitel Einordnung dient dazu, wichtige Begriffe im Umfeld der Thematik zu klären und einzuordnen. Dabei wird auf die Begriffe E-Business, C-Business, Informationssystemarchitektur und auf den Integrationsgedanken eingegangen. Das nächste Kapitel Analyse der bisherigen Integrationslösungen befasst sich mit den gegenwärtigen Integrationsformen in der Welt der Informationstechnologie. Hierzu zählen die herstellerabhängigen Schnittstellen sowie die klassische Middleware. Dabei werden verschiedene Basistechnologien vorgestellt. Auf die Middleware-Arten Remote Procedure Call, Message oriented Middleware, verteilte Objekttechnologien und Middleware für den Datenbankzugriff wird dabei näher eingegangen. Ein anschließendes Fazit analysiert die Schwachstellen der bisherigen Integrationslösungen. Resultierend aus diesen Schwachstellen werden im Kapitel Integrationsanforderungen an künftige Softwaresysteme die Integrationsanforderungen in Zeiten des C-Business detailliert dargestellt. Data-, People-, Process- und Application Integration sind dabei die wichtigen Schlagworte. Das Kapitel fünf Moderne Lösungsansätze beschäftigt sich ganz grob mit den verschiedenen Integrationsansätzen auf dem Markt, die den Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business nachkommen möchten. Technologien wie XML und WebServices 9 Vgl. [KEAI02], S. 13 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 12

13 EINLEITUNG erscheinen dabei sehr vielversprechend zu sein. Zudem werden die Integrationslösungen von Microsoft und IBM vorgestellt. Das letzte Kapitel rundet diese Studienarbeit mit den erreichten Ergebnissen und einem Ausblick ab. Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 13

14 2 Einordnung Das Kapitel Einordnung dient dazu, wichtige Begriffe im Umfeld der Thematik zu klären und einzuordnen. Zuerst werden die Begriffe E-Business und C-Business näher erläutert. Danach wird kurz auf die Informationssystemarchitektur eingegangen bevor der Integrationsgedanke erklärt wird. 2.1 E-Business und C-Business Unternehmen und Institutionen sind heute gezwungen, sich mit den neuen Formen elektronischer Geschäftsprozesse auseinandersetzen. Das Electronic Business (E-Business) meint hier vor allem die Abwicklung von Geschäftsprozessen über das Internet. Es stellt sich die Frage, wie das Internet in einem Unternehmen sinnvoll eingesetzt werden kann. Folgende Anwendungsgebiete kristallisieren immer mehr zu Erfolgsfaktoren: Neugestaltung von Geschäftsprozessen Das Ziel ist, mit Hilfe von Internettechnologien, die bestehenden Geschäftsprozess neu zu gestalten, indem man sie vereinfacht und wenn möglich automatisiert. (Reengineering von Prozessen) B2B-Integration Hier werden die Wertschöpfungsketten von Unternehmen durch die Kommunikationstechnik verbunden. (B2B-Prozessautomatisierung) Verlagerung von Service auf billigere Kanäle Services über das Internet ergänzen die Callcenter, denn Selbstbedienung über das Internet ist noch mal preiswerter als Service über das Callcenter. 10 Im Idealfall von E-Business findet kein physikalischer Kontakt mehr zwischen den Partner statt. Heute werden die Partnerbeziehungen in den meisten Fällen wie folgt klassifiziert: 1. Business-to-Consumer (B2C) 2. Business-to-Business (B2B) 3. Business-to-Administration (B2A) 10 Vgl. [KEAI02], S. 11 und 12 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 14

15 EINORDNUNG C-Business ist eine Unterkategorie des E-Business und konzentriert sich auf das Zusammenarbeiten von Partnern respektive von Unternehmen. Unterstützt wird die Kooperation entlang der Wertschöpfungskette durch die Internettechnologien. Das C-Business ist eine Geschäftsstrategie, die verschiedenste Partnerunternehmen entlang einer Wertschöpfungskette dazu animiert, unter der Prämisse gemeinsamer Zielsetzungen durch gezielten Informationsaustausch gegenseitigen Mehrwert zu generieren. 11 Im folgenden Schaubild werden die Hauptfaktoren für die C-Business-Entwicklung dargestellt: Abbildung 1: Hauptfaktoren für die C-Business-Entwicklung 12 Eine bekannte Form des Collaborative Business in der Automobilbranche ist EDI (Electronic Data Interchange). Hier wird der Datenaustausch innerhalb eines festgelegten semantischen und syntaktischen Rahmens ermöglicht. Da der Nachrichteninhalt (Semantik) von EDI jedoch vor der Erstkommunikation besprochen werden muss, beschränkte sich der Einsatz hauptsächlich auf bekannte Partner, die regelmäßig Informationen austauschen. Michal Wettklo und Marc-Andreas Schultze gehen in ihrer Studie ERP-Strategien im collaborative Business ERP in der Sackgasse? weiter und fordern Unternehmen in Zeiten des C-Business auf, sich innerhalb kürzester Zeit mit den eigenen Prozessen und Systemen an die Partnerunternehmen anpassen zu können [SiCB03], S [SiCB03], S Vgl. [ScWe03], S. 10 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 15

16 EINORDNUNG Doch warum sollten sich Unternehmen dem E-Business-Trend überhaupt annehmen? Analysten, Beratungsfirmen und natürlich die Unternehmen selbst versprechen sich durch das e folgende Vorteile: Beschleunigung und Vereinfachung von Geschäftsprozessen Produktivitätsverbesserung durch rasche Kommunikationsmöglichkeiten Verbesserter Informationsaustausch Flexibilität Erhebliche Einsparungspotenziale bei unternehmens- bzw. organisationsübergreifenden Integration von Geschäftsprozessen Eliminierung aller Medienbrüche Informationssystemarchitektur Die Informationssystemarchitektur in den 80-er Jahren orientierte sich stark an den innerbetrieblichen Prozessen. IS-Architekturen dienen in Unternehmen seit längerem als Instrument zur Strukturierung von Informationssystemen. Die überbetriebliche Vernetzung von Unternehmen mittels IS stellt jedoch neue Anforderungen an die zugrundeliegenden IS- Architekturen durch die Verfügbarkeit von neuen Technologien wie z.b. Portale und WebServices. 15 Obwohl man heutzutage vornehmlich verteilte Systeme in den IT-Landschaften der Unternehmen vorfindet, bestehen trotzdem einige Defizite in deren Architekturlandschaft: Heterogenität der Systemlandschaft In großen multinationalen Unternehmen sind IS-Architekturen zumeist historisch gewachsen. Häufig sind die Verantwortlichkeiten dezentral in Geschäftseinheiten delegiert und führten daher zu einer Koexistenz unterschiedlicher, heterogener Systemlandschaften. Integration Integration bildet die Voraussetzung für die Realisierung kundenorientierter Geschäftsprozesse. Redundanz Die Erweiterung der ERP-Systeme um Collaboration Applikationen, wie z.b. CRM- und SCM-Systeme, von verschiedenen Softwareanbietern, hat in vielen Fällen zu einer Überschneidung an Applikationsfunktionalität und redundanten Daten geführt Vgl. [ÖBüeN], S. 4 und 5 15 [PuCP03], S Vgl. [PuCP03], S. 20 und 21 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 16

17 EINORDNUNG Abbildung 2: Arten von Informationssystemen 2.3 Der Integrationsgedanke Dezentrale Organisationsstrukturen und verteilte Systeme sind in vielen Unternehmen bereits implementiert oder angestrebt und gerade deshalb ist der Integrationsgedanke so wichtig. Integration eröffnet unternehmensintern und übergreifend Erfolgspotenziale. Man darf Integration nicht als reine IT-Lösung verstehen, Integration ist primär keine technische Frage, sondern erfordert Anstrengungen auf allen Ebenen betrieblicher Organisation. 17 Integration ist mehr als nur der Austausch von Daten zwischen verschiedenen Programmen: Integration bedarf mächtiger Konzepte, die sich sowohl aus einer betriebswirtschaftlichen als auch einer softwaretechnischen Betrachtungsweise von Problemen ergeben. 18 Der Strategieansatz des C-Business sieht in vielen Bereichen eine Integration vor, denn durch die Internettechnologien und den zahlreichen Standards können Systeme einfach miteinander kommunizieren. Die heutigen IT-Landschaften sollen flexibel und offen sein, damit sie auf Änderungen der Geschäftsprozesse umgehend reagieren können. Integration lässt sich in vier Ebenen gliedern: 1. Die Integration unter einer Benutzeroberfläche (People Integration) 2. Die Integration auf Datenebene (Data Integration) 3. Die Integration auf Funktionsebene (Process Integration) 4. Integration auf Applikationsebene (Application Integration) 17 [KEAI02], S [RaIE93], S. 23 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 17

18 EINORDNUNG Abbildung 3: Der Integrationsgedanke Alle vier Ebenen sind später noch von besonderer Wichtigkeit, wenn es darum geht, die Integrationsanforderungen an künftige Softwaresysteme in Zeiten des C-Business zu stellen. Die verschiedenen Ebenen werden in Kapitel vier noch ausführlicher behandelt und dementsprechend erläutert. Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 18

19 3 Analyse der bisherigen Integrationslösungen Das Kapitel Analyse der bisherigen Integrationslösungen befasst sich mit den gegenwärtigen Integrationsformen in der Welt der Informationstechnologie. Hierzu zählen die herstellerabhängigen Schnittstellen sowie die klassische Middleware. Im Zuge der Begriffserläuterung der Middleware werden verschiedene Basistechnologien vorgestellt. Auf die Middleware-Arten Remote Procedure Call, Message oriented Middleware, verteilte Objekttechnologien und Middleware für den Datenbankzugriff wird dabei näher eingegangen. Ein anschließendes Fazit rundet das Kapitel ab und informiert über die Schwachstellen der bisherigen Integrationslösungen. 3.1 Proprietäre Schnittstellen Aus Zeiten älterer Softwaregenerationen entstanden API s, die meist herstellerspezifisch sind. Bei Erweiterungen innerhalb der Einzelsysteme um Zusatzfunktionalitäten oder die Anbindung eines ergänzenden Systems müssen die Schnittstellen angepasst oder neue Schnittstellen entwickelt werden. Hinzu kommt, dass die proprietären Schnittstellen oftmals in verschiedenen Programmiersprachen erstellt wurden und nicht offen zugänglich sind. Trotz der wohlwilligen Absicht mangelt es an Andockpunkten. Die Folge daraus sind immens hohe Entwicklungs- und Wartungskosten und eine nicht zu unterschätzende Abhängigkeit vom jeweiligen Hersteller. Im schlechtesten Fall gibt es im Unternehmen nur noch wenige oder genau einen Programmierer, der die Sprache der veralteten Systeme und Schnittstelle beherrscht Klassische Middleware Der Begriff Middleware ist generell schwach definiert. Wolfgang Keller definiert Middleware in seinem Buch über Enterprise Application Integration wie folgt: Middleware ist Software, die ansonsten getrennte Anwendungen miteinander verbindet. Der Begriff Middleware wird benutzt, um Produkte zu beschreiben, die als Klebstoff zwischen zwei Anwendungen dienen. Middleware unterscheidet sich damit von Export- und Importfunktionen, die in einer einzigen Anwendung eingebaut sein können. 20 Klassische Middleware-Produkte verfolgen den Ansatz, die Integration unterschiedlicher heterogener Systeme möglichst standardisiert zu ermöglichen. Dabei werden Middleware- Lösungen zwischen zwei oder mehrere Applikationen geschaltet und ermöglichen dadurch die plattformunabhängige Kommunikation und den Datenaustausch zwischen Systemen und Anwendungen unterschiedlichster Hersteller. Die klassische Middleware bildet also die Basis der 19 Vgl. [DuBI04], S [KEAI02], S. 85 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 19

20 ANALYSE DER BISHERIGEN INTEGRATIONSLÖSUNGEN gegenwärtigen EAI-Lösungsansätze (Enterprise Application Integration). Folgende Middleware- Typen lassen sich klassifizieren: Remote Procedure Call (RPC) Message oriented Middleware (MOM) Middleware für den Datenbankzugriff Verteilte Objekttechnologien Transaktionsmonitore 21 Arbeit verzichtet) (auf die Erklärung von Transaktionsmonitoren wird in dieser RPC und MOM Unter Remote Procedure Call (RPC) versteht man ein Protokoll, das die Implementierung verteilter Anwendungen vereinfachen soll. Die Grundidee ist, dass ein Programm eine Funktion eines Programms, das auf einem anderen PC läuft, nutzen kann, ohne sich um die zu Grunde liegenden Netzwerkdetails kümmern zu müssen. Ein RPC-Aufruf stellt in den meisten Fällen eine synchrone Kommunikation dar. Dabei besteht ein RPC aus einer Anfrage und einem zurückgelieferten Ergebnis (Request-Reply-Modell). Von der Funktionsweise her sendet ein lokales Programm eine Anforderung an ein entferntes Programm und unterbricht seine Arbeit bis zum Eintreffen der Antwort. In Verbindung mit so genannten Threads ist jedoch auch eine asynchrone Realisierung eines entfernten Funktionsaufrufs möglich. Abbildung 4: Request-/Reply-Kommunikation 21 Vgl. [MeCR02], S. 219 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 20

21 ANALYSE DER BISHERIGEN INTEGRATIONSLÖSUNGEN Aufgrund des simplen Funktionsmechanismus liegt der Vorteil von RPCs eindeutig in der Einfachheit. Nachteilig wirken sich die mangelnde Skalierbarkeit und die negativen Auswirkungen auf die Performance betroffener Applikationen aus. 22 Message oriented Middleware (MOM) benutzt als Modell die Weitergabe von Nachrichten. Typische Dienste von MOM-Produkten erlauben das Anlegen, Weitergeben und Speichern von Nachrichten. Im Gegensatz zu den RPCs beruht MOM auf dem asynchronen Kommunikationsprinzip und eignet sich daher hervorragend für lose gekoppelte Systeme. Messaging und Queuing stellen in MOM die beiden Kernmechanismen beim asynchronen Austausch von Nachrichten dar. Die Nachrichtenvermittlung über MOM ist dadurch unempfindlich gegenüber Staus im Netz. Zusätzlich verfügt MOM über einen Wiederherstellungsmechanismus. 23 Abbildung 5: Asynchrone Kommunikation Verteilte Objekttechnologien (CORBA, EJB und COM) Der Kerngedanke des objektorientierten Ansatzes besteht in der Kapselung von Daten und Operationen zu einer Einheit, die nach außen sichtbares Verhalten hat, ihren internen Aufbau im Sinne des Information Hiding aber verbirgt. 24 Nachfolgend werden mit CORBA (Common Object Request Broker Architecture), COM (Component Object Model) und Enterprise JavaBean (EJB) die wichtigsten Standards für die Entwicklung heterogener verteilter Anwendungen vorgestellt. CORBA hat das Ziel, die Interoperabilität, die Wiederverwendbarkeit und die Portierbarkeit von Software zu maximieren. Mit der CORBA-Referenzarchitektur wurde ein 22 Vgl. [MeCR02], S Vgl. [MeCR02], S. 220 und [KEAI02], S [MeCR02], S. 222 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 21

22 ANALYSE DER BISHERIGEN INTEGRATIONSLÖSUNGEN Interaktionsmechanismus zwischen verteilten Systemen definiert, welche sowohl für die Entwicklung neuer Komponenten als auch für die nachträgliche Integration getrennt voneinander entwickelter Applikationskomponenten entwickelt worden ist. Microsoft s COM-Modell ermöglicht das Schreiben von wiederverwendbaren Komponenten und verteilten Anwendungen. OLE (Object Linking and Embedding) bildet dabei die komplette Infrastruktur für die objektorientierte Kommunikation. CORBA gilt generell als plattformunabhängig, COM zielt hingegen ausschließlich auf die Microsoft-Welt ab. OLE basiert architektonisch auf COM. DCOM (Distributed COM) stellt eine Erweiterung von COM dar, die es COM-Clients ermöglicht, Objekte zu bearbeiten, die sich auf verschiedenen Rechnern befinden. COM+ wiederum ist die Weiterentwicklung von DCOM und reduziert den gewaltigen Programmier-Overhead bei der Entwicklung von DCOM-Komponenten. Enterprise JavaBean (EJB) stellt ebenso ein Komponentenstandard dar. Die EJB-Spezifikation ermöglicht es, Anwendungslogik als Komponenten zu entwickeln. Dabei können EJB auf allen wichtigen Plattformen implementiert werden und bieten wesentlich offenere und flexiblere Einsatzmöglichkeiten als beispielsweise COM/COM+. Mit Hilfe von EJB können Serverfunktionalitäten über einen clientseitigen Aufruf ausgeführt werden. EJB stellt die Anwendungslogik in wiederverwendbaren Komponenten, so genannten Beans, dar, wobei die Geschäftslogik in Session Beans und Daten in Entity Beans gehalten werden. 25 In der nachfolgenden Tabelle werden die verschiedenen verteilten Objekttechnologien miteinander verglichen: Tabelle 1: Vergleich der verteilten Objekttechnologien Vgl. [MeCR02], S [DuBI04], S. 16 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 22

23 ANALYSE DER BISHERIGEN INTEGRATIONSLÖSUNGEN Middleware für den Datenbankzugriff Ein großes Problem beim Einsatz von herstellerspezifischen Datenbanken stellt deren Abfrage dar. Um die Abfrage und Verwaltung verschiedener Datenbanken zu vereinheitlichen, wurden mit ODBC (Open Database Connectivity) und JDBC (Java Database Connectivity) Middleware- Lösungen für den Zugriff auf Datenbanken unterschiedlicher Hersteller entwickelt. Mittels der Middleware und SQL können aus einer höheren Programmiersprache heraus, Datenbanken verwaltet und abgefragt werden. Beide Technologien sind plattformunabhängig Fazit Die unternehmensinterne und übergreifende Abwicklung von Geschäftsprozessen in Zeiten des C-Business zwingt die Unternehmen dazu die inner- als auch die überbetriebliche Integration zu forcieren. Sämtliche Aufgaben und Prozesse werden dabei zunehmend durch IT-Systeme unterstützt, so dass neben der organisatorischen Zusammenführung auch die technische Zusammenführung der beteiligten IT-Systeme erforderlich ist. Weitere Integrationsanforderungen ergeben sich durch die rasante Entwicklung des Internet. Hinzu kommt die Erhaltung der Flexibiliät, um weitere Systeme schnell und problemlos einbinden zu können. Im gleichen Maße, wie sich die Systeme jedoch anderen Systemen und neuen Anforderungen öffnen sollen, wuchs der Bedarf an Sicherheitsvorkehrungen. Den genannten Herausforderungen versucht man mit den heutigen EAI-Ansätzen zu begegnen. Die wesentlichen Vorteile des Einsatzes von EAI-Software sind: Reduktion der Anzahl der sichtbaren Schnittstellen Verbindung von Produktivsystemen über standardisierte Schnittstellen Kommunikation über standardisierte Datentypen (generische Business-Objekte) Kapselung der Anbindung von Systemen Reduzierter Aufwand für die Pflege und Wartung der Systemlandschaft 28 Auf dem Weg zum E-Business, d.h. einer ganzeinheitlichen Ausrichtung der Geschäftsprozesse auf die elektronischen Vertriebswege, ist EAI ein entscheidender Baustein. EAI ist dabei ein werkzeuggestützter Ansatz, welcher die Problematiken der einzelnen Ebenen Transport, Konvertierung und Geschäftsprozesse in einem Werkzeug bzw. einer Suite von Werkzeugen kapselt. 29 Dabei darf jedoch nicht vergessen werden, dass diese vorwiegend technischer Natur sind, d.h. inhaltliche bzw. semantische Aspekte werden derzeit nur wenig oder gar nicht berücksichtigt. Aber auch in Bezug auf die technischen Integrationsmöglichkeiten lassen die gegenwärtig verfügbaren EAI-Tools viele Wünsche offen. 30 Dem Anspruch einer Systemintegration per Plug and Play auf dem Niveau von Geschäftsprozessen oder Applikationen werden sie nicht gerecht. Aufgrund dieser Schwachstellen gilt es nun speziell auf die Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business einzugehen. Das nächste Kapitel befasst sich genau mit dieser Problematik. 27 Vgl. [MeCR02], S [DuBI04], S [MeCR02], S Vgl. [MeCR02], S. 227 und 228 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 23

24 4 Integrationsanforderungen an künftige Softwaresysteme Das Kapitel Integrationsanforderungen an künftige Softwaresysteme bildet den Kern dieser Studienarbeit. Die klassische Middleware kann den Anforderungen moderner Informationssysteme nur bedingt nachkommen. Deshalb werden in diesem Kapitel die Integrationsanforderungen in Zeiten des C-Business detailliert dargestellt. Data-, People-, Process- und Application Integration sind dabei die Schlagworte. Am Ende spiegelt eine Zusammenfassung die erreichten Ergebnisse wider. 4.1 Data Integration Gerade im Bereich der Daten besteht ein hoher Integrationsbedarf. Betrachtet man heute das Softwareangebot oder die installierte Basis an Standard- oder eigenentwickelter Software für betriebliche Anwendungen, so sind dies in der Regel monolitische Systeme, deren Funktionsumfang und Zuordnung sich an der Aufbauorganisation von Unternehmen orientieren. Sieht man jedoch die Vorgangsketten der gesamten Wertschöpfungskette, so stellt man fest, dass diese häufig abteilungs- und unternehmensübergreifend sind, was bedeutet, dass Daten verschiedenster Systeme für die Bearbeitung eines Prozesses notwendig sind. Die heterogene System-Landschaft weist dadurch etliche Redundanzen auf. Redundante Datenhaltung bedeutet redundanten Pflegeaufwand und die Sicherstellung, dass die gehaltenen Daten stets auf gleichem Aktualitätsgrad sind. In der Praxis ist dies äußerst schwierig zu bewerkstelligen. 31 Eine wesentliche Rolle spielt hierbei die Qualität der zugrunde liegenden Daten. Dieser Anforderung kann am besten nachgekommen werden, wenn die Daten sofort am Ort ihrer Entstehung über mobile Geräte direkt im Back-End-System zentral erfasst werden können. 32 Der Fokus der Datenintegration liegt auf der Zusammenführung der DV-Landschaft im eigenen Unternehmen. In erster Linie kann man sagen, dass die Datenintegration ein Prozess ist, in dem man Informationen aus einer Datenbank ausliest, dann möglicherweise verarbeitet und anschließend in eine andere Datenbank, die evt. auch in einem anderen Unternehmen vorzufinden ist, wegschreibt (Kommunikation zwischen Datenbanken mit Datentransformation). Dieser Ansatz klingt auf den ersten Blick recht einfach, wenn man jedoch die Datenbankarchitektur eines Unternehmens mit über 100 Datenbanken und über 1000 Tabellen betrachtet, wird das Unterfangen der Datenintegration äußerst komplex. Zumal man die Transformation von Daten und die dahinter steckende Geschäftslogik nicht vergessen darf. 31 Vgl. [RaIE93], S. 43 und [ScWe03], S. 42 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 24

25 INTEGRATIONSANFORDERUNGEN AN KÜNFTIGE SOFTWARESYSTEME Ein weiteres Problem ergibt sich dadurch, dass sämtliche nehmende Applikationen angepasst werden müssen, sobald bei der gebenden Applikation Änderungen in der Datenstruktur und semantik vorgenommen werden. Diese Problematik steht eng im Zusammenhang mit dem Problem der semantischen Integrität. 33 Die Datenintegration bildet also die Voraussetzung für eine Realisierung der Funktionsintegration (Process Integration). Bei der Ausgestaltung der Datenintegration ist unter Abwägung von Komplexität, Kosten und Nutzen über die technische Realisierung zu entscheiden. Beispielsweise kann die Aktualisierung bzw. der Abgleich nachts im Batch-Modus oder im Realtime-Modus stattfinden. 34 Die Zeiten des C-Business erfordern einen schnellen Zugriff auf Daten und Informationen. Dabei beschränkt sich der Zugriff nicht nur auf die Anwendungen innerhalb eines Unternehmens, sonder auch auf die Daten und Informationen von Kooperationspartnern. Der Austausch von Daten umfasst ebenso die Konvertierung der Datenformate in ein lesbares Format (Mapping) für die eigenen Anwendungen. Zusammenfassend lässt sich also sagen, dass um die im C-Business erforderlichen kurzen Reaktionszeiten in Bezug auf die Verarbeitung von Daten gewährleisten zu können, ist eine unternehmensweite Anwendungsintegration erforderlich. EAI-Lösungen können diese Aufgabe übernehmen, scheitern aber an der unternehmensübergreifenden Anwendungs- und Datenintegration. Hier werden für eine C-Business-Architektur neue technologische Ansätze erforderlich People Integration Moderne E-Business-fähige Software muss Menschen mit unterschiedlichen Rollen (z.b. Außendienstmitarbeiter, Kunden, Lieferanten, interne Mitarbeiter,...) einen personalisierten Zugang über ein Portal zum Informationssystem bieten. Der Zugang der einzelnen Rolleninhaber ist also auf dessen Bedarf an Informationen ausgerichtet. Die vordergründig einfachste aller Arten, Anwendungen über eine Benutzeroberfläche zu integrieren, ist die Web-Integration in Form eines Webportals. Anhand eines Browsers, der heutzutage zur Informationsbeschaffung über das Internet allgegenwärtig ist, lässt sich das Webportal einfach aufrufen. Dem User erscheinen unter einer einheitlichen Benutzeroberfläche verschiedene Applikationen. Er erhält dadurch den Eindruck, als arbeite er mit einer einzigen Applikation. Collaboration Portale sind als web-basierte, personalisierbare und integrierte Zugangssysteme zu internen und externen Applikationen definiert, die der Unterstützung von Kundenprozessen dienen und die grafische Frondend-Integration über verschiedenen Portale hinweg umsetzen. 4.3 Process Integration Das Ziel der Prozessintegration ist die Schaffung eines virtuellen Unternehmens. Es wird also nicht nur das eigene Unternehmen betrachtet, sondern die ganze Wertschöpfungskette. Dazu zählen Zulieferer als auch Kunden. Die Komplexität der Prozessintegration hängt von der Komplexität der Geschäftsprozesse ab. Zunächst einmal gilt es, alle Geschäftsprozesse genau zu 33 Vgl. [MeCR02], S [MeCR02], S [ScWe03], S. 41 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 25

26 INTEGRATIONSANFORDERUNGEN AN KÜNFTIGE SOFTWARESYSTEME beschreiben und zu dokumentieren. Sind diese spezifiziert, kann man zum nächsten Schritt übergehen und die Systeme analysieren, die nötig sind, um den Geschäftsprozess zu automatisieren. Dabei werden nun verschiedene Applikationen und einzelne Funktionen in der Wertschöpfungskette integriert. Das Zusammenspiel von Anwendungen ist die Grundidee, die hinter dem Aspekt der Prozessintegration steckt (gemeinsame Nutzung von Business-Logik). Um die Anforderungen nach einfacher Integration von SCM-Funktionalitäten zwischen möglicherweise nur temporär miteinander verknüpften Kooperationspartnern umsetzen zu können, erscheinen lose gekoppelte, technisch weniger komplexe Lösungen auf Basis von Internet-Standardtechnologien erfolgsversprechender. 36 Abbildung 6: Lose Koppelung 37 Künftige IT-Lösungen müssen in der Lage sein, den Anwendern die erforderlichen Freiräume in der Gestaltung ihrer Geschäftsprozesse zu bieten. Die zu Grunde liegenden Technologien müssen an Veränderungen der Geschäftsprozesse angepasst werden können, ohne dass dafür eine Reimplementierung der Software notwendig wird Application Integration Mit der Application Integration verbindet man die Skalierbarkeit von IT-Systemen. Gemeint ist die Integration von Standardanwendungen mit branchenspezifischen Lösungen. Beispielsweise sollten ein ERP-System und ein CRM-System von verschiedenen Herstellern ohne Probleme miteinander kommunizieren können. Informationssysteme müssen dabei offen und flexibel gestaltet sein. 36 [ScWe03], S [ScWe03], S [ScWe03], S. 38 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 26

27 INTEGRATIONSANFORDERUNGEN AN KÜNFTIGE SOFTWARESYSTEME Eine auf C-Business ausgerichtete Anwendungsarchitektur muss eine einfache Integration von Standard-Front-End-Anwendungen aufgrund ihrer offenen Architektur mit minimalem Anpassungsaufwand ermöglichen auch, wenn die beteiligten Anwendungen nicht vom gleichen Hersteller sind. 39 Die Applikationsintegration umfasst alle Bereiche der Daten-, der People- und der Prozessintegration und erfordert in Zeiten des C-Business den permanenten Zugriff auf gemeinsam genutzte Daten und Informationen sowie die nahtlose Weiterverarbeitung dieser Daten und Informationen in den verschiedenen Anwendungen des Unternehmens. Dies setzt zum einen die Standardisierung der Datenformate voraus und macht zum anderen eine gemeinsame, offene Plattform zum Austausch dieser Daten erforderlich, die auf Basis von Internettechnologien für jeden Kooperationspartner zugänglich ist Zusammenfassung Da EAI-Produkte den Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business nur bedingt gerecht werden, müssen erweiterte Anforderungen an Informationssysteme gestellt werden. Tatsache ist, dass gegenwärtige EAI-Lösungen nicht den Aspekt der übernehmensübergreifenden Abwicklung von Geschäftsprozessen erfüllen. Unter den vier verschiedenen Arten der Integration (Data, People, Process und Application) lassen sich die modernen Integrationsanforderungen zusammenfassen. Die Datenintegration beschreibt dabei den schnellen Zugriff auf Daten und Informationen innerhalb eines Unternehmens, als auch die überbetriebliche Interaktion mit B2B-Partnern in der der Supply Chain. Die klassische Middleware verfolgt das Ziel einer einheitlichen und konsistenten Datenbasis in einem Unternehmen, in dem man heterogene Datenquellen zusammenführt. Dieser Aspekt wird im Collaborative Business erweitert. Die People Integration erfordert über ein Webportal (also auf der Basis von Internettechnologien) einen personalisierten Zugang zu verschiedenen Applikationen. Dabei erscheint es dem User, als ob er nur eine Anwendung ausführt. Durch den personalisierten Bereich stehen dem Anwender nur die Informationen bereit, die er auch wirklich benötigt. Die Process Integration ermöglicht durch gezielte Funktionsaufrufe in verschiedenen Applikationen die Abwicklung von unternehmensübergreifenden Geschäftsprozessen. Lose gekoppelte, technisch weniger komplexe Systeme auf Basis von Internet-Standardtechnologien sollten in Zeiten des C-Business die Grundlage bilden. Die Application Integration rundet die Integrationsebenen ab, indem sie alle Integrationsarten zusammenfasst und eine flexible und offene Architektur von Softwaresystemen verlangt. Nicht zu vergessen sind die hohen Anforderungen an die Performance, die Skalierbarkeit, die Sicherheit und die Zuverlässigkeit an denen jedes Informationssystem gemessen wird. Das folgende Schaubild fasst die unterschiedlichen Integrationsanforderungen grafisch noch einmal zusammen. 39 [ScWe03], S [ScWe03], S. 39 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 27

28 INTEGRATIONSANFORDERUNGEN AN KÜNFTIGE SOFTWARESYSTEME Abbildung 7: Zusammenfassung der Integrationsanforderungen an Softwaresysteme in Zeiten des C- Business [ScWe03], S. 55 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 28

29 5 Moderne Lösungsansätze Das Kapitel Moderne Lösungsansätze geht ganz grob auf die verschiedenen Integrationstechnologien und -lösungen auf dem Markt ein, die den Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business nachkommen möchten. Technologien wie XML und WebServices erscheinen vielversprechend zu sein. Anschließend werden die Integrationslösungen von Microsoft und IBM vorgestellt. 5.1 XML Dem Mangel an standardisierten Kommunikations- und Datenaustauschmöglichkeiten versucht man mit der Extensible Markup Language (XML) zu begegnen. Mit XML handelt es sich um eine standardisierte Sprache zur Notation der Syntax von Auszeichnungssprachen (Metasprachen). Die Kernidee von XML besteht in der strikten Trennung von Inhalt, Struktur und Darstellung. XML ist in Zeiten des C-Business deshalb so wichtig, weil diese standardisierte Sprache die Forderung nach einem einheitlichen Datenaustauschformat (siehe Kapitel 4 Data Integration ) erfüllt. Es steht somit ein plattformübergreifendes und anwendungsneutrales Datenformat zur Verfügung und stellt eine Schlüsseltechnologie dar, um beispielsweise Nachrichten, die in XML beschrieben sind, zwischen heterogenen Applikationen auszutauschen WebServices Unter WebServices versteht man im Wesentlichen Aufrufe von Prozeduren auf entfernten Servern über ein offenes Standardprotokoll. WebServices versetzen IT-Applikationen in die Lage mit anderen Softwarekomponenten Daten und Informationen auszutauschen. Aus betriebswirtschaftlicher Sicht übernehmen WebServices klar abgrenzbare, hoch standardisierte Aufgaben aus Prozessen, sind zeit- und/oder transaktionsbasiert verrechenbar und in die Applikationswelt eines Unternehmens mit den bestehenden Systemen integrierbar. Aus technischer Sicht zielen WebServices auf die Kommunikation lose gekoppelter Softwarekomponenten. Auf Basis von Standards wie XML, SOAP, WSDL und UDDI dienen sie als Grundlage einer unternehmens- und anwenderübergreifenden automatisierten System-zu- System-Kommunikation Vgl. [MeCR02], S. 225 und [PuCP03], S. 150 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 29

30 MODERNE LÖSUNGSANSÄTZE Abbildung 8: Die Ebenen eines WebService 44 Aufgrund des hohen Standardisierungsgrades eignen sich WebServices hervorragend für den überbetrieblichen Bereich. Zur Verbindung von inner- und überbetrieblicher Geschäftsprozesse ist eine Verbindung von EAI-Lösungen und WebServices erforderlich. WebService-Standards werden daher existierende EAI-Systeme in Unternehmen um die überbetriebliche Funktion erweitern. (siehe Kapitel 4 Process Integration) Die Technologie der WebServices wird bislang nur in Pilotprojekten eingesetzt, was zeigt, dass sie noch nicht vollständige Reife erlangt hat. Die folgende Tabelle vergleicht die Ansätze der EAI-Systeme und der WebServices: Tabelle 2: Vergleich von EAI-Systemen und WebServices [DuBI04], S [PuCP03], S. 156 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 30

31 MODERNE LÖSUNGSANSÄTZE 5.3 Frameworks Ein Framework stellt wiederverwendbare, halbfertige Anwendungen und zugehörige Integrationsmuster bereit, die generische Lösungen für eine Reihe verwandter Probleme implementieren, und so die Entwicklung von Applikationen für bestimmte Anwendungsbereiche vereinfachen. 46 Ein Framework ist also nichts anderes als ein Baukastenprinzip. Mit Hilfe vorgefertigter Bausteine lassen sich schnell und einfach Applikationen entwickeln. Im folgenden werden zwei neuere Frameworks sehr kurz und oberflächlich vorgestellt, zum einen Sun s J2EE (Java 2 Enterprise Edition) und zum anderen Microsoft s.net. Beide Frameworks halten zusätzlich Serverlandschaften bereit J2EE J2EE ist eine Spezifikation für eine unternehmensweite Anwendungsarchitektur von Sun Microsystems. Basis bildet die plattformunabhängige objektorientierte Programmiersprache Java. Dieses Framework verfolgt den Ansatz, wie Unternehmensanwendungen gebaut werden sollten. Dabei werden die Anwendungen in vier verschiedene Serverschichten zerlegt. 1. Client-Schicht (für den Benutzer, der sich einem HTML-Browser bedient) 2. Web-Komponenten-Schicht (Erzeugung von HTML-Seiten durch Java Server Pages) 3. Business-Logik-Schicht (enthalten Geschäftsobjekte oder -komponenten) 4. Enterprise-Information-System-Schicht (kommuniziert mit den einzelnen Informationssystemen) Im Falle von Geschäftsprozessintegration und Prozessautomatisierung sowie B2B-Integration muss man zu seinem J2EE-Applikationsserver Funktionalität dazukaufen, z.b. in Form eines EAI-Integrationsservers. 47 Die vier verschiedenen Serverschichten belegen, dass die Firma Sun mit dem Framework J2EE den gestellten Integrationsebenen (Data, People, Process und Application) nachkommen möchte NET Microsoft stellt.net auf der Entwickler-Website folgendermaßen vor: Microsoft.NET is an XML Web services plattform that will enable developers to create programs that transcend device boundaries and fully harness the connectivity on the internet. Grundgedanke ist, dass Bezieher von Diensten nicht nur Clients mit Browsern sind, sondern beliebige Anwendungen, die sich Dienste anderer Anwendungen über das Netz bedienen also echte verteilte Verarbeitung über das Netz. WebService können unter.net einfach und schnell erstellt werden. Microsoft hat mit.net die Idee einer universellen Ausführungsumgebung für viele Programmiersprachen aufgegriffen, die durch Java allerdings aus Gründen der Portabilität schon vorher beschritten worden war. Die entsprechende Laufzeitumgebung heißt bei.net Common Language Runtime (CLR). 48 Auch hier ist klar zu erkennen, dass Microsoft mit der Architektur 46 [MeCR02], S Vgl. [KEAI02], S Vgl. [KEAI02], S Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 31

32 MODERNE LÖSUNGSANSÄTZE und Funktionsweise von.net die unternehmensübergreifenden Integrationsanforderungen erfüllen möchte. Abbildung 9: Aufbau des.net Frameworks Build-to-integrate-Lösungen Hier werden die Initiativen von zwei großen, namhaften IT-Marktführern zur Abwicklung von unternehmensübergreifenden Geschäftsprozessen betrachtet. Angeführt werden der BizTalk- Server von Microsoft und IBM s WebSphere-Lösung. Beide Build-to-integrate-Lösungen werden nur kurz beleuchtet, da es sonst den Rahmen dieser Studienarbeit sprengen würde BizTalk-Server Hinter dem BizTalk-Server von Microsoft steckt ein voll funktionaler EAI-Integrationsserver. Ziel ist die Automatisierung des Nachrichtenverkehrs zwischen Unternehmen. Das wesentliche Einsatzgebiet ist B2B-Kommunikation von Unternehmen, die über XML kommunizieren. Primär unterstützte Formate für den Nachrichtenaustausch sind XML, EDI und Textdateien. Mittels BizTalk kommunizieren Organisationen, in dem sie ihre Nachrichten an einen Channel schicken. Die Nachrichten können aber auch vom BizTalk-Server aktiv abgefragt werden. Der BizTalk- Server ist in der Lage, Nachrichten zu analysieren, zu transformieren und wieder zu verteilen. Die Architektur des BizTalk-Servers besteht aus drei Schichten. 1. Prozessschicht (enthält eine Prozessbeschreibungssprache) 49 [DuBI04], S. 32 Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 32

33 MODERNE LÖSUNGSANSÄTZE 2. Kommunikationsschicht (BizTalk-Editor, der die Konventionen für die BizTalk- Nachrichten berücksichtigt und unterstützt und BizTalk-Mapper, der XML-Files, EDI- Files und Textfiles transformieren kann) 3. Adapter (für die normale Übertragung von XML-Dateien) WebSphere IBM s WebSphere ist eine Infrastruktursoftware für dynamisches E-Business, sozusagen eine Produktfamilie bestehend aus sicheren und zuverlässigen Softwareprodukten, zur Entwicklung zuverlässiger E-Business-Anwendungen. WebSphere verwendet als Basisframework das von Sun Microsystems erarbeitete J2EE und schließt die Lücken zwischen Geschäftsprozessen und Informationstechnologien. Im Rahmen dieser Plattform spielt die Komponententechnologie Enterprise Java Beans (EJB) eine tragende Rolle. Enterprise Java Beans verkörpern die Anwendungsfunktionalität, die Geschäftsobjekte und die Geschäftslogik. Ablaufumgebung für J2EE-Anwendungen ist der Applikationsserver. Ein Applikationsserver liefert die gesamte Infrastruktur der Anwendungen, wie z.b. Ressourcenverwaltung, Transaktionssicherung, Datenbankzugriffe und vieles mehr. Das WebSphere-System gehört zu den marktführenden Web-Application-Server-Lösungen. Der WebSphere-Server weist eine dreischichtige Architektur auf: Er verarbeitet die Browsereingaben des Anwenders, stellt den Zugriff auf Ihre unternehmensinternen Datenbanken her und bildet die gesamte Anwendungslogik ab Vgl. [KEAI02], S Vgl. [DuBI04], S Integrationsanforderungen an Softwaresysteme in Zeiten des C-Business 33