TIBET ... Tricept Integrated Business Enterprise Technology. Whitepaper. Version 2.1

Transkript

1 TIBET Tricept Integrated Business Enterprise Technology Whitepaper Version 2. Hohler Weg Detmold Telefon 0523 / Telefax 0523 / Bruchtorwall Braunschweig Telefon: 053 / Telefax: 053 / Benzstraße Fellbach Telefon 07 / Telefax 07 /

2 Inhaltsverzeichnis Inhaltsverzeichnis... 2 Inhalt dieses Dokumentes... 4 Eine kurze Einführung in J2EE... 5 J2EE in Theorie und Praxis... 5 Einschränkung einer klassischen J2EE-Anwendung... 5 Die grafische Benutzeroberfläche der J2EE-Anwendung... 5 Der EJB-Container der J2EE-Anwendung... 6 Blick auf die klassische J2EE-Anwendung am Beispiel... 6 Folgen dieses Lösungsansatzes... 7 Multi Channel Architecture (MCA) als Lösungsarchitektur... 7 Anforderungen an Frameworks für Middletieranwendungen... 8 Allgemeine Anforderungen... 8 Anforderungen von Entwicklern... 8 Anforderungen von Systembetreuern... 9 TIBET... 0 Grundgedanken und Konzepte... 0 Schichten in TIBET... 2 Die Clientschicht... 2 Die Gatewayschicht... 2 Die Sessionschicht... 3 Der Processlayer... 5 Der Businesslayer, die Businessfunktion- und Businessobjekt-Schicht... 5 Die Servicesschicht... 5 Die Backendschicht... 6 Kommunikation zwischen den Frameworkschichten... 7 Ablaufsteuerung und Kompetenzservice... 8 Technische Beschreibung der Kernkomponenten Der Businesslayer Die Businessfunktionen Die Businessobjekte Die Datenschicht

3 Die Managerobjekte... 2 Unterstützung der Mehrsprachigkeit Die Request- und Resultobjekte Die Services TIBET und Webservices Das Exceptionhandling Die Transaktionskontrolle Beispiele zu Usertransaktionen Der Sessionkontext TIBET im Batchbetrieb Mitgelieferte TIBET-Tools Der generische Testclient für TIBET Der Lasttestclient für TIBET Das Deploymenttool für TIBET Sourcecodegeneratoren für TIBET Backendsimulation Tricept-Basisklassen Die JUnit-Tests

4 Inhalt dieses Dokumentes Das vorliegende Dokument ist in drei verschiedene Teilbereiche gegliedert: Eine kurze Einführung in J2EE Dieses Kapitel erläutert, was J2EE eigentlich bedeutet, in welchen Bereichen heute welche Arten von Software entstehen und eingesetzt werden und welche Vor- bzw. Nachteile die Verwendung von verschiedenen Standardarchitekturen oder -Frameworks bietet. Anforderungen an Softwarearchitekturen im Middletier Dieser Abschnitt beschreibt aus unterschiedlichen Blickwinkeln, welche Anforderungen an eine Middletiersoftwarearchitektur in der Regel gestellt werden. Beschreibung von TIBET In den restlichen Kapiteln geht es um die detaillierte Vorstellung der verschiedenen technischen Aspekte des realisierten J2EE-Frameworks. Sollten Sie mit dem Begriff J2EE vertraut sein und die Anforderungen an moderne Middletiersoftwarearchitekturen kennen, so empfehlen wir Ihnen, Ihre Lektüre mit dem Kapitel TIBET auf Seite 0 fortzusetzen. 4

5 Eine kurze Einführung in J2EE J2EE in Theorie und Praxis J2EE stellt ein Komponentenmodell für die Entwicklung und den Einsatz von Unternehmensanwendungen dar, welches auf offenen Standards basiert und standardisierte Technologien wie JNDI, EJB, JSP und JDBC bereitstellt. Da der Zugriff auf kritische Dienste wie z.b. Transaktions- und Persistenzdienste gekapselt erfolgt, wird die Anwendungsentwicklung wesentlich vereinfacht. Die J2EE-Spezifikation liegt derzeit in der Version 5.0 (.5 nach alter Nummerierung) vor. Produktiv wird momentan die J2EE-Version.4 eingesetzt. Hierfür existiert eine Vielzahl von Entwicklungsumgebungen und Anwendungsservern, z.b. Produkte von IBM, BEA, Oracle, SAP, JBoss, Apache usw. In der Version 5.0 von J2EE kommen Enterprise Java Beans der Spezifikation 3.0 zum Tragen. Durch den Einsatz von Plain Old Java Objects (POJOs) wird die Programmierung der Persistenzschicht vereinfacht. POJOs stellen klassische Javaobjekte dar, welche z.b. im Zusammenhang mit Object-Relational-Mapping-Konzepten verwendet werden - der Trend geht wieder zu einfachen Objekten und ist als Ablösung bzw. Ergänzung der Entity Beans zu sehen, zumal POJOs im Gegensatz zu Entity Beans flexibler handhabbar sind. Außerdem wird eine neue Persistenz-API eingeführt, welche die Java Data Objects (JDO) in ihrer Bedeutung ablöst bzw. ergänzt. Die Unterstützung im Clientbereich wird mit der Erweiterung der Spezifikationen Java Server Faces, Java Server Pages und AJAX weiter ausgebaut. Der Fokus liegt dabei auf Webanwendungen (z.b. Web 2.0). Am Markt existieren diverse Persistenzframeworks, z.b. Hibernate, welche den POJO-Gedanken verfolgen. Mit der J2EE-Version.4 kamen diverse Frameworks auf den Markt, welche JDO zur Persistierung verwendeten. Gerade im Bereich der Persistierung wechseln sich mit jeder neuen J2EE-Version auch die Verfahren ab. J2EE-Anwendungen bieten ihren Clients Dienste (oder auch Geschäftsprozesse) an. Die serviceorientierte Architektur (SOA) stellt fachliche Funktionalitäten in Form von Diensten über eine standardisierte Schnittstelle bereit und kann mittels J2EE realisiert werden. SOA sieht eine Menge voneinander unabhängiger, lose gekoppelter Dienste vor, so dass sich komplexe Geschäftsprozesse durch eine Aneinanderreihung von Serviceaufrufen realisieren lassen. Zumeist werden für SOAs Webservices auf der Basis von SOAP, WSDL und UDDI eingesetzt. Aber auch der Einsatz jeder anderen dienstbasierten Technologie wie z.b. CORBA oder Enterprise Java Beans ist möglich. SOA ist besonders gut zu Kopplung von Systemen (oft auch unterschiedlicher Programmiersprachen) geeignet, z.b. Anbindung eines Microsoft.NET-Clients unter Microsoft Windows an einen Java Enterprise Server (z.b. TIBET) unter Unix. Das Spring-Framework ist ein Komponentenmodell für lokale Middletiers, welches auf POJOs aufbaut und explizites Deployment á la EJB von vornherein vermeidet. Spring kann deklarative Transaktionen und frei definierte Aspekte auf POJOs anwenden. Einschränkung einer klassischen J2EE-Anwendung Klassische J2EE-Projekte, die derzeit entwickelt werden oder bereits umgesetzt sind, gehen zumeist von einer starken Bindung zwischen Servletengine und EJB-Container aus, oft wird auch gar kein EJB-Container verwendet und die Fachlogik direkt im Servlet (z.b. Apache Tomcat als Servletcontainer) implementiert, bzw. man verwendet lediglich Entity Beans zur Persistierung. Fachlogik in Session Beans ist derzeit eher selten anzutreffen. Die grafische Benutzeroberfläche der J2EE-Anwendung Bei modernen Anwendungen geht der Trend zu browserbasierten Ansätzen bei der Gestaltung des Benutzerinterfaces (Frontend). Die grafische Benutzeroberfläche wird mit Hilfe von Servlets, Java Server Pages und Java Server Faces implementiert. Um die Servletentwicklung zu vereinfachen, werden oft Servletframeworks wie z.b. das freie Framework Apache Struts eingesetzt. Durch den Einsatz von AJAX-Frameworks (Stichwort Web 2.0) lassen sich komplexe Webanwendungen realisieren. Komplexere grafische Benutzeroberflächen werden unter Verwendung von Java Swing realisiert, oft auch in Verbindung mit einem Framework. Ein weiterer aktueller Trend ist die Realisierung des Clients mit anderen Architekturen (zum Beispiel Microsoft.NET). Auch eine direkte Anbindung 5

6 von Microsoft Office-Produkten ist möglich. Dabei verläuft die Kommunikation häufig über Webservices (SOAP) mit dem Applicationserver. Clientanwendungen werden im Allgemeinen nach dem Model-View-Controller-Paradigma (MVC) entwickelt. Hierbei wird die Trennung einer Anwendung mit grafischer Oberfläche in drei Teilen beschrieben:. Model: Datenmodell, welches der Anwendung zugrunde liegt und die Anwendungslogik (Fachlogik, Businesslogik) beinhaltet 2. View: Darstellung der Verarbeitungsergebnisse (Oberflächengestaltung) 3. Controller: Grafische Oberflächenfunktionalität und Auswertung der Eingabeformulare Diese Trennung hat sich für objektorientierte Anwendungen in der Praxis bewährt, da Abhängigkeiten zwischen dem Datenmodell, der grafischen Oberfläche und der Darstellung der Daten weitestgehend vermieden werden. Der EJB-Container der J2EE-Anwendung Unter dem Begriff Java Beans sind im Allgemeinen eigenständige Javamodule mit überschaubarem Funktionsumfang zu verstehen. In einer auf J2EE basierenden Anwendung werden so genannte Enterprise Java Beans (EJB) im EJB-Container des Applikationsservers veröffentlicht (deployed). In den meisten Fällen handelt es sich dabei um Session Beans, welche die Prozesslogik der Anwendung abbilden und um Entity Beans, welche die Schnittstelle zur Datenbank bilden und deren Einträge zur Laufzeit repräsentieren. Anstelle der Entity Beans können auch Java Data Objects, Plain Old Java Objects (Hibernate) oder andere Persistenzframeworks verwendet werden. Es werden zwei Arten von Session Beans unterschieden: Stateful Session Bean Müssen Session Beans über mehrere Methodenaufrufe hinweg ihren Zustand halten, etwa um an einer länger andauernden Transaktion teilzunehmen, so müssen sie zustandsbehaftet vereinbart werden zwischen zwei Aufrufen halten sie ihren Zustand. Stateless Session Bean Session Beans werden für serviceartige Funktionalität (fire and forget) zustandslos ausgelegt. Nach jedem Aufruf geht ihr Zustand verloren. Blick auf die klassische J2EE-Anwendung am Beispiel Als Beispiel wird eine Anwendung betrachtet, die ihr Benutzerinterface mit dem Framework Struts realisiert. Für jede Funktionalität, die der Benutzer aufrufen kann, existiert im Frontend eine JSP- Seite (View gemäß MVC). Das Servlet agiert dabei als Controller, während das Model auf dem Server durch die Enterprise Java Beans gebildet wird. Durch das Absenden der Daten im View werden die eingegebenen Daten vom Servlet extrahiert und auf ihre Gültigkeit überprüft. Die Daten werden verpackt und an die zuständige Session Bean des EJB-Containers geschickt. Dort werden die Daten weiterverarbeitet und gegebenenfalls persistiert. Der Datenzugriff wird mit Entity Beans realisiert. Als persistenter Datenspeicher wird eine über JDBC ansprechbare, relationale Datenbank verwendet. Der Datenzugriff steht unter Transaktionskontrolle, d.h. es wird gewährleistet, dass alle ausgeführten Aktionen beim Auftreten eines Fehlers rückgängig gemacht werden können. Beispielsweise können schreibende Operationen auf n Entity Beans in einem gemeinsamen Transaktionskontext erfolgen. Eine Transaktion kann dabei aus einer Session Bean oder auch aus dem Servlet heraus begonnen werden. Der J2EE-Standard lässt dem Entwickler die Freiheit, die Transaktionssteuerung selbst zu übernehmen (Bean Managed Persistence), oder aber dieses dem Container zu überlassen (Container Managed Persistence). Dieses Vorgehen führt jedoch in der Praxis zu einem nicht zu unterschätzendem Implementierungsaufwand, sowie zum Verlust der Portabilität bzw. der Konfigurierbarkeit der Anwendung. 6

7 Folgen dieses Lösungsansatzes Eine auf diese Weise implementierte Anwendung ist auf die Verwendung von Servlets im Frontendbereich festgelegt. Die Anbindung weiterer Frontends wie zum Beispiel Java Swing-Clients oder auch Microsoft.NET-Clients ist ohne großen Aufwand nur schwer möglich. Um dennoch andere Clientlösungen anbinden zu können, müsste zunächst ein Wrapper auf die Servleteingabeformulare entwickelt werden. In den meisten Fällen endet dies jedoch mit einer kompletten Neuentwicklung der Anwendung. Oft wird bei der Umsetzung von J2EE-Anwendungen der Schwerpunkt auf nur eine Clientlösung gelegt, nämlich diejenige, deren Umstellung oder Neuentwicklung für das Unternehmen am wichtigsten ist. Eventuell später folgende Anwendungsfälle werden außer Acht gelassen. Dieses bedeutet, dass die Fachlogik mehrfach implementiert wird und auch spätere Änderungen und Erweiterungen an mehreren Stellen eingepflegt werden müssen. Beispiel: Eine Firma möchte ihren Sachbearbeitern über ein Webfrontend Zugriff auf ihr Warenwirtschaftssystem gewähren. Die Anwendung wird mit Servlets und einem Applikationsserver realisiert. Da wie oben beschrieben zu viel Fachlogik im Servlet implementiert wurde, ist ein zukünftiger Wunsch, das Warenwirtschaftssystem mit derselben Funktionalität über SOAP an eine bestehende Microsoft.NET-Anwendungen zu koppeln, nicht mehr möglich. Bei der Entwicklung von serverbasierten J2EE-Anwendungen ist darauf zu achten, an welcher Stelle die Fachlogik implementiert wird. Diese sollte vollständig im Applikationsserver angesiedelt sein nicht im Frontend, der Servletcontainer (obwohl er auf einem Server läuft) ist hier auch als Frontend anzusehen. Multi Channel Architecture (MCA) als Lösungsarchitektur Ein Lösungsansatz für dieses Problem stellt der Einsatz oder die Entwicklung eines MCA-tauglichen Frameworks dar. Eine Mehrkanalanwendung bietet viele Schnittstellen zur Präsentationsschicht, um möglichst viele Clientarten (Servlet, Java Swing, Microsoft.NET) integrieren zu können. Die Implementierung der Fachlogik wird unabhängig von der einzusetzenden Benutzerschnittstelle auf dem J2EE-Anwendungsserver durchgeführt. Im optimalen Fall ist der so entstehende Server als EAI- Server zu sehen, da die Anwendung auch in Richtung der Datenbasis, also zum Beispiel in Richtung von relationalen Datenbanken, Hostsystemen, Legacysystemen oder auch anderen schon e- xistierende Middletieranwendungen, offen ist. Unter Umständen kann die Serveranwendung sogar außerhalb der Serverumgebung als Fat Client eingesetzt werden, vorausgesetzt dieses wurde während der Designphase berücksichtigt. 7

8 Anforderungen an Frameworks für Middletieranwendungen Allgemeine Anforderungen Je universeller ein Middletierframework einsetzbar sein soll, desto wichtiger ist es, dass es unabhängig von verschiedenen Randbedingungen im Gesamtsystem ist. Dies setzt voraus, dass das Framework relativ flexibel ist, und sowohl clientseitig, als auch in Richtung der Backend- und Legacysysteme möglichst viele Kommunikationsarten und -protokolle unterstützt. Andererseits sollte die Implementierung an sich plattformunabhängig sein. Die Verwendung von allgemeinen Standards trägt zusätzlich dazu bei, dass ein solches Framework in seiner Einsatzvielfalt nicht eingeschränkt wird. Es muss möglich sein, bereits existierende Komponenten über Frameworkmechanismen einzubinden bzw. Komponenten des Frameworks durch andere auszutauschen. Diese Punkte bilden die Grundvoraussetzung für eine Mehrkanal- und Mandantenfähigkeit. Unabhängig davon, ob einfache oder hochkomplexe Abläufe, Kommunikation mit Webservices oder Hostsystemen, Bereitstellung von Schnittstellen für Servletengines oder SOAP-Clients, idealerweise sollte dies alles durch Frameworkmechanismen abgedeckt werden können. Da heutzutage viele Middletieranwendungen im Regelfall im 24/7-Betrieb laufen müssen, werden erhöhte Anforderungen an Stabilität, Ausfallsicherheit, Performance und Skalierbarkeit gestellt. Das setzt auch eine gewisse Fehlertoleranz des Frameworks voraus. Softwarefehler in einem Teilbereich dürfen nicht dazu führen, dass das ganze System nicht zur Verfügung steht. Ein kompromisslos flexibles und erweiterbares Framework kann langfristig eingesetzt werden. Die Anpassungsfähigkeit des Frameworks und die Austauschbarkeit seiner Komponenten tragen dazu bei, die Investitionen in die Middleware auf lange Sicht zu sichern, da auf neue Anforderungen flexibel reagiert werden kann. Anforderungen von Entwicklern Für Entwickler lohnt sich die Einarbeitung in ein Framework dann, wenn sie ihre Produktivität durch den Einsatz dieses Frameworks erheblich steigern können. Dafür ist es erforderlich, dass sich ein Entwickler erst einmal nicht um die komplexen Komponenten wie Session- und Fehlerhandling, Transaktionskontrolle, Prozesssteuerung oder Kompetenz- und Securityprüfungen kümmern muss, sondern er durch das Framework die Möglichkeit bekommt, sich voll auf die fachliche Entwicklung konzentrieren zu können. Ein durchgängiges Schichtenmodell innerhalb des Frameworks sichert eine klare Trennung der einzelnen Zuständigkeitsbereiche. Dazu müssen die Schnittstellen klar definiert sein. Das Framework kann die Implementierung der fachlichen Funktionalität durch die Bereitstellung eines Grundgerüsts von Business-Funktionen und Business-Objekten weiter unterstützen. Eine Abbildung der Relationen zwischen den einzelnen Business-Objekten erweitert die Möglichkeiten bei den Fachklassen zusätzlich. Vordefinierte Servicekomponenten wie ein Datenbankservice oder ein Loggingservice erleichtern die Entwicklung, ebenso wie im Framework verankerte Tracingmechanismen, die dabei helfen, Programmierfehlern auf die Spur zu kommen. Durch die Bereitstellung von Entwicklungsassistenten, wie zum Beispiel. Generatoren für bestimmte Standardklassen, lässt sich die Entwicklung noch weiter beschleunigen. Das heißt, im Framework sollten die technischen und fachlichen Abläufe, soweit möglich, schon vorimplementiert sein. Gleichzeitig muss ein gutes Framework trotzdem einfach zu verstehen sein. Dazu ist eine ausreichende Dokumentation unverzichtbar. Idealerweise braucht der Entwickler eine fachliche Funktion in der Middletieranwendung nur einmal zu implementieren. Danach steht sie allen angebundenen Client-Anwendungen zur Verfügung. Das Framework darf die Entwickler jedoch nicht unnötig einschränken. Auf neue oder sehr spezielle Anforderungen müssen sie auch im Rahmen des Frameworks flexibel reagieren können. Das Framework darf kein starres Gerüst sein. Anpassungen sollten auf einfache Weise vorgenommen werden können. 8

9 Anforderungen von Systembetreuern Für die Systembetreuung stehen andere Dinge im Vordergrund. Wichtig ist abgesehen von einem stabilen Laufzeitverhalten vor allem eine gute Administrierbarkeit einer Anwendung. Das schließt neben einer unkomplizierten Installation und Produktionseinführung auch Punkte wie Wartungsfreundlichkeit im Produktionseinsatz ein. Im Idealfall ist die Anwendung von außen per Monitoring leicht zu überwachen, so dass Ressourcenengpässe oder Fehlfunktionen von Komponenten schnell erfasst werden und Gegenmaßnahmen frühzeitig eingeleitet werden können. Die Daten, die eine Monitoringanwendung liefert, können zugleich dazu dienen, die Ursachen für Fehler im Gesamtsystem schneller zu identifizieren, etwa Programmierfehler oder Hardwaredefekte. In die Konfiguration des Frameworks sollte von außen eingegriffen werden können, damit nicht ständig neue Entwicklungszyklen angestoßen werden müssen. Das im Folgenden näher vorgestellte Softwareframework TIBET ist das Beispiel für eine Architektur, die den oben beschriebenen Anforderungen genügt. 9

10 TIBET Grundgedanken und Konzepte Bei TIBET handelt es sich um ein von der Tricept AG entwickeltes objektorientiertes Framework für Middletieranwendungen, das auf Java/J2EE basiert. Der Grundgedanke beim Entwurf des Frameworks war es, den Entwickler vom technischen Ballast zu befreien und ihm die Möglichkeit zu geben, sich ganz auf die fachliche Entwicklung zu fokussieren. Lösungen für die technischen Fragestellungen und allgemeingültige fachliche Abläufe stellt das Framework zur Verfügung oder lassen sich zumindest auf einfach Weise im Framework verankern. Die TIBET zugrunde liegende Architektur sollte serviceorientiert sein. Eine große Rolle beim Design des Frameworks spielte die Anwendbarkeit von TIBET auf den Feldern MCA und EAI, sowie eine starke Komponentenorientierung. Mit der Entwicklung von TIBET hat die Tricept AG ihr gesammeltes technisches Know-How, das ganze Wissen um fachliche und technische Prozesse und nicht zuletzt die langjährige Erfahrung ihrer Entwickler und Consultants in einem Produkt integriert. TIBET zeichnet sich durch ein hohes Maß an Universalität und Flexibilität aus. Das Framework ist offen für zahlreiche Kommunikationsprotokolle und unabhängig von der Systemarchitektur. Das ermöglicht es dem Benutzer, prinzipiell jeden Typ von Middletieranwendung mit TIBET zu entwickeln. Besonderer Wert wurde auf ein zeitloses Frameworkdesign und auf die Wiederverwendbarkeit der Frameworkkomponenten gelegt, um sicherzustellen, dass die verwendeten Konzepte auch in Zukunft noch tragfähig sind. TIBET ist plattformunabhängig. Ob IBM Websphere, BEA Weblogic oder JBOSS mit TIBET entwickelte Anwendungen sind uneingeschränkt lauffähig. Es nutzt die Vorzüge der J2EE-Architektur, ist aber gleichzeitig so unabhängig von den J2EE-Mechanismen, dass man auch Fat-Client-Anwendungen damit entwickeln kann, die ganz ohne Applicationserver auskommen. Diese Unabhängigkeit geht so weit, dass eine für einen Applicationserver entwickelte Anwendung auf TIBET-Basis im Regelfall ohne irgendeine Anpassung als Javaprogramm in einer ganz normalen Java Virtual Machine laufen kann, z.b. auf einem Hostsystem. Die J2EE-Mechanismen sind durch TIBET für den Entwickler bei der Erstellung des fachlichen Codes vollkommen transparent. Die Frameworkkonzepte lassen sich problemlos auf andere objektorientierte Programmiersprachen oder Serverarchitekturen übertragen. Abbildung : TIBET in einer heterogenen Systemumgebung TIBET setzt konsequent auf Schichtentrennung mit definierten Schnittstellen. Jede der TIBET- Schichten ist somit auf einfache Weise austausch- und erweiterbar. 0

11 Um die fachliche Implementierung zu beschleunigen, bietet TIBET einen leistungsfähigen Businesslayer mit Businessobjekten und Businessfunktionen an. Dieser bildet durch die Bereitstellung von Relations- und Transaktionsmechanismen den Rahmen zur Implementierung von fachlichen Prozessen, in denen Businessobjekte manipuliert und diese Änderungen anschließend persistiert werden. Die Prozesssteuerung kann selbst programmiert werden oder durch externe Tools erfolgen. Dabei ist es nicht relevant, ob es sich um kurz- oder langlebige Prozesse oder um synchrone oder asynchrone Prozesse handelt. Die bei der Ausführung der Businesslogik in der Regel notwendigen Kompetenz- und Autorisierungsprüfungen sind im TIBET-Framework bereits verankert und können an die Bedürfnisse des Benutzers angepasst werden. TIBET ist generell mandantenfähig. Der Businesslayer unterstützt durch spezielle Objekttypen mehrsprachige Anwendungen. Auf diese Weise können der Clientseite fachliche oder technische Meldungen in einer von außen konfigurierbaren Sprache zurückgeliefert werden. Der fachliche Code selbst bleibt dabei sprachunabhängig. In den Businesslayer integriert ist ein Freigabeverfahren für Änderungen an Businessobjekten. Ändert ein Benutzer die Attribute eines freigabepflichtigen Businessobjekts, so werden die die neuen Werte erst in den aktiven Bestand übernommen, wenn diese Änderung von einem anderen Benutzer kontrolliert worden sind. Dieser Freigabemechanismus ist so ausgelegt, dass er angepasst und erweitert bzw. komplett ausgeschaltet werden kann. Da TIBET universell einsetzbar sein soll, sind im Framework die Sonderfälle, die es in jeder Anwendung gibt, bewusst nicht berücksichtigt. TIBET ist aber durch sein flexibles Design für diese Fälle auf einfache Weise adaptierbar. Zum Umfang von TIBET gehören vordefinierte, jedoch modifizierbare Dienste wie Logging, Tracing und Datenbankzugriff. Ebenso besteht die Einsatzmöglichkeit von Monitoringkomponenten zur Ü- berwachung der Anwendung im Test- und Produktionsbetrieb. Die bei TIBET mitgelieferten Tools unterstützen den Entwickler wirkungsvoll bei der alltäglichen Arbeit, zum Beispiel durch: - Generierung von TIBET-Standard-Objektklassen - Sofortigen Test der neu entwickelten Businesslogik durch einen generischen Testclient - Erzeugung von JUnit-Testklassen auf Knopfdruck für automatisierte Tests - Unterstützung des Deployments der Anwendung auf dem Applicationserver TIBET ist unterteilt in sieben, durch definierte Schnittstellen voneinander entkoppelte Schichten. Abbildung 2: TIBET-Schichtenmodell

12 Dabei repräsentieren die Client- und die Backendschicht die Systemumgebung, in der TIBET eingesetzt wird. Das eigentliche Framework setzt sich aus den Schichten zwei bis sechs zusammen: - Schicht : Client - Schicht 2: Gateway - Schicht 3: Session - Schicht 4: Processlayer - Schicht 5: Businesslayer - Schicht 6: Services - Schicht 7: Backend, also z.b. Datenbanken, Legacysysteme oder Webservices Eine detaillierte Beschreibung der einzelnen Schichten und ihrer Aufgaben im Framework findet sich im folgenden Abschnitt. Schichten in TIBET Die Clientschicht Als Client wird jede Anwendung bezeichnet, die mit TIBET kommuniziert. Das sind zum Beispiel in Java Swing implementierte Anwendungen, Java Servlets, Java Applets, Microsoft.NET- Anwendungen oder sogar andere Anwendungsserver. TIBET unterstützt durch seine offene Architektur und Vielzahl von Kommunikationsprotokollen (RMI, CORBA, SOAP, FILE, usw.) die Anbindung einer großen Clientzahl. Beispielsweise lassen sich Microsoft.NET-Anwendungen genauso einfach wie das PHP-Framework TACOMA der Tricept AG problemlos an TIBET über SOAP anbinden. Das klassische Kommunikationsprotokoll zur Anbindung von Java-Anwendungen ist RMI oder RMI über HTTP (bei Verwendung einer Firewall). Weitere Kommunikationsprotokolle können durch das TIBET-Gatewaykonzept einfach implementiert werden. Die Anbindung von Kommunikationsprotokollen erfolgt im Framework generisch, eine Anpassung der einzelnen Fachfunktionen ist nicht nötig. Eine mit TIBET entwickeltet Anwendung kann jederzeit um neue Kommunikationsprotokolle erweitert werden. TIBET ist durch sein Gatewaykonzept offen für nahezu alle Clientarten. Die Gatewayschicht Die Gatewayschicht stellt in TIBET die Möglichkeit dar, einen in einer beliebigen Programmiersprache geschriebenen Client über ein beliebiges Kommunikationsprotokoll anzubinden. Von Haus aus unterstützt TIBET zunächst alle Arten von Javaclients, die über RMI mit dem Server kommunizieren. Bei der Kommunikation über RMI (direkter Austausch von serialisierten Javaobjekten) wird die Anwendung selbst als Gateway betrachtet, d.h. ein dediziertes Gateway existiert hierfür nicht. Javaanwendungen werden aus Gründen der Performance in der Regel immer über RMI angebunden. Weitere Beispiele für Gateways sind das CORBA-Gateway, das SOAP-Gateway oder das MQSeries- Gateway. Da der TIBET-Server intern Zustandsinformationen über den angemeldeten Benutzer, Workflow, Transaktion u.ä., speichert, kommt dem Gateway desweiteren die Aufgabe zu, diese Zustandsinformationen den Anfragen zustandsloser Clients eindeutig zuzuordnen. SOAP-Clients sind in der Regel zustandslos. Sie können demnach eigentlich nur Funktionalität der Art fire and forget auf dem Server nutzen. Die Gatewayschicht des TIBET-Servers führt für zustandslose Protokolle oder auch Clients eine Umsetzung auf eine zustandsbehaftete TIBET-Session durch. Dieses wird durch den Austausch von eindeutigen IDs (Credentials) zwischen Client und Server erreicht. 2

13 RMI-GW CORBA-GW SOAP-GW... Gateway SessionContext Service verwaltet 0.. verwendet verwaltet 0.. verwaltet Transaction Config HostService Tracing Logging DatabaseService KompetenzService verwendet... delegiert Requests UserSession IBSession... Session verwaltet und erzeugt besitzt 0.. BusinessFunction 0.. steuert viele kennt bearbeitet viele BOManager kennt verwaltet verwaltet BOFactory BOCache RelationFactory kennt erzeugt 0.. BusinessObject verwaltet viele hat viele 0.. kennt Relation erzeugt RelationDescriptorFactory erzeugt und verwaltet RelationDescription BDManager BDFactory erzeugt verwaltet DataAccessDescriptorFactory kennt erzeugt Workflow steuert 0.. Process steuert viele hat BusinessData DataAccessDescriptor Person Adresse Vereinbarung... Abbildung 3: Schematisches UML-Modell des TIBET-Frameworks Die Sessionschicht Die TIBET-Session stellt eine eindeutige Zuordnung von Client und Server dar. Jeder Client, der mit dem Server kommunizieren möchte, fordert zunächst von diesem eine Session an. Durch unterschiedliche Sessiontypen bietet das Framework den Clients speziell auf ihre Anforderungen zugeschnittene Funktionalitäten. Im Umfeld einer Bankinganwendung könnte die Session z.b. abhängig vom jeweiligen Vertriebsweg sein. In diesem Szenario gäbe es z.b. eine Internet-Banking-Session, eine SB-Banking-Session oder eine HBCI-Banking-Session. Zusätzlich könnte man sich einen speziellen Sessiontyp für die Administration des Bankingservers vorstellen. Denkbar wäre es auch, dass für den Fall, dass die Middletieranwendung Online- und Batchfunktionalität bieten soll, für Batch- und Onlinebetrieb jeweils eigene Sessiontypen angeboten werden. Für Demonstrationszwecke liefert TIBET eine vordefinierte allgemeine Benutzersession mit. Die Sessionschicht stellt die äußere Schnittstelle des Frameworks für die Clients zur Verfügung. Ein Client schickt alle Anfragen über die Gatewayschicht an seine Session. Von dort werden sie an den Empfänger weitergeleitet. Durch das Sessionkonzept werden Clientrequests an einem zentralen Eingangspunkt im Server empfangen. Diese Stelle wird von allen Sessions in gleicher Weise genutzt und kann deshalb als zentraler Monitoring- und Loggingpunkt verwendet werden. Hier prüft das Framework auch bereits die Autorisierung des Clients bzw. Benutzers für die gewählte Anfrage. Im Standard-TIBET-Berechtigungskonzept spielen Gateway- und Sessionschicht eine große Rolle. Zugriffsrechte lassen sich abhängig von Gateway und Sessiontyp definieren. Die Hauptarbeit bei der Ermittlung der Berechtigungen liegt allerdings beim Kompetenzservice. Korrespondierend zu jedem Sessiontypen existiert ein eigener Kompetenzservice, der die Möglichkeit bietet, Benutzerdaten- und berechtigungen sitzungsspezifisch zu prüfen. Zur Verdeutlichung soll hier ein Beispiel folgen: Client A wird über RMI an die Internet-Banking-Session angebunden Der Administrator kann für diese Kombination aus Gateway (RMI) und Session (Internetbanking) Zugriffsrechte vergeben. D.h. er bestimmt, welche Funktionalität auf dem Server für solche Clients aufgerufen werden darf. Erst anschließend erfolgt eine Auswertung der Berechtigungen, die für den angemeldeten Benutzer freigegeben sind. Beispielsweise darf das RMI-Gateway die Funktionen F a, F b und F c verwenden. Die Session Internetbanking besitzt Berechtigung für die Funktionen F b und F c. Jeder Benutzer, der über dieses Gateway und diese Session an der Server gelangt, darf demnach zunächst die Funktionen F b und F c 3

14 TIBET - Whitepaper aufrufen, sofern er selbst Berechtigungen dafür besitzt (Für jeden Benutzer können individuelle Berechtigungen zusätzlich definiert werden). Client B wird über SOAP an die SB-Banking-Session angebunden Für das SOAP-Gateway wurden die Funktionen F d, F e, F f und F g freigeschaltet. Die SB- Banking-Session besitzt per Voreinstellung Berechtigung für das Ausführen der Funktionen F f, F g und F h. Demnach darf jeder Benutzer, der über diese Kombination aus Gateway und Session an der Server gelangt, zunächst die Funktionen F f und F g verwenden. Durch die Kombination aus Session und Gateway lassen sich die Benutzerrechte schon sehr granular definieren. So könnte ein SB-Banking-Benutzer durch Vergabe entsprechender Berechtigungen nicht dieselben Funktionen aufrufen, für die er über HBCI kommend autorisiert wäre. Dieses eher statische Berechtigungskonzept wird wesentlich erweitert durch den sessionspezifischen Kompetenzservice, der die Möglichkeit bietet, zum Beispiel Benutzer bei der Anmeldung zu authentifizieren und deren Autorisierungen dynamisch für die aktuelle Situation festzustellen. Dabei spielt es keine Rolle, welche Arten von Berechtigungen geprüft werden sollen, und in welcher Form die Berechtigungen (Datenbank, LDAP-Verzeichnis usw.) abgelegt sind. Der Kompetenzservice kann vollständig an die Bedürfnisse des Anwenders angepasst werden.! " Abbildung 4: Berechtigungen von Client B Client und Server kommunizieren ebenso wie die einzelnen Frameworkkomponenten untereinander immer über Request- und Resultobjekte. Der Client z.b. benachrichtigt seine Session mittels eines Frontendrequests, welche Businessfunktion er ausführen möchte. Das Ergebnis dieses Aufrufs ist ein FrontendResult, das der Client vom Server zurück erhält. Wie diese Kommunikation im Detail verläuft, beschreibt das Kapitel Kommunikation zwischen den Frameworkschichten. In der Session erfolgt die erste Auswertung der vom Client als Frontendrequest gesendeten Anfrage. Der Frontendrequest wird nach formalem Check der Eingabeparameter und erfolgreicher Plausibilitätsprüfung in der Session in einen so genannten Businessrequest umgewandelt. Anschließend erfolgt eine Kompetenzprüfung. Sollte der aufrufende Client die Berechtigung besitzen, die geforderte Aktion durchzuführen, wird der Businessrequest an den Processlayer zur Weiterverarbeitung ü- bergeben. 4

15 Der Processlayer Der Processlayer dient zum einen der Verarbeitung der Clientanfragen, d.h. der Verarbeitung von Frontendrequests, die in Businessrequests umgewandelt wurden, und zum anderen der Verarbeitung der serverinternen Anfragen, d.h. der Servicerequests und internen Businessrequests. Jeder Request, der von der Prozessschicht zu verarbeiten ist, wird von ihr an den durch den Namen des Requests eindeutig spezifizierten Empfänger weitergeleitet. Empfänger der Requests sind die Frameworkservices (zum Beispiel Logging, Tracing, Datenbank, Kompetenz), sowie die Workflowsteuerung, welche für die Verarbeitung der Businessrequests verantwortlich ist. Der Processlayer steuert die Verarbeitung der Requests. Gleichzeitig ist er es, der frameworkseitig auf Fehler und Exceptions reagiert und somit eine Art von Transaktionskontrolle durchführt. In der Regel entspricht ein verarbeiteter Frontendrequest des Clients einer Transaktion, d.h. mit Ablieferung des Verarbeitungsergebnisses beim Client sind eventuelle Änderungen an Businessobjekten persistent. Im Fehlerfall werden die Änderungen durch den Processlayer gesteuert wieder rückgängig gemacht. Clients haben jedoch auch die Möglichkeit, dem Framework den Transaktionsbeginn von außen mitzuteilen, mehrere Frontendrequests abzuschicken und danach diese so genannte Usertransaktion abzuschließen bzw. rückgängig zu machen. Dementsprechend werden Änderungen an Businessobjekten erst dann persistiert, wenn der Client die Transaktion abschließt und nicht nach jeder Bearbeitung eines Frontendrequests. Der Businesslayer, die Businessfunktion- und Businessobjekt-Schicht Im Businesslayer ist die eigentliche Geschäftslogik der Anwendung angesiedelt. Businessfunktionen werden von einem internen Workflowobjekt angesteuert, das die Workflowsteuerung in TIBET repräsentiert. Die Businessfunktionen stellen die eigentliche Verarbeitungsstufe der Businessrequests dar. Dabei ist jedem Requesttyp genau eine Businessfunktion zugeordnet. Jede dieser Funktionen ist als eigene Klasse in TIBET vorhanden. Die vorgelagerten Frameworkkomponenten stellen sicher, dass der Zugriff auf Businessfunktionen nur dann gewährt wird, wenn der Benutzer dafür authentifiziert und autorisiert ist. Zur Implementierung der fachlichen Funktionalität greifen die Businessfunktionen auf Businessobjekte oder auch direkt auf die Servicesschicht zu. Änderungen an den Businessobjekten werden im jeweils gültigen Transaktionskontext abgelegt und bei Abschluss der Transaktion persistiert. Businessfunktionen können sich gegenseitig aufrufen. Businessobjekte repräsentieren in der Regel einen Datensatz. Das Framework stellt Mechanismen zur Verfügung, über die der Anwender solche Objekte lesen z.b. von der Datenbank oder neu erzeugen kann. Relationen zwischen den Businessobjekten können im Speicher abgebildet werden. Innerhalb einer Transaktion finden Änderungen an Businessobjekten nur im Arbeitsspeicher statt. Das Framework verwaltet im Businesslayer die Zustände der einzelnen Objekte, damit im Fall von geschachtelten Transaktionen diese teilweise wieder zurückgerollt werden können. Der Businesslayer kann dadurch die Businessobjekte im Arbeitsspeicher auf einen alten Zwischenzustand zurücksetzen. So kann der Benutzer dann im Regelfall mit seinem Prozess wieder aufsetzen, ohne die Daten erneut ermitteln zu müssen. Die Servicesschicht TIBET-Services sind funktionale Dienste, die in der Regel durch den Businesslayer über die jeweiligen Request-/Resultobjekte angesprochen werden, oder sich gegenseitig aufrufen. Man kann bei den Services unterscheiden in Persistenzservices, die vom Framework dazu benutzt werden, Datenänderungen zu persistieren, und Services mit eher fachlichem Funktionsumfang. Folgende Services sind zurzeit in TIBET verfügbar:. Datenbankservice Der Datenbankservice ist ein Persistenzservice und stellt die zentrale Datenzugriffsfunktionalität für relationale Datenbanken zur Verfügung. Er unterstützt neben dynamischen SQL- Statements auch Stored Procedures und Prepared Statements. 5

16 2. K3-Service Der K3-Service ist ein spezieller Persistenzservice für die Anbindung an das Konto Buchungssystem der Firma CSC Ploenzke. 3. Kompetenzservice Der Kompetenzservice ist als zentrale Komponente des Frameworks für Autorisierung und Authentifizierung zuständig. In seiner Defaultimplementierung ist neben der oben erwähnten an Gateway und Session orientierten Berechtigungsvergabe ein mächtiges datenbankgestütztes Berechtigungskonzept realisiert, in dem es möglich ist, Berechtigungen einzelnen Benutzern, Benutzergruppen und Benutzerrollen auf Businessfunktionsebene zuweisen. Diese Berechtigungen können zu Prozessgruppen zusammengefasst werden. Um einen Benutzer für einen Prozess zu berechtigen, genügt es somit, ihm die entsprechende Prozessberechtigung zuzuordnen. Er ist dann automatisch für alle Businessfunktionen, die im Rahmen des Prozesses aufgerufen werden, berechtigt. Sollte sich der Prozessablauf ändern, reicht es, wenn die zentrale Prozessberechtigung verändert wird. Die Benutzer besitzen dann automatisch alle für den neuen Prozess notwendigen Berechtigungen. 4. Journalservice Der Journalservice protokolliert alle Änderungen an journalisierbaren Businessobjekten in speziellen Datenbanktabellen. 5. Loggingservice Der Loggingservice dient zur Aufzeichnung und Ausgabe von Status- und Fehlermeldungen auf beliebigen Medien (Datei, Konsolefenster ) 6. Bankleitzahlservice Der Bankleitzahlservice berechnet und kontrolliert Prüfziffern von Kontonummern und IBANs, ermittelt die BIC zu einer Bankleitzahl und prüft Bankleitzahlen auf ihre Existenz. 7. Mailservice Der Mailservice bietet eine einfache Schnittstelle zum Versand von -Nachrichten aus der Anwendung heraus. 8. MQ-Service Beim MQ-Service handelt es sich um eine voll funktionsfähige prototypische Implementierung einer Anbindung an IBM MQSeries. 9. Hostservice Der Hostservice dient zur Simulation eines typischen Backendsystems und kann von Entwickler beliebig angepasst werden. Die Implementierungen dieser Services sind allgemein gehalten und sofort einsetzbar. Sie können vom Entwickler bei Bedarf an seine Anforderungen angepasst werden. Die Servicesschicht ist vielfältig konfigurierbar und leicht durch neue Services erweiterbar. Jeder angemeldete Benutzer erhält durch die Zuordnung zu einer eindeutigen Session eine eigene Servicesschicht vom System. Die Services sind in der Lage, untereinander zu kommunizieren. So besitzt der Kompetenzservice beispielsweise die Möglichkeit, jede Anmeldung am System automatisch durch den Journalservice protokollieren zu lassen. Die Backendschicht Alle Systemkomponenten, bei denen die Middletieranwendung in der Rolle des Clients ist, also die Komponenten, von denen TIBET mit Daten versorgt wird, liegen aus TIBET-Sicht in der Backendschicht. Diese Komponenten bieten ihren Clients fest definierte Schnittstellen an, über die die Kommunikation erfolgt. Dazu gehören Datenbank- oder Hostsysteme, Legacyanwendungen oder auch Webservices. 6

17 Die Kommunikation mit Backendsystemen bringt für Middletieranwendungen immer gewisse Probleme mit sich, etwa - Konvertierung interner Datentypen auf externe Datentypen und umgekehrt - Abbildung logischer Protokolle in physikalische Protokolle - Synchrone Abläufe, obwohl die Verarbeitung am Backend oder die Kommunikation mit dem Backend asynchron erfolgt All diese Aufgaben werden im TIBET-Framework von den Services übernommen. Sie stellen dem Businesslayer eine homogene Schnittstelle zu den Backends zur Verfügung, egal wie diese tatsächlich arbeiten. Kommunikation zwischen den Frameworkschichten Um innerhalb des Frameworks eine einheitliche und stabile Schnittstelle zu Verfügung zu stellen, folgt die Kommunikation in TIBET intern und extern dem so genannten Command-Entwurfsmuster. Die Frameworkschichten kommunizieren mittels Request- und Resultobjekten, die über eine von der jeweiligen Schicht bereitgestellten process-methode verarbeitet bzw. zurückgeliefert werden. In einem Requestobjekt werden die Anfragen an den Empfänger des Requests hinterlegt. Als Antwort vom Empfänger erhält der Absender das in einem Resultobjekt verpackte Ergebnis zurück. Dieses Kommunikationsmuster gilt ganz bewusst auch für die Kommunikation zwischen den Clients und dem TIBET-Framework. Der Client ruft die process-methode seiner Session auf. Parameter dieser Methode ist ein Frontendrequest, das die vom Framework aufzurufendende Businessfunktion festlegt und die Aufrufparameter enthält. Ergebnis des Aufrufs ist ein Objekt vom Typ Frontendresult. Abbildung 5: Kommunikationsverlauf im Framework Ohne das Command-Entwurfsmuster müsste man bei einer Änderung der Schnittstelle etwa die Einfügung neuer Parameter oder neuer Methoden die jeweiligen aufrufenden Instanzen formal an die neue Schnittstelle anpassen, weil es sonst zu technischen Problemen kommt, etwa weil sich der Sourcecode nicht mehr kompilieren lässt. Zusätzlich müssten im J2EE-Umfeld die Kommunikationsklassen für die von der Änderung betroffenen Enterprise Beans jedes Mal erneut erzeugt werden. So aber ändert sich nur der dynamische Inhalt der jeweiligen Requests oder Results, rein formal an der Schnittstelle aber nichts. Jeder Entwickler, der die Schnittstelle nutzt, muss deshalb 7

18 technisch an seinem Aufruf nichts ändern. Das bedeutet, dass die Entwicklung von Client und Server entzerrt wird. Weil die Schnittstellen stabil bleiben, ist das Erzeugen von EJB-Kommunikationsklassen bei Einsatz von TIBET in der Regel nur zu Projektbeginn und bei Einführung eines neuen Services erforderlich. In der Regel durchläuft ein Clientrequest alle Frameworkschichten. TIBET basiert zwar logisch auf einer Mehrschichtenarchitektur, ist technisch aber als Bussystem realisiert. Die Busarchitektur ermöglicht, dass jede Frameworkkomponente mit jeder anderen direkt kommunizieren kann. Das bedeutet, dass ein Clientrequest nicht zwangsläufig alle Frameworkkomponenten durchläuft, sondern dass ein Request Abkürzungen nehmen kann, was aus Performancegründen manchmal sinnvoll sein kann. So ist es zum Beispiel problemlos möglich, dass man aus der Sessionschicht unter Umgehung der Businessschicht auf direktem Wege den Databaseservice anspricht. Ablaufsteuerung und Kompetenzservice Die Ablaufsteuerung in TIBET wird nachfolgend in einem Beispiel erklärt. Eine Clientanfrage an TI- BET und das damit verbundene Aufrufen der Businessfunktion UserLogon läuft für einen RMI-Client wie folgt ab: Client/Gateway FrontEndRequest Session BusinessRequest Transaction Process KompetenzService BusinessFunction create() process(newfrontendrequest)() formalcheck() return: ok() dependencycheck() return: ok() create() add(newbusinessrequest)() KompetenzServiceRequest create(newbusinessrequest)() process(newkompetenzrequest)() dochecks() KompetenzServiceResult create() return: ok() commit() create() process(allbusinessrequests)() create() process(abusinessrequest)() BusinessResult dowork() create() return: newbusinessresult() return: allbusinessresults() FrontEndResult return: allbusinessresults() create(allbusinessresults)() return: newfrontendresult() Abbildung 6: Prinzipieller Verlauf des Aufrufs einer Businessfunktion vom Client aus Der Client erzeugt eine Benutzersession und startet diese. Um eine Anmeldung durchzuführen, erzeugt er einen Frontendrequest UserLogon und bestückt dessen Parameter Benutzername und 8

19 Password mit Daten vom Typ String. Anschließend sendet er diesen Request an die Methode process der Session. In der Session werden die vom Client bestückten Parameter formal geprüft, d.h. es wird geprüft, ob der Benutzername die vereinbarte Anzahl von Stellen besitzt und ob die dafür übergebene Zeichenkette gültige Zeichen enthält (zum Beispiel sind hier für den Benutzernamen keine Sonderzeichen erlaubt). Dasselbe wird für alle weiteren Parameter des Frontendrequests durchgeführt. Tritt bei einer Formalprüfung ein Fehler auf, so wird dieser in einem Fehlerarray vermerkt. Nach diesen Prüfungen erfolgt die Auswertung der aufgetretenen Fehler. Existieren Fehler, so wird das Fehlerarray an den Client gesendet. Es enthält eindeutige Fehlernummern, welche der Client dem Benutzer über seine Oberfläche in aufbereiteter Form anzeigen kann. Parameterprüfungen erfolgen per Definition auf dem Server. Nichtsdestotrotz kann der Client zuvor Eingabeprüfungen vornehmen, um das Ansprechverhalten der Anwendung zu verbessern (Minimierung der Netzwerkkommunikation). Generell gilt jedoch: Alles wird auf dem Server geprüft. Diese Regel trägt zur Stabilität des Servers bei. Liefert die formale Prüfung keine Fehler und genügen alle Parameter den Vereinbarungen, erfolgt die Prüfung auf Plausibilität. Hier kann etwa ein Check auf Parameterabhängigkeiten erfolgen. Für eine Riesterförderungsberechnung beispielsweise kann an dieser Stelle geprüft werden, ob der Benutzer die Förderung für den Ehepartner ausgewählt hat, obwohl er angibt, nicht verheiratet zu sein. Ein Bestehen all dieser Prüfungen überführt den Frontendrequest in einen Businessrequest. Die vom Frontendrequest dabei übernommenen Parameter werden in die Datentypen konvertiert, die am Server im fachlichen Code benutzt werden. Beispielsweise enthält ein Frontendrequest das Feld Kontonummer als java.lang.string. Im Businessrequest besitzt der Parameter Kontonummer dagegen den Datentyp tricept.data.kontonummer. Bei der Umwandlung der Datentypen können noch weitere Prüfungen erfolgen, bei einer Kontonummer etwa ein Check der Prüfziffer. Die Kombination aus Frontendrequest und Businessrequest bewirkt, dass der TIBET-Entwickler niemals dazu gezwungen ist, vom Client kommende Parameter auf Korrektheit der Datentypen oder auf NULL zu überprüfen. Diese Prüfungen werden vom Framework automatisch erledigt. Der Businessrequest wird nun in der Sessionschicht in einen so genannten Transactionrequest verpackt. Mithilfe dieses Requesttyps ist es möglich, auf einfache Weise im Framework zu navigieren. Der Transactionrequest weiß, welcher Request an welche Frameworkinstanz (Businesslayer, Service, ) geroutet werden muss. Ein Businessrequest wird von ihm an den Businesslayer weitergegeben. Das TIBET-Framework benutzt für die interne Kommunikation grundsätzlich Transactionrequests. Das Hinzufügen eines Businessrequests zu einem Transactionrequest bewirkt immer eine Autorisierungsprüfung durch den Kompetenzservice, der wiederum über die Kombination aus Request/Result wie folgt angesprochen wird. Ein neuer Transactionrequest wird erzeugt und mit einem Servicerequest für den Kompetenzservice bestückt. Anhand der Requestparameter überprüft der zur Session gehörige Kompetenzservice, ob der Benutzer für das Ausführen dieser Businessfunktion die notwendigen Berechtigungen besitzt. Im Fall der Anmeldung ist der Benutzer generell autorisiert. Es wird lediglich überprüft, ob für dieses Gateway in Zusammenhang mit dieser Session überhaupt ein Logon aufgerufen werden darf. Nach erfolgter positiver Autorisierungsprüfung wird der Businessrequest über den Processlayer an den Workflow und von dort weiter an die zum Request gehörige Businessfunktion gesendet. In der Businessfunktion UserLogon hat der Entwickler den eigentlichen fachlichen Code für eine Benutzeranmeldung implementiert. Zuerst werden die Requestparameter extrahiert. Um den Benutzer anzumelden, wird ein neuer Transactionrequest erzeugt und mit einem Request an den Kompetenzservice befüllt. Dieser Request wird dann im Kompetenzservice verarbeitet. Da es sich um einen Logonrequest handelt, wird dort über einen TransactionRequest mit Hilfe des Datenbankservices überprüft, ob Benutzername und Passwort gültig sind. Anschließend wird dieser Zugriff durch einen Request an den Journalservice protokolliert, der einen entsprechenden Eintrag in eine Log-Datei schreibt. 9

20 Beim eben beschriebenen Beispiel handelt es sich um einen rein lesenden Vorgang. Sollte während seiner Verarbeitung ein unerwarteter Fehler auftreten, so hätte das auf die Bestandsdaten des Systems keinen Einfluss, da nichts geändert wurde. Bei schreibenden Vorgängen dagegen muss beim Auftreten eines Fehlers sichergestellt werden, dass diese Daten nicht unzulässig geändert werden und so Inkonsistenzen entstehen. Um ein automatisiertes Rollback aller Änderungen durchführen zu können, verfügt das TIBET-Framework über interne Strukturen, über die die Aufrufhierarchie der Transactionrequests verwaltet und kontrolliert wird. So ist sichergestellt, dass bei Auftreten eines Fehlers alle betroffenen Komponenten ein Rollback durchführen und das System so wieder in den vorhergehenden Zustand gelangt. Nach dieser Gesamtübersicht über das TIBET-Framework beschreibt der folgende Abschnitt die für den Fachentwickler wichtigen Komponenten noch einmal genauer. Technische Beschreibung der Kernkomponenten Der Businesslayer Der TIBET-Businesslayer stellt einen Rahmen für Klassen und Methoden zur Verfügung, der die Entwicklung der eigentlichen Businesslogik wirkungsvoll unterstützt. Dieser Rahmen bildet in der Regel auch den Bereich, innerhalb dessen sich der Fachentwickler bewegt. Die vom Businesslayer bereitgestellten Klassen lassen sich grob in vier Kategorien einteilen:. Die Businessfunktionen, also die Implementierung der fachlichen Ablauflogik 2. Die Businessobjekte, d.h. die fachlichen Objekte und ihre Hilfsklassen 3. Die Objekte der Datenschicht 4. Managerobjekte 5. Objekte zur Unterstützung der Mehrsprachigkeit Die Businessfunktionen Eine Businessfunktion ist ein einzelner in einer TIBET-Session ausführbarer Prozess bzw. eine Verkettung von mehreren Businessfunktionen. Die Businessfunktion arbeitet auf Businessobjekten, kann aber auch je nach Bedarf andere Businessfunktionen aufrufen oder direkt mit Services im Hintergrund des Frameworks kommunizieren. Die Businessfunktion und alle von ihr angestoßenen Vorgänge sind transaktionsgesteuert. Ergebnis einer Businessfunktion ist immer ein Objekt von Typ Businessresult. Die Businessobjekte Die Businessobjekte machen die Zugriffe auf die Services im Hintergrund transparent. Anstatt mit Tabelleneinträgen in einer Datenbank oder am Host arbeitet man mit echten Objekten, die die Daten repräsentieren, zum Beispiel einer Person, einer Adresse oder einer Bestellung. Diese Objekte bieten Methoden zum Lesen oder zur Änderung der repräsentierten Daten und zur Speicherung bzw. Löschung des jeweiligen Objekts. Ein Businessobjekt kann zusätzlich auch fachliche Methoden implementieren. Zu jedem Businessobjekttyp existiert eine korrespondierende Factoryklasse, die letztendlich für das Erzeugen neuer Businessobjekte verantwortlich ist. Die zwischen einzelnen Objekttypen bestehenden Beziehungen können in benannten Relationen abgebildet werden. Jede dieser Relationen wird beschrieben durch ein spezielles Objekt. Mithilfe dieses Objekts kann die Relationfactory die gewünschte Relation erzeugen. Allein durch die Angabe des Relationsnamens ist es einem Businessobjekt so möglich, alle Objekte zu erzeugen, die mit ihm in der gewünschten Beziehung stehen. Beim Laden von Relationen stützt sich das Framework auf ein Repository, in dem die Relationsbeschreibungen abgelegt sind. Die Datenschicht In der Datenschicht existiert zu jeder der oben erwähnten Businessobjektklassen eine Businessdataklasse. Sie dient in erster Linie der reinen Datenhaltung. Zusammen mit der zugehörigen Factory ist sie aber auch für den eigentlichen Datenzugriff bzw. Zugriff auf die Services verantwortlich. 20