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

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

ObjectBridge Java Edition

ObjectBridge Java Edition ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

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

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

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

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

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

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

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

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de s & Servlet Integration Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Motivation Das Interface Stateful und Stateless s Programmierung einer Stateful

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

OTRS-TFS-Konnektor. Whitepaper. Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg

OTRS-TFS-Konnektor. Whitepaper. Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg OTRS-TFS-Konnektor Whitepaper Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg Tel: 0391 59801-0 Fax: 0391 59801-10 info@advanto-software.de Stand: Mai 2015 Inhaltsverzeichnis 1 Idee... 3 2

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

Jakarta Turbine Ein Open Source Framework fÿr Webanwendungen. KNF Kongre 2001 Henning P. Schmiedehausen

Jakarta Turbine Ein Open Source Framework fÿr Webanwendungen. KNF Kongre 2001 Henning P. Schmiedehausen <henning@apache.org> Jakarta Turbine Ein Open Source Framework fÿr Webanwendungen Henning P. Schmiedehausen Turbine - ein berblick Open Source unter Apache License 100% pure Java, Java 2 (JDK 1.2+) Servlet-basiertes

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

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

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2)

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2) Referat im Rahmen des Proseminars Internettechnologie WS 2007/2008 Thema: Web Services und serviceorientierte Architekturen (SOA) vorgelegt von: Intelligente Web Services sind für das Informationszeitalter,

Mehr

WebSphere Application Server Installation

WebSphere Application Server Installation WebSphere Application Server Installation und Administration Seminarunterlage Version: 3.04 Copyright Version 3.04 vom 16. Mai 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte

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

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Inhaltsverzeichnis. Zusammenfassung Wydler

Inhaltsverzeichnis. Zusammenfassung Wydler Inhaltsverzeichnis 1 Multitier Anwendungen... 2 2 J2EE Komponenten... 2 2.1 J2EE Design Patterns for Performance... 2 2.1.1 Design Patterns... 2 2.1.2 Session Façade... 2 2.1.3 Data Transfer Object (Value

Mehr

Microsoft SQL Server 2014 Express & EPLAN Plattform. EPLAN-Product-IT-Support / FOS / 2015 1

Microsoft SQL Server 2014 Express & EPLAN Plattform. EPLAN-Product-IT-Support / FOS / 2015 1 Microsoft SQL Server 2014 Express & EPLAN Plattform 1 Microsoft SQL Server & EPLAN Plattform Übersicht Download - Microsoft SQL Server 2014 Express mit Advances Services Installation - Microsoft SQL Server

Mehr

Java - Webapplikationen

Java - Webapplikationen Java - Webapplikationen Bestandteile (HTTP,, JSP) Aufbau (Model View Controller) Datenverwaltung (Java Beans, Sessions) Entwicklung (Projektstruktur, Sysdeoplugin für Eclipse) 17. Januar 2006 Jan Hatje

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

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

Existierende Systeme I Bibliotheken & Frameworks

Existierende Systeme I Bibliotheken & Frameworks Projektgruppe: Generierung von Webanwendungen aus visuellen Spezifikationen Existierende Systeme I Bibliotheken & Frameworks Von Christian Schneider Paderborn, den 18.06.2004 Übersicht Motivation Dynamische

Mehr

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

Mehr

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

Mehr

Systemvoraussetzungen für ConSol*CM Version 6.10.2 Architektur Überblick

Systemvoraussetzungen für ConSol*CM Version 6.10.2 Architektur Überblick Systemvoraussetzungen für ConSol*CM Version 6.10.2 Architektur Überblick ConSol*CM basiert auf einer Java EE Web-Architektur, bestehend aus den folgenden Kern-Komponenten: JEE Application Server für die

Mehr

inews: XML in der Praxis Konvertierung von Objekten nach XML und zurück Dr. St. Seefeld / INGTES AG

inews: XML in der Praxis Konvertierung von Objekten nach XML und zurück Dr. St. Seefeld / INGTES AG inews: XML in der Praxis Konvertierung von Objekten nach XML und zurück Dr. St. Seefeld / INGTES AG Objekte und XML Bei der Arbeit mit objektorientierten Programmiersprachen und XML kommt schnell der Wunsch

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

JDO Java Data Objects

JDO Java Data Objects JDO Java Data Objects Ralf Degner, Chief Consultant Ralf.Degner@poet.de Agenda POET Motivation Geschichte Einführung Architekturen FastObjects POET Gegründet 1993 Zwei Produktlinien esupplier Solutions:

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

... die Zeitschrift der DOAG-Mitglieder. News. Deutsche ORACLE-Anwendergruppe. Grid Computing

... die Zeitschrift der DOAG-Mitglieder. News. Deutsche ORACLE-Anwendergruppe. Grid Computing Deutsche ORACLE-Anwendergruppe News... die Zeitschrift der DOAG-Mitglieder Grid Computing ISSN 0936-0360 www.doag.org Q2/2005 Architektur einer mobilen Swing-Anwendung Autoren: Frank Kohmann, Stefan Götzl,

Mehr

EJB Beispiel. JEE Vorlesung 10. Ralf Gitzel ralf_gitzel@hotmail.de

EJB Beispiel. JEE Vorlesung 10. Ralf Gitzel ralf_gitzel@hotmail.de EJB Beispiel JEE Vorlesung 10 Ralf Gitzel ralf_gitzel@hotmail.de 1 Stundenkonzept Gemeinsame Übung Stoff der letzten Stunde wird gemeinsam in einem Beispiel umgesetzt Details werden nochmals erklärt bzw.

Mehr

Szenarien DPE Reporting

Szenarien DPE Reporting Szenarien DPE Reporting Das nachfolgende Dokument beschreibt mögliche Szenarien zur Generierung von Reports aus dem Delmia Process Engineer (DPE). 1 Einleitung Der DPE ist eine Lösung zur Prozeßplanung

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

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen Abgleich von Adressen und Terminen Stand Juni 2004 Was ist CAS genesisworld.exchange connect? Inhalt 1 Was ist CAS genesisworld.exchange connect?... 3 2 Systemvoraussetzungen... 5 2.1 Software...5 2.2

Mehr

Metadata Service Respository (MDS) - Sehen, lernen, verstehen!

Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Carsten Wiesbaum esentri AG Schlüsselworte Metadata Service Repository, MDS, Oracle Fusion Middleware Einleitung Früher oder später wird jeder

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

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

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

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

Leitfaden zur Installation von BitByters.Backup

Leitfaden zur Installation von BitByters.Backup Leitfaden zur Installation von BitByters.Backup Der BitByters.Backup - DASIService ist ein Tool mit dem Sie Ihre Datensicherung organisieren können. Es ist nicht nur ein reines Online- Sicherungstool,

Mehr

TriNotar. Administrationshandbuch. Copyright Wolters Kluwer Deutschland GmbH Build 013.100.0028 vom 18.03.2013

TriNotar. Administrationshandbuch. Copyright Wolters Kluwer Deutschland GmbH Build 013.100.0028 vom 18.03.2013 Copyright Wolters Kluwer Deutschland GmbH Build 013.100.0028 vom 18.03.2013 TriNotar Administrationshandbuch (Version mit Schwerpunkt auf Neuerungen Build 013.100.0028) Wolters Kluwer Deutschland GmbH

Mehr

5.5.8 Öffentliche und private Eigenschaften

5.5.8 Öffentliche und private Eigenschaften 5.5.8 Öffentliche und private Eigenschaften Schnittstellen vs. Implementierungen: Schnittstelle einer Klasse beschreibt, was eine Klasse leistet und wie sie benutzt werden kann, ohne dass ihre Implementierung

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

CARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH

CARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH CARM-Server Version 4.65 Users Guide APIS Informationstechnologien GmbH Einleitung... 1 Zugriff mit APIS IQ-Software... 1 Zugang konfigurieren... 1 Das CARM-Server-Menü... 1 Administration... 1 Remote-Konfiguration...

Mehr

INFORMATION MONITOR HSM SOFTWARE GMBH CLIENT-INSTALLATION

INFORMATION MONITOR HSM SOFTWARE GMBH CLIENT-INSTALLATION INFORMATION MONITOR HSM SOFTWARE GMBH CLIENT-INSTALLATION Allgemein Infomon bietet die Architektur für das Informations-Monitoring in einer Windows- Topologie. Die Serverfunktionalität wird in einer IIS-Umgebung

Mehr

Überblick GOF Version 1.0.1 - Effizienter Implementieren durch Konfigurieren - Dokumentversion 1.0.8

Überblick GOF Version 1.0.1 - Effizienter Implementieren durch Konfigurieren - Dokumentversion 1.0.8 Überblick GOF Version 1.0.1 - Effizienter Implementieren durch Konfigurieren - Dokumentversion 1.0.8 Agenda Vorstellungsrunde Grundlegende Ansätze der Generic Objekte Frameworks (GOF) Einsatzmöglichkeiten

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

WDAV - webbasierte Diebstahlsanzeigenverwaltung

WDAV - webbasierte Diebstahlsanzeigenverwaltung WDAV - webbasierte Diebstahlsanzeigenverwaltung Große deutsche Baumarktkette Webbasierte Verwaltung von Diebstahlsanzeigen Kunde Der Kunde ist ein namhafter Vertreter im Bereich der Baumärkte mit über

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

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

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

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen Java Beans Enterprise Java Beans Eine kurze Einführung in die Welt der Bohnen Java Beans Einführung Stefan Sauer Was ist ein Java Bean? Beans sind Komponenten. Einmal schreiben Überall wiederverwerten

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

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

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

Jump Project. Softwarelösungen für professionelles Projektmanagement

Jump Project. Softwarelösungen für professionelles Projektmanagement Jump Project Softwarelösungen für professionelles Projektmanagement Jump Project Office Übersichtliche Dokumentenstruktur und schneller Zugriff auf alle wichtigen Funktionen. Steuern Sie Ihre Projekte

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

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

Visendo SMTP Extender

Visendo SMTP Extender Inhalt Einleitung... 2 1. Aktivieren und Konfigurieren des IIS SMTP Servers... 2 2. Installation des SMTP Extenders... 6 3. Konfiguration... 7 3.1 Konten... 7 3.2 Dienst... 9 3.3 Erweitert... 11 3.4 Lizenzierung

Mehr

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API PHP-Framework zur Anbindung an die plenty API Inhaltsverzeichnis 1 Kurzbeschreibung...3 2 Integration...4 3 Möglichkeiten...5 3.1 Artikel...5 3.2 Aufträge...5 3.3 Kunden...5 4 Interne Funktionsweise...7

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

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

Whitepaper. bi-cube SSO SSO in einer Terminal Umgebung. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g

Whitepaper. bi-cube SSO SSO in einer Terminal Umgebung. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Whitepaper bi-cube SSO T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Inhalt 1 DIE SITUATION...3 2 ZIELSTELLUNG...4 3 VORAUSSETZUNG...5 4 ARCHITEKTUR DER LÖSUNG...6 4.1 Biometrische

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

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

Datenmanagement in Android-Apps. 16. Mai 2013

Datenmanagement in Android-Apps. 16. Mai 2013 Datenmanagement in Android-Apps 16. Mai 2013 Überblick Strukturierung von datenorientierten Android-Apps Schichtenarchitektur Möglichkeiten der Datenhaltung: in Dateien, die auf der SDCard liegen in einer

Mehr

Java Pet Store vs..net Pet Shop. Seminar Software-Entwurf Jörg Eggermann

Java Pet Store vs..net Pet Shop. Seminar Software-Entwurf Jörg Eggermann <Eggermann@hosterme.de> Java Pet Store vs..net Pet Shop Seminar Software-Entwurf Jörg Eggermann Gliederung Motivation Einordnung Einschub - Enterprise Java Beans Anwendungen in der Übersicht Java Pet Store.NET

Mehr

Java Frameworks im Vergleich - ADF vs. Grails vs. Spring

Java Frameworks im Vergleich - ADF vs. Grails vs. Spring Java Frameworks im Vergleich - ADF vs. Grails vs. Spring Frank Szilinski esentri software GmbH Karlsruhe Schlüsselworte: ADF, Java, JEE, JSF, Grails, Spring, Open Source, Rapid Application Development

Mehr

Wurm-Lizenzserver Internetverbindung über Port 80 (http) Bei aktiver Firewall muss die Ausnahme für die URL http://ls.wurm.de eingerichtet werden

Wurm-Lizenzserver Internetverbindung über Port 80 (http) Bei aktiver Firewall muss die Ausnahme für die URL http://ls.wurm.de eingerichtet werden Der Wurm Lizenzmanager Der Wurm Lizenzmanager dient als Lizenzserver für Software der Firma Wurm. Die Installation erfolgt auf einem Rechner innerhalb des jeweiligen Intranets. Dadurch kann auf separate

Mehr

Whitepaper Walkyre Enterprise Resource Manangement

Whitepaper Walkyre Enterprise Resource Manangement Whitepaper Walkyre Enterprise Resource Management Seite 1 Whitepaper Walkyre Enterprise Resource Manangement Stand 15.11.2004 Inhalt 1. Hinweis... 2 2. Grundsätzliches zur Funktionalität... 3 3. Der Walkyre-Client...

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher 729631 745097 736477 745011 741297 Inhalt Schlussbewertung... 3 Bewertung

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

TKeasy: Die unternehmensweite Java-Enterprise- Architektur der Techniker Krankenkasse

TKeasy: Die unternehmensweite Java-Enterprise- Architektur der Techniker Krankenkasse TKeasy: Die unternehmensweite Java-Enterprise- Architektur der Techniker Krankenkasse Universität Hamburg, 8.11.2011 Ralf Degner, Techniker Krankenkasse Überblick Voraussetzungen, Ziele, Entscheidungen

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

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

Dreamwap. Systemanalyse

Dreamwap. Systemanalyse Dreamwap Systemanalyse Änderungskontrolle Version Datum Name Bemerkung 0.1 15.7.2000 P. Troxler Initialversion 0.2 16.7.2000 P. Troxler Neue Tabelle: Kap. 2.1. Vgl. Datenbank Tabellen 0.3 18.7.2000 P.

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

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

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

Wie hat es Microsoft Consulting gemacht.

Wie hat es Microsoft Consulting gemacht. Wie hat es Microsoft Consulting gemacht. Folge 1: Projektübersicht Leider kann ich den Kunden und das Projekt nicht nennen, da es eine Vertraulichkeitsvereinbarung mit dem Kunden gibt und wir somit nicht

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

Hibernate Das Praxisbuch für Entwickler

Hibernate Das Praxisbuch für Entwickler Sebastian Hennebrüder 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Hibernate Das Praxisbuch für Entwickler Galileo

Mehr

UI-Architekturen mit JSF

UI-Architekturen mit JSF www.jsf-academy.com UI-Architekturen mit JSF - JSF ist mehr als nur Syntax - Copyright 2011, Andy Bosch, www.jsf-academy.com Slide 1 Agenda Warum reden wir überhaupt über UI-Architektur? Technologien und

Mehr

Online Banking System

Online Banking System Online Banking System Pflichtenheft im Rahmen des WI-Praktikum bei Thomas M. Lange Fachhochschule Giessen-Friedberg Fachbereich MNI Studiengang Informatik Erstellt von: Eugen Riske Yueksel Korkmaz Alper

Mehr

Java EE Projektseminar

Java EE Projektseminar Java EE Projektseminar Daniel Alberts & Sonja Subicin Sprachliche Informationsverarbeitung Universität zu Köln Sommersemester 2010 Sitzung Organisatorisches zum Seminar Java EE Projektplanung Defi nition

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

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013 GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr