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

Größe: px
Ab Seite anzeigen:

Download "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

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Java Enterprise Architekturen Willkommen in der Realität

Java Enterprise Architekturen Willkommen in der Realität Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

ORACLE Business Components for Java (BC4J) Marco Grawunder

ORACLE Business Components for Java (BC4J) Marco Grawunder ORACLE Business Components for Java (BC4J) Marco Grawunder Gliederung 2 Probleme von J2EE/EJB J2EE-Pattern Lösungsansatz: BC4J Architektur einer BC4J-Anwendung Komponenten Entity Objects View Objects Application

Mehr

Warum EJB Technologie (1)?

Warum EJB Technologie (1)? Datenbanken und Informationssysteme 2 SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn Datenbanken und Informationssysteme 2 - Prof. Dr. Stefan Böttcher - SS 2004 Folie EJB - 1 Warum EJB Technologie

Mehr

Analyse, Design, Implementierung Implementierung administrativer Funktionen in ein bestehendes webbasierendes Vertragsverwaltungssystem.

Analyse, Design, Implementierung Implementierung administrativer Funktionen in ein bestehendes webbasierendes Vertragsverwaltungssystem. Nachrichtenservice rubbergram Datum 10/2014 - Web-Applikation zum Versand von Einwegnachrichten rubbergram.com Social Web Idee, Design, Implementierung Einfache Möglichkeit zum Versand von Einwegnachrichten,

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

ITS Business Integrator

ITS Business Integrator IBI Weboberfläche zur Datenintegration Location Viewer Asset-Management Smallworld GIS Monitoring Planung Bau Wartung Entstörung Integration Der ITS Business Integrator (IBI) ist eine offene Plattform

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

JE Web Services. Hinweise. Beschreibung. Doku.-Version: 1.0 Letzte Änderung: 02.02.2011

JE Web Services. Hinweise. Beschreibung. Doku.-Version: 1.0 Letzte Änderung: 02.02.2011 Beschreibung Hinweise Doku.-Version: 1.0 Letzte Änderung: 02.02.2011 http://www.jacob-computer.de/kontakt.html software@jacob-elektronik.de Inhaltsverzeichnis 1. Inhaltsverzeichnis Hinweise... 1 1. Inhaltsverzeichnis...

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

Integrating Architecture

Integrating Architecture Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Vorstellung und Einführung Ein beliebiger Zeitpunkt in einem beliebigen Unternehmen

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt -

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt - Herzlich Willkommen! Mit Java ins Web - eine praxisnahe Übersicht 1 Wer bin ich? Michael Behrendt, 21, Nürnberg kurzer Lebenslauf: 1991 Erster Rechner: Commodore C128 1995 Ausbildung zum Datenverarbeitungskaufmann

Mehr

Hochschule Darmstadt Fachbereich Informatik

Hochschule Darmstadt Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik 6.3 Systemarchitektur 430 6.3 Systemarchitektur Drei Schichten Architektur Die "Standardtechniken" des Software-Engineering sind auch auf die Architektur einer

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

Übungsaufgabe Transaktion als Middleware

Übungsaufgabe Transaktion als Middleware Übungsaufgabe Transaktion als Middleware und Java Persistence API Client/Server Abstraktes Komponentenmodell Entscheidende Punkte Erweiterung der Invoke-Methode Context-Verwaltung Transaktionsbehandlung

Mehr

Architektur einer GDI: Service-oriented Architecture (SOA)

Architektur einer GDI: Service-oriented Architecture (SOA) Modul 6: Voraussetzungen einer GDI Vertiefende Dokumente I Stand: 24.01.2012 Architektur einer GDI: Service-oriented Architecture (SOA) Zu den Hauptargumenten für eine Geodateninfrastruktur zählen unter

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Der Java Server beinhaltet Container für EJB, Servlet und JSP, darüber hinaus unterstützt er diejee 1.3 Version.

Der Java Server beinhaltet Container für EJB, Servlet und JSP, darüber hinaus unterstützt er diejee 1.3 Version. hehuvlfkw Oracle 9iApplication Server (9iAS) fasst in einem einzigen integrierten Produkt alle Middleware-Funktionen zusammen, die bisher nur mit mehreren Produkten unterschiedlicher Anbieter erreicht

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Rinke Solutions - Projects

Rinke Solutions - Projects Rinke Solutions - Projects (Stand: Juli 07) 01/07... Internet-Portal / ISP 02/06 12/06 Internet-Portal 01/06 03/05 Internet-Portal EAI (Integration / Optimierung der Geschäftssysteme). Zur besseren Integration

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

3... SAP NetWeaver Developer Studio: Schritt für Schritt zur Beispielanwendung... 119

3... SAP NetWeaver Developer Studio: Schritt für Schritt zur Beispielanwendung... 119 1... SAP NetWeaver... 25 1.1... Plattform für die Enterprise Service-Oriented Architecture... 26... 1.1.1... Enterprise-SOA-Definition... 26... 1.1.2... Vorteile einer serviceorientierten Architektur...

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Enterprise Edition Teil 4 Schnittstellen el0100 copyright W. G. Spruth, wgs 04-10

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Kommunikationsübersicht XIMA FORMCYCLE Inhaltsverzeichnis

Kommunikationsübersicht XIMA FORMCYCLE Inhaltsverzeichnis Kommunikationsübersicht Inhaltsverzeichnis Kommunikation bei Einsatz eines MasterServer... 2 Installation im... 2 Installation in der... 3 Kommunikation bei Einsatz eines MasterServer und FrontendServer...

Mehr

Mehmet-Oktay Tugan Gliederung Grundsätzliches und Begriffserklärung Einleitung Geschichte Architektur Funktionalitätsumfang Hauptunterstützungen Zusammenfassung Grundsätzliches WebSphere ist ein Entwicklungstool

Mehr

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Middleware Versuch einer Einleitung Host dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Mainframe enthält vollständige Anwendung Typ. COBOL, C Mainframe contd.! Nachteile! Mainframe ist teuer

Mehr

Bridging the Gap between the Enterprise and You. Who s the JBoss now?

Bridging the Gap between the Enterprise and You. Who s the JBoss now? or Who s the JBoss now? Patrick Hof (patrick.hof@redteam-pentesting.de) Jens Liebchen (jens.liebchen@redteam-pentesting.de) RedTeam Pentesting GmbH http://www.redteam-pentesting.de 16. DFN-Cert Workshop

Mehr

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany Enterprise JavaBeans Einführung Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Inhalt Allgemeines Motivation Rollen Aufbau einer EJB Arten von Beans Enterprise JavaBeans

Mehr

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH Erfahrungen und Erkenntnisse Klaus Richarz, HBT GmbH Java Enterprise Edition 5.0 JBoss Seam Konsequenzen für Realisierung Qualitätssicherung Build & Deployment Fazit & Empfehlungen JBoss Seam in Projekten,

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Mufid Sulaiman mufidsulaiman@web.de

Mufid Sulaiman mufidsulaiman@web.de Mufid Sulaiman mufidsulaiman@web.de Überblick Frameworks Applikationsentwicklung mit Frameworks Komponentenbasierte Frameworks Einführung in Enterprise JavaBean Einführung in SanFrancisco Vergleich Enterprise

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

// Mehr, als Sie erwarten //

// Mehr, als Sie erwarten // // Mehr, als Sie erwarten // // Unitek entwickelt seit 1988 innovative Software, mitten in der Altstadt von Zürich. Gegründet von ETH-Absolventen, hat Unitek dank massvollem Wachstum, anhaltender Begeisterung

Mehr

Technische Produktinformation: Active Directory- Management in bi-cube

Technische Produktinformation: Active Directory- Management in bi-cube Inhalt: 1 bi-cube -FEATURES ACTIVE DIRECTORY... 2 2 DAS SYSTEMKONZEPT... 3 3 WAS SIND ADOC UND ECDOC?... 3 4 DIE WICHTIGSTEN FUNKTIONEN IM ÜBERBLICK... 5 4.1 Verwaltung der Strukturdaten... 5 4.2 Verwaltung

Mehr

Application Development Framework (ADF) Teil 1: Überblick Autor(en): Kersten Mebus, Jürgen Menge Oracle Deutschland GmbH

Application Development Framework (ADF) Teil 1: Überblick Autor(en): Kersten Mebus, Jürgen Menge Oracle Deutschland GmbH Application Development Framework (ADF) Teil 1: Überblick Autor(en): Kersten Mebus, Jürgen Menge Oracle Deutschland GmbH Die Entwicklung von Java/J2EE Anwendungen wird durch den Einsatz von Design Pattern

Mehr

SOA Einsatzmöglichkeiten und Voraussetzungen unter Nutzengesichtspunkten

SOA Einsatzmöglichkeiten und Voraussetzungen unter Nutzengesichtspunkten SOA Einsatzmöglichkeiten und Voraussetzungen unter Nutzengesichtspunkten Zusammenfassung (Fast) Alles Wissen der Fachbereiche (Regelwerke, Formelwerke, Produktstrukturen, Prozessabläufe etc.) ist heute

Mehr

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen IN-Q-My Title Company (Name) / 1 Agenda Firmenübersicht ebusiness Evolution InQMy Application Server Architektur Zusammenfassung

Mehr

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht.

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht. Technisches Design Inhalt Design Übersicht Menü und DispatcherServlet DWR Servlet Viewer Servlets Controllers Managers Sicherheit Anwendung Architektur Component Diagram Deployment Diagram Komponente Sequence

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Bridging the Gap between the Enterprise and You. Who s the JBoss now?

Bridging the Gap between the Enterprise and You. Who s the JBoss now? or Who s the JBoss now? Patrick Hof (patrick.hof@redteam-pentesting.de) Jens Liebchen (jens.liebchen@redteam-pentesting.de) RedTeam Pentesting GmbH http://www.redteam-pentesting.de FrOSCon 2009 22./23.

Mehr

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

Transaktionsmonitore und Applikationsserver

Transaktionsmonitore und Applikationsserver Transaktionsmonitore und Applikationsserver Marc Monecke monecke@informatik.uni-siegen.de Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D-57068 Siegen 13. Juni 2003

Mehr

Enterprise Java Beans

Enterprise Java Beans Enterprise Java Beans Beispiel Minibank nur: Kunde, Konto, Überweisung personen.person Attributes Name:String Vorname:String überweisungen.überweisung Attributes Verwendungszweck:String Datum:Date betrag:integer

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

Version 4.4. security.manager. Systemvoraussetzungen Version 4.4 security.manager Systemvoraussetzungen Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

Karl Kessler, Peter Tillert, Panayot Dobrikov Java-Programmierung mit dem SAP Web Application Server

Karl Kessler, Peter Tillert, Panayot Dobrikov Java-Programmierung mit dem SAP Web Application Server 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Karl Kessler, Peter Tillert, Panayot Dobrikov Java-Programmierung

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Architekturen. DB-Anwendungen: Aufgaben. Aufteilung der Funktionen. ƒ Datenbankanwendungen

Architekturen. DB-Anwendungen: Aufgaben. Aufteilung der Funktionen. ƒ Datenbankanwendungen Architekturen ƒ Datenbankanwendungen Aufgaben und Komponenten Aufteilung ƒ Architektur Web-basierter Anwendungen HTTP-basierte Architekturen Applet-basierte Architekturen Vorlesung Internet-Datenbanken

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Anwendung eines Enterprise Java Beans

Anwendung eines Enterprise Java Beans Anwendung eines Enterprise Java Beans EJB Server EJB Container Remote Interface Home Interface EJB Object Der EJB Container kümmert sich um die Kommunikation des Beans mit anderen Komponenten, wobei er

Mehr

JSP und Servlet Programmierung

JSP und Servlet Programmierung Seminarunterlage Version: 5.02 Copyright Version 5.02 vom 1. März 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Anleitung zum Online Banking

Anleitung zum Online Banking Anleitung zum Online Banking Diese Anleitung beschreibt das Vorgehen zur Installation und Konfiguration von Online Banking unter Jack. Um das Online Banking in Jack nutzen zu können, müssen Sie das entsprechende

Mehr

anaptecs JEAF Plattform JEAF Developer Guide

anaptecs JEAF Plattform JEAF Developer Guide anaptecs JEAF Plattform JEAF Developer Guide : JEAF Framework Die technische Grundlage für Applikationen auf Basis der JEAF Plattform bildet das JEAF Framework. Dabei handelt es sich um ein leichtgewichtiges

Mehr

Kurzübersicht Diplomarbeit

Kurzübersicht Diplomarbeit Thema: Konzeption und Implementierung einer Basisarchitektur für eine regelbasierte Client-/Server-Anwendung für das Workflow Management Ort: Bundesamte für Wehrtechnik und Beschaffung, Wehrtechnische

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

open to your business

open to your business open to your business oss dac (document and appoval center) der fahrtenschreiber zu ihrer produktplatzierung oss dac einführung inhalte (stand januar 2014) aktuelle gegebenheiten und oss dac S. 2 grundsätzliches

Mehr

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001 V3.05.001 MVB3 Admin-Dokumentation Einrichten eines Servers für MVB3 ab Version 3.5 Inhalt Organisatorische Voraussetzungen... 1 Technische Voraussetzungen... 1 Konfiguration des Servers... 1 1. Komponenten

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum CORVUS by init.at... 3 3 Ihre Vorteile durch CORVUS... 3 4 CORVUS Features... 4

Mehr

Ein mobiler Electronic Program Guide für Android

Ein mobiler Electronic Program Guide für Android Whitepaper Telekommunikation Ein mobiler Electronic Program Guide für Android Prototyp für Android Apps 2011 SYRACOM AG 1 Einleitung Apps Anwendungen für mobile Geräte sind derzeit in aller Munde. Durch

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Enterprise JavaBeans

Enterprise JavaBeans Enterprise JavaBeans Sebastian Pipping 18. Dezember 2006 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. Teil I J2EE J2EE Was ist J2EE? Was ist J2EE?

Mehr

Administration und Konfiguration für JBOSS

Administration und Konfiguration für JBOSS Administration und Konfiguration für JBOSS Seminarunterlage Version: 2.03 Version 2.03 vom 7. Mai 2012 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards:

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards: MSP SSO Portalübergreifendes Single Sign-on Für das Abwickeln von Online- Geschäftsprozessen ist es wichtig, sein Gegenüber zu kennen. Das gilt sowohl für den Kunden als auch den Betreiber des Online-

Mehr