Masterarbeit Dynamische Softwarekomponentenverwaltung einer Kommunikationsmiddleware

Größe: px
Ab Seite anzeigen:

Download "Masterarbeit Dynamische Softwarekomponentenverwaltung einer Kommunikationsmiddleware"

Transkript

1 Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Masterarbeit Dynamische Softwarekomponentenverwaltung einer Kommunikationsmiddleware vorgelegt von: Aalbrecht Alby Irawan eingereicht am: geboren am: Studiengang: Studienrichtung: Ingenieurinformatik Multimediale Informations- und Kommunikationssysteme Anfertigung im Fachgebiet: Kommunikationsnetze Fakultät für Elektrotechnik und Informationstechnik Verantwortlicher Professor: Wissenschaftlicher Betreuer: Prof. Dr. rer. nat. Jochen Seitz Dipl.-Ing. Karsten Renhak

2 Kurzfassung Ziel dieser Masterarbeit ist die Entstehung eines Verwaltungssystem zur automatischen individuellen An- und Abmeldung verschiedener Gateways. Die Gateways sollen sich zur Laufzeit dynamisch im System registrieren können, ohne das Gesamtsystem neugestartet werden zu müssen. Demnach gliedert sich die Arbeit in 2 Teile. Erstens in die Recherche über verschiedene Verfahren zum dynamischen Komponentenmodell und die Unterschiede zwischen relationale Datenbankschnittstelle und objektrelationale Datenbankschnittstelle. Zweitens in die Konzeption und Umsetzung eines optimalen dynamischen Software- Verwaltungssystems. Im ersten Teil werden 4 Ansätze recherchiert: CORBA, Jini, EJB, und OSGi. Anhand ausgewählter Kriterien, wie z.b. Plattformunabhänigkeit, Kapselung und Versionierung werden sie anschließend miteinander verglichen. OSGi wird letzendlich gewählt, da OSGi die neueste und optimalste Variante ist. Die Vor- und Nachteile von verschiedenen Datenbankschnitstellen werden auch berücksichtigt. Eine relationale Datenbank ist leichter zu realisieren, aber bei einer objektorientierten Progammierung hat objektrelationale Datenbank einen klaren Vorsprung. Mit Hilfe von einer Objekt Relational Mapping- (ORM)Software, wie z.b. EclipseLink oder Hibernate sei dies kein großes Problem mehr. Im zweiten Teil wird ein Konzept zur Verwaltung verschiedener Kommunkationsgateways erläutert. Hierbei stellt ein zentrales Element der Middleware einerseits eine Schnittstelle zum Assistenzsystem zur Verfügung und andererseits übernimmt dieses Modul die Verwaltung der einzelnen Gateways. Die Kommunikation zwischen der zentralen Schnittstelle und den Kommunikationsgateways soll ausschließlich über die vorhandene Message Oriented Middleware (MOM), in diesem Fall Advanced Message Queuing Protocol (AMQP), erfolgen. Die notwendige Speicherung vorhandener Informationen durch das zentrale Modul soll auf Basis der objektrelationalen Datenbankschnittstelle erfolgen.

3 Abstract Goal of this thesis is the development of a management system for automatic individual registration and deregistration of different gateways. The gateways can register dynamically at runtime without having the entire system to be restarted. Accordingly, the work is divided into 2 parts. First, in the research on various methods for dynamic component models, and the differences between relational database interface and object-relational database interface. Second, in the design and implementation of an optimal dynamic software management system. In the first part 4 approaches are investigated: CORBA, Jini, EJB and OSGi. They are compared based on selected criteria, such as platform independency, encapsulation and versioning. OSGi is ultimately chosen because OSGi is the latest and the most optimal variant. The pros and cons of various database interface are also be considered. A relational database is easier to implement, but in such an object-oriented programming, object-relational database has a clear lead. Using an Object Relational Mapping (ORM) software, e.g. EclipseLink or Hibernate, there shouldn t be any big problem. The second part is an approach to managing various communication gateways. Therefore, a core element of the middleware provides an interface for the assistance system and at the other hand it watches over the individual gateways. The communication between the central interface and the communication gateways is only via the existing Message Oriented Middleware (MOM), in this case Advanced Message Queuing Protocol (AMQP). The required storage of existing information by the central module should be based on the object-relational database interface.

4 Inhaltsverzeichnis i Inhaltsverzeichnis 1 Einleitung Motivation Aufgabenstellung Dynamische Verwaltung von Softwarekomponenten CORBA JINI EJB OSGi Vergleich der Ansätze Datenbankschnittstelle Relationales Datenbanksystem Objektrelationales Datenbanksystem Java Datenbank Connectivity Java Persistence Query Language Konzeption eines dynamischen Software-Verwaltungssystems Anforderungen an das Software-Verwaltungssystem Struktur des Verwaltungssystems Umsetzung des Konzepts RabbitMQ EclipseLink Apache Derby OSGi Zusammenfassung/Ausblick Zusammenfassung der Ergebnisse Ausblick auf Erweiterungen

5 Inhaltsverzeichnis ii Literaturverzeichnis 41 Abbildungsverzeichnis 43 Tabellenverzeichnis 44 Abkürzungsverzeichnis und Formelzeichen 45 Thesen zur Masterarbeit 47 Erklärung 48

6 1 Einleitung 1 1 Einleitung 1.1 Motivation Das Fachgebiet Kommunikationsnetze befasst sich mit Infrastrukturen und Anwendungen für Assistenzsysteme zur Unterstützung des täglichen Lebens. Um die Qualität und vor allem die Akzeptanz des Assistenzsystems zu erhöhen, ist es von Vorteil, möglichst viele Nutzungsmöglichkeiten anzubieten. Seit mehr als 20 Jahren haben sich Ingenieure damit beschäftigt, ein monolitisches System mit einem Komponentenmodell zu ersetzen. Im Gegensatz zum monolitischen System bietet ein modulares System viele Nutzungsmöglichkeiten. So ist es leicht, andere Module hinzuzufügen. und entsprechend können alte Module gegen neue Module ausgetauscht werden. Außerdem ist ein bestehendes Modul in einem anderen System wiederverwendbar. Hierdurch können die Entwicklungskosten sinken und schnellere Produktzyklen erreicht werden. Dieses Modell kann allerdings auch zu neuen Problemen führen, vorallem bei der Sicherheit und Kompatibilität. Da die Ressourcen jetzt für alle zugreifbar sind, muss das System gegen Angreifer geschützt sein. Eine Authentifizierung ist erforderlich, sodass kein unauthorisierter Teilnehmer den Zustand des Systems verändern kann. Im Markt finden sich viele verschiedene Realisierungen einer Spezifikation. Oft gibt es Probleme bei der Kommunikation, sodass die Interoperabilität nicht gewährleistet werden kann. Diese Inkompatibilität kann auch innerhalb einer Software gleichen Herstellers vorkommen, z.b. wenn ein Client und ein Server andere Versionen der Software benutzen. Ein anderer Aspekt, der eine große Rolle spielt, ist die Dynamik. Bei früheren Systemen muss das System heruntergefahren und neugestartet werden, wenn sich eine Komponente ändert, denn sonst ist der Name oder die Adresse eines Objekt für die anderen Komponenten unbekannt. Erst nach dem Neustart wird eine Zusammenarbeit ermöglicht. Deshalb soll das Verwaltungssystem in dieser Masterarbeit die dynamische An- und Abmeldung einer Komponente unterstützen. Eine Datenbank ist eine Sammlung von Informationen wie z.b. Texte, Zahlen und Bilder. Sie ist so organisiert, dass sie leicht zugänglich und zuzuordnen ist. Eine Da-

7 1 Einleitung 2 tenbank kann nach ihrem organisatorischen Ansatz eingestuft werden. Der häufigste Ansatz ist die relationale Datenbank, auch tabellarische Datenbank genannt. Sie wird durch ihre Attribute (Spalten) und ihre Tupel (Zeilen) charakterisiert. Eine objektrelationale Datenbank hingegen wird mit den Daten der Objekte in Klassen und Unterklassen definiert. Eine relationale Datenbank ist sehr leicht zu realisieren, aber bei objektorientierter Programmierung ist sie kaum nutzbar. Im Gegensatz dazu ist eine objektrelationale Datenbank relativ schwierig zu realisieren, aber sie wurde genau für objektorientierte Programmierung entwickelt. Deshalb soll man eine Schnittstelle anwenden, welche die Zuordnung und die Übertragung von Daten der Objekte zu einer tabellarischen Datenbank ermöglicht, sogenannte Object-Relational-Mapping (ORM)-Software. 1.2 Aufgabenstellung Eine am Fachgebiet Kommunikationsnetze entwickelte Kommunikationsmiddleware für Assistenzsysteme wird eingesetzt, um möglichst viele verschiedene Kommunikationsarten und -technologien mit dem Assistenzsystem zu nutzen. Diese Kommunikationsmiddleware verwendet unter anderem eine nachrichtenbasierte Middleware (Message Oriented Middleware - MOM) zur internen Kommunikation. Die Anbindung der verschiedenen Kommunikationssysteme erfolgt durch unabhängige Gateways, die über eine MOM mit der Kommunikationsschnittstelle des Assistenzsystems verbunden sind. Im Rahmen der Erweiterung und Pflege der Kommunikationsmiddleware soll ein Verwaltungssystem zur automatischen individuellen An- und Abmeldung der Gateways entstehen. Um dieses Ziel zu realisieren, sind folgende Arbeitsschritte erforderlich: Recherche zu Verfahren und Ansätzen zur dynamischen Verwaltung von Softwarekomponenten Recherche zu objektrelationalen Java-Datenbankschnittstellen Konzeption und Umsetzung eines dynamischen Software-Verwaltungssystems Abbildung 1.1 stellt eine mögliche Realisierung eines solchen Verwaltungssystems dar. Hierbei stellt ein zentrales Element der Middleware einerseits eine Schnittstelle zum Assistenzsystem zur Verfügung. Und andererseits übernimmt dieses Modul die Verwaltung der einzelnen Gateways. Die Kommunikation zwischen der zentralen Schnittstelle

8 1 Einleitung 3 Abbildung 1.1: Beispiel für Realisierung eines Verwaltungssystems und den Kommunikationsgateways soll ausschließlich über einen AMQP-Server erfolgen. Die Verwaltung des Gateways ist weiterhin auf Basis der übermittelten Metadaten in XML-Format umzusetzen. Die Speicherung vorhandener Informationen durch das zentrale Modul soll auf Basis einer objektrelationalen Datenbankschnittstelle erfolgen.

9 2 Dynamische Verwaltung von Softwarekomponenten 4 2 Dynamische Verwaltung von Softwarekomponenten Dieses Kapitel befasst sich mit verschiedenen Ansätzen, welche die dynamische Verwaltung von Softwarekomponenten ermöglichen sollen. Die Ansätze werden nach nach Erscheinungsjahr aufgelistet. 2.1 CORBA Common Object Request Broker Architecture (CORBA) ist eine Spezifikation, die 1991 zum ersten Mal von der Object Management Group (OMG) verabschiedet wurde. Federführend bei der Entwicklung dieses Standards sind die Unternehmen Sun und IBM [Lan02]. Weil CORBA nur eine Spezifikation ist, gibt es im Markt viele herstellerabhängige Anwendungen, die CORBA implementieren. Dennoch soll mittels Interface Definition Language (IDL) Interoperabilität und Sprachunabhängigkeit gewährleistet werden. Anders als herkömmliche Programmiersprachen wie C, COBOL, Python, C++ oder Java ist die IDL eine reine Spezifikationssprache. Ein mit der CORBA-IDL erzeugtes Interface wird in einem normalen Text-File abgespeichert und muss in die jeweils verwendete Programmiersprache übersetzt werden. Diese Übersetzung wird von den IDL-Compilern im ORB übernommen. Da dieser Compiler und dessen Übersetzung standardisiert ist, sollen Clients und Server verschiedener Hersteller problemlos kommunizieren können, solange keine herstellerspezifische Erweiterungen installiert werden. Grundlage für die Spezifikation ist die sogenannte Object Management Architecture (OMA), die aus fünf Komponenten besteht: Object Request Broker (ORB) Common Object Service (COS) Common Facilities

10 2 Dynamische Verwaltung von Softwarekomponenten 5 Domain Objects Application Objects ORB steht im Zentrum. Dieser funktioniert als ein Broker, der Kommunikation und Interaktion von verschiedenen und entfernten Objekten verbindet. Der IDL Compiler im ORB erzeugt ein Server-Skeleton und einen Clienten-Stub. Diese fungieren als Proxy des Clients bzw. Servers. Wenn ein Client eine Server-Methode aufruft, übernimmt der Stub das Verpacken der Parameter und gibt den Aufruf an den ORB weiter. Dieser ist dafür zuständig, das Server-Objekt zu lokalisieren und den Aufruf weiterzuleiten. Die Rückgabe des Ergebnisses geschieht in umgekehrter Richtung analog. Da nur Parameter (input und output) benötigt werden, bleibt das Objekt vor der Außenwelt versteckt. Dieser Ablauf wird in Abbildung 2.1 veranschaulicht. Abbildung 2.1: Methodenaufruf bei CORBA [Haa01] CORBA ermöglicht auch dynamische Methodenaufrufe. Während bei einem statischen Aufruf der Client die Schnittstellendefinition des Servers kennen muss, können mit Hilfe des Dynamic Invocation Interface (DII) Aufrufe zur Laufzeit konstruiert werden. Analog dazu können auf der Server-Seite über das Dynamic Skeleton Interface (DSI) beliebige Aufrufe ohne Kenntnis der Schnittstellenbeschreibung entgegengenommen werden [Haa01]. Der ORB beinhaltet auch ein Implementation Repository. In dieser Datenbank wird gespeichert, welcher Server welche CORBA-Objekte beinhaltet und wie ein Server bei Bedarf zu starten ist. Auf diese Weise kann CORBA einen automatischen Aktivierungsmechanismus bieten. Wenn ein Client nach einem bestimmten CORBA-Objekt verlangt, das derzeit von keinem Server angeboten wird, kann der ORB im Implementation Repository nach einem passenden Server-Programm suchen und dessen Ablageort und Konfigurationsdaten ermitteln, um ihn anschließend zu starten [GT00].

11 2 Dynamische Verwaltung von Softwarekomponenten 6 Common Object Services bieten Dienste an, die benötigt werden, um Objekte und Daten zu finden und zu verwalten. Einige wichtige COS sind etwa Naming Service, Trading Service, Persistent Object Service und Event Service. Der Naming Service verknüpft einen abstrakten Namen zu einem Objekt. Der Client muss dann nur den entsprechenden Namen eingeben, um das Objekt zu erreichen. In diesem Fall fungiert der Naming Service als eine Datenbank. Ein Objekt kann nicht nur einen Namen haben, sondern auch Eigeschaften. Der Trading Service wird benutzt, um ein Objekt zur Laufzeit zu finden. Im Gegensatz zum Naming Service werden Objekte nicht durch ihre Namen identifiziert, sondern durch den Vergleich von Eigenschaften. Nach dem Vergleich können mehrere Objekte gefunden werden. Mit dem Persistent Object Service wird eine vordefinierte Schnittstelle ermöglicht, um Persistenz für CORBA-Objekte auf verschiedenen Systemen zu gewährleisten. Der Event Service ermöglicht asynchrone Kommunikation mittels Ereignismeldungen. Dabei wird zwischen Objekten unterschieden: Supplier und Consumer. Supplier erzeugen Ereignismeldungen und versenden sie an Consumer. Ein Consumer empfängt die Ereignismeldungen und verarbeitet sie weiter. Dabei werden das Push-Modell und das Pull-Modell unterstützt. Common Facilities bieten Dienste an, die auf den COS aufbauen und in ihrer Funktionalität über sie hinausgehen. Die Dienste der Common Facilities sind weniger allgemein als die COS, aber sie erledigen noch komplexere Aufgaben. Die Comon Facilities sind in die folgende Bereiche untergliedert: Information Management Benutzerschnittstellen Systemmanagement Taskmanagement Domain Objects stellen die nächste Abstraktionsstufe nach den COS und den Common Facilities dar. Sie sind auf einen bestimmten Anwendungsbereich zugeschnitten, etwa Telekommunikation, Bankwesen oder Medizin. Application Objects stellen die eigentlichen verteilten Applikationen dar. Sie kommunizieren miteinander und mit den anderen OMA-Komponenten über den ORB. Für ihre Realisierung verwenden sie die COS, die Common Facilities sowie die Domain Objects. Die Application Objects selbst sind nicht Teil der Standardisierung.

12 2 Dynamische Verwaltung von Softwarekomponenten 7 Die 5 Komponenten der OMA und ihre Beziehungen zueinander sind in Abbildung 2.2 graphisch dargestellt. Abbildung 2.2: Object Management Architecture der OMG [Haa01] Trotz der IDL könnte es noch Probleme mit der Interoperabilität geben. Einfachstes Beispiel ist der Einsatz von VisiBroker als ORB. Wenn ein CORBA-Programm diesen Broker als Kommunikationsplattform einsetzt, müssen die Bibliotheken von VisiBroker sowohl client- als auch serverseitig eingebunden werden. Eine Zusammenarbeit mit einem anderen Broker ist nicht garantiert [Lan02]. Konkurrenz erhält CORBA vor allem von Microsoft mit seiner.net-plattform. Die.NET-Plattform verwendet das Simple Object Access Protocol (SOAP), das entfernte Methodenaufrufe auf der Basis von extensible Markup Language (XML) realisiert. Außerdem kann es mit dem Protokoll Hyper Text Transfer Protocol (HTTP) arbeiten, das die Einsetzbarkeit noch weiter steigert. Im Allgemeinen ist zu empfehlen, CORBA nur zu verwenden, wenn die Komponenten mit unterschiedlichen Programmiersprachen entwickelt werden sollen. Es ist jedoch anzunehmen, dass Großunternehmen, die bereits CORBA einsetzen, nicht von dieser Technologie abweichen werden. Besonders in den Bereichen der Banken, Versicherungen und Luftfahrten werden diese Systeme schon seit sehr langer Zeit eingesetzt und haben sich entsprechend bewährt. CORBA erfordert eine enormes Know-how der Mitarbeiter. Erst ab ca. 20 Mitarbeitern lassen sich große Projekte entsprechend bewältigen. Deshalb sollte bei der Weiterentwicklung von CORBA das Ziel sein, die Komplexität des Projektes zu reduzieren [Lan02]. Im Zuge der Weiterentwicklung verabschiedete OMG auch noch CORBA 2 und

13 2 Dynamische Verwaltung von Softwarekomponenten 8 CORBA 3. In CORBA 2 wird der GIOP und IIOP dazu addiert und in CORBA 3 die Interoperabilität mit den anderen Komponentenmodellen. General Inter ORB Protocol (GIOP) ist ein Protokoll, mit dem ORB miteinander kommunizieren. Internet Inter ORB Protocol (IIOP) ist die Umsetzung der GIOP über TCP/IP. Da IIOP nicht immer Port 80 [IAN12] wie bei XML/SOAP verwendet, kann es Probleme mit einer sehr strengen Firewall geben. Unter findet man die genauere Spezifikation von CORBA 2 und CORBA JINI Jini ist eine Service-orientierte Architektur, die Java-Technologie erweitert, um sichere und verteilte Systeme aufzubauen. Diese Systeme bestehen aus Föderationen von Diensten und Clients. Jini wurde 1999 von Sun Microsystems verabschiedet. Ab 2007 wurde das Projekt Jini von Apache übernommen und in Apache River umbenannt. Jini unterstützt nur Java-Systeme und bestimmte Plattformen wie Solaris, Ubuntu und Windows. Jini hat den Ansatz, die automatische Vermittlung zwischen Client und Server zu ermöglichen. Die Firma Sun, die Jini entwickelt hat, nennt diese Eigenschaft Spontaneous Networking [Haa01]. Jini besteht aus 3 Komponenten: Client Server Lookup Service Der Lookup Service ermöglicht einem Client, die verfügbaren Dienste in verteilten Systemen zu finden. Die Dienste können sofort benutzt werden, ohne das System neu zu starten. Lookup Service arbeitet ähnlich wie CORBA Naming oder Trading Services. Auf diese Art können Client bzw. Server auch in dynamisch konfigurierten Netzen den Lookup Service finden. Eine übliche Realisierung ist, bestimme Dienste auf reservierten TCP- oder UDP- Ports zu hören. Ein Client muss dann aber immer noch die IP-Adresse oder den logischen Rechnernamen des Server-Rechners kennen, um den Dienst zu adressieren. Wenn dies nicht der Fall ist, verwendet Jini IP-Multicast zwischen und So gibt es für jede aktive Jini-Föderation einen Registrierbaum, der sich potenziell über das gesamte Internet erstreckt [Haa01].

14 2 Dynamische Verwaltung von Softwarekomponenten 9 Wenn ein Jini Lookup Service gestartet wird, gibt dieser seine Anwesenheit durch ein Announcement auf eine Multicast-Adresse. z.b bekannt. Somit erfahren Clients und Dienste von der Existenz eines neuen Lookup Service. Dann trägt sich der Lookup Services in die Multicast-Gruppe ein. Alle Clients und Dienste melden sich auf der Adresse , wenn sie den Lookup Service finden möchten. Dieser Vorgang wird Lookup-Discovery genannt. Die angesprochenen Lookup Services antworten, in dem sie einen Java Proxy zurückschicken. Der Client bzw. Dienst kann den Proxy verwenden, um Anfragen an den Lookup Service zu stellen. Dienste in Jini stehen nicht unbedingt dauerhaft zur Verfügung, deshalb wurde das Leasing eingeführt. Wenn ein Jini-Dienst einen oder mehrere passende Lookup Services gefunden hat, kann er sich bei ihnen anmelden. Dazu hinterlegt er seinen eigenen Proxy und ggf. benutzerdefinierte Attribute. Im Gegenzug erhält der Dienst ein Lease. Leases müssen regelmäßig erneuert werden, so kann festgestellt werden, ob ein Dienst noch existiert ist oder nicht. Wenn keine Erneuerung des Leases innerhalb einer Zeitspanne erfolgt, wird der Dienst aus dem Lookup Service gelöscht. Ein Client nutzt den Lookup Service, um nach passenden Diensten zu suchen. Dazu sendet er den Typ des gesuchten Dienstes und die Werte der Attribute. Falls der Lookup Service über einen passenden Dienst verfügt, schickt er dessen Proxy zum Client. Der Client kann dann auf diesem Proxy arbeitet. So als wäre der Dienst lokal verfügbar. Abbildung 2.3: Ablauf der Jini-Anfrage [New12]

15 2 Dynamische Verwaltung von Softwarekomponenten 10 Zum Starten des Lookup Services muss auch ein HTTP-Server gestartet werden. Wenn Dienste ihre Proxy senden, ist der erste Teil der Datenstroms ein Uniform Resource Locator (URL). Diese URL gibt bekannt, wo die benötigte JAR heruntergeladen werden kann. Oft geht diese URL zurück bis zu einem bestimmten HTTP-Server. Um zu kommunizieren, wird kein Standard vorausgesetzt. Früher wurde Java RMI verwendet. Aber ab Jini 2.0 wird ein Protokoll namens Jini Extensible Remote Invocation (Jeri) vorgeschlagen. Jeri ist eine neue Implementierung des RMI-Modells und gewährt noch höhere Sicherheit [Art12]. Der Client unterscheidet nicht, ob Jeri, RMI oder IIOP verwendet werden solange das Protokoll mit der Semantik der Schnittstelle übereinstimmt. Ein Verbund von Clients, Diensten, einem oder mehreren Lookup Services wird Djinn oder Federation genannt. Obwohl sich Jini selbst nicht erfolgreich durchgesetzt hat, wird sein Ansatz in JavaSpace verwendet. JavaSpace ist ein Verbund von Jini- Diensten, die Java-Objekte speichern und als eine geschlossene Einheit zusammen arbeiten. JavaSpaces ist sehr einfach und besteht aus 7 Methoden. Vier von denen sind: schreiben Ein Objekt wird in JavaSpace geschrieben. lesen Ein Objekt wird aus JavaSpace gelesen. Dies liefert eine Kopie und hinterlässt eine Kopie in JavaSpace nehmen Ein Objekt wird aus JavaSpace genommen. Dies liefert eine Kopie und entfert das Objekt aus JavaSpace notifizieren Lookup Service wird benachrichtigt, wenn Änderungen in JavaSpace festgestellt. Anfangs war Jini Konkurrenz für CORBA und DCOM. Distributed Component Object Model (DCOM) ist eine frühere Microsoft-Spezifikation, die schon absorbiert und abgeschafft wurde zugunsten der.net-technologie. Auch innerhalb der Java- Gesellschaft konnte sich Jini nicht gegen Enterprise Java Beans (EJB) durchsetzen. Jini läuft in Java Standard Edition (Java SE), denn es wird eine Java Virtual Machine (JVM) gebraucht, um die nötigen Operationen durchzuführen. Somit ist Jini für Kleingeräte mit beschränkten Ressourcen nicht geeignet. Außerdem gibt es zurzeit kaum Dokumentation und Tutorials für Jini. Seit der Übergabe an Apache ist die Seite die als Bezugpunkt für Einsteiger dienen sollte, nicht mehr verfügbar.

16 2 Dynamische Verwaltung von Softwarekomponenten EJB Enterprise Java Beans (EJB) wurde im Jahr 2001 von Sun Microsystems verabschiedet. EJB kann leicht mit JavaBeans verwechselt werden, aber EJB ist völlig unabhängig von JavaBeans. EJB-Technologie ist die serverseitige Komponente der Architektur für Java Enterprise Edition (Java EE). EJB ermöglicht die schnelle und vereinfachte Entwicklung verteilter Anwendungen. JavaBeans hingegen ist eine Schnittstellen-Spezifikation für wiederverwendbarer Komponenten in Java. Sie definiert die Java-Komponenten und wie sie zusammen arbeiten sollen. Bei JavaBeans handelt es sich um einen Verbund von mehreren Java-Objekten, genannt Beans. Ein Java-Entwickler, der eine Funktion oder ein Objekt braucht, muss dann nicht selbst alles schreiben. Er kann den entsprechende Bean herunterladen und einsetzen. Mit EJB soll die Entwicklung von verteilten, komponentenbasierten Java-Anwendungen vereinfacht werden. EJB sorgt zudem für eine Komplexitätsreduktion: Die Ansteuerung von Mechanismen wie Verteilung, Sicherheit und Transaktionsverwaltung muss in anderen Umgebungen oft vom Entwickler explizit ausprogrammiert werden, was aufwendig und fehleranfällig ist. EJB verlagert diese Komplexität in die EJB-Server bzw. EJB-Container, so dass sich der Komponentenentwickler auf die eigentlichen fachlichen Anforderungen, also auf die Business-Logik konzentrieren kann [GT00]. EJB besteht aus 4 Teilen: Client-Anwendungen EJB-Server EJB-Container EJB-Komponenten Die Grundstruktur entscpricht einer Drei-Schicht-Anwendung aus einer Präsentations-, einer Geschäftslogik- und einer Datenebene. In einer typischen Geschäftsanwendung verwendet man für die Datenebene eine Datenbank und für die Präsentationsebene entweder GUI-Front-End oder einen Webserver. Die Geschäftslogikebene ist normalerweise am schwierigsten zu entwerfen. Man muss herausfinden, wie der eigene Code mit der Datenbank und mit Clients zusammenarbeiten wird. Wie mit den Clients interagiert wird, entscheidet häufig darüber, wie man mit der Datenbank interagiert [Wut02]. Abbildung 2.4 veranschaulicht den Aufbau der EJB-Architektur.

17 2 Dynamische Verwaltung von Softwarekomponenten 12 Abbildung 2.4: EJB-Architektur [Int12] Viele Entwickler stellen sich unter einem Container eine Datenstruktur wie ein Array, eine verkettete Liste oder einen Vektor vor. In Java EE ist ein Container jedoch fast wie ein Mini-Server. Er stellt die Laufzeitunterstützung für die Elemente bereit, die er enthält. Ein EJB-Container enthält EJB-Komponenten und sorgt für die Bildung eines Verbindungspools und die Transaktionsverarbeitung. Ein Server kann mehrere Container haben. Und die Objekte in den einzelnen Container sind voneinander isoliert, obwohl Objekte in einem Container mit Objekten in einem anderen Container kommunizieren können. Der Unterschied zwischen einer Komponente und einem Objekt ist nicht immer klar. Aber i.a. ist eine Komponente ein Software-Modul, das so entworfen ist, dass man es in vielen Anwendungen verwenden kann, ohne es zu verändern. Ein Objekt kann zwar eine Komponente sein, aber normalerweise stellt man sich unter Komponenten etwas Größeres als Objekte vor. EJB sind verteilte Objekte und daher eher Komponenten als Objekte. Und tatsächlich ist eine EJB nicht als einzelnes Objekt, sondern als Gruppe von Objekten definiert. [Wut02] EJB-Container enthalten drei Typen von Beans: Session Beans Message Driven Beans Entity Beans Session Beans führen die Anwendungslogik im Auftrag des Kunden. Sie wird nicht

18 2 Dynamische Verwaltung von Softwarekomponenten 13 in der Datenbank gespeichert, kann dennoch auf die Datenbank zugreifen. Session Beans sind relativ kurzlebig, meist nur innerhalb einer Client-Sitzung. Man unterscheidet stateful und stateless Session Beans. Eine stateful Session Bean kann Daten speichern für die spätere Wiederverwendung. Ein EJB-Container kann mehrere stateful Session Beans enthalten, deshalb wird an jede einzelne Session Bean eine eindeutige ID vergeben. Im Gegensatz dazu können stateless Session Beans keine Daten speichern. Sie werden daher von anderen stateless Session Beans nicht unterschieden und haben keine eindeutige ID. Message Driven Beans sind für asynchrone Kommunikation gedacht. Sie führen die Anwendungslogik nach Erhalt einer Nachricht vom Kunden. Hierzu wird Java Message Service (JMS) verwendet. Message Driven Beans sind auch relativ kurzlebig. Wenn das System währen der Sitzung abstürtzt, muss eine neue Bean etabliert werden. Entity Beans stellen eine persistente Entität dar. Sie werden häufig in einer relationalen Datenbank gespeichert. Sie haben eine eher lange Lebensdauer und sind nicht auf die Dauer einer Client-Sitzung beschränkt. Anders als Session Beans können mehrere Clients gleichzeitig auf dieselbe Entity Bean zugreifen. Seit EJB 3.0 sind Entity Beans obsolet und werden nicht mehr gebraucht. Sie werden von Java Persistence API ersetzt. Eine Komponente, die in EJB 3.0 geschrieben wurde, ist kompatibel mit einer Komponente, die in EJB 2.1 oder in früherer Version geschrieben wurde. Solche Komponenten- Kombination von verschiedenen Versionen der EJB kann die Migration von bestehenden Anwendungen erleichtern. Außerdem ermöglicht sie die Wiederverwendung von Komponenten aus früheren EJB-Spezifikationen. 2.4 OSGi Open Service Gateway Initiative (OSGi) Framework ist ein modularisches System und eine Service-Plattform, die ein dynamisches Komponentenmodell implementiert. Installation, Start, Stopp und Deinstallation erfolgen über das Netzwerk und benötigen keinen Neustart des Gesamtsystems. Außerdem ermöglicht OSGi auch eine Versionierung, d.h. Komponenten können zur Laufzeit auf eine neuere Version upgegradet werden. OSGi ist nicht sprachunabhängig, nur Java wird hier unterstützt. OSGi wurde von der OSGi-Allianz verabschiedet, die 1999 gegründet wurde. Die OSGi-Allianz besteht aus vielen bekannten Großunternehmen im Bereich Service- und Content-Anbieter, Infrastruktur- und Netzbetreiber sowie Software-Entwicklung. Dazu gehören z.b. Adobe Systems, Oracle, IBM, Deutsche Telekom, Mitsubishi Electric

19 2 Dynamische Verwaltung von Softwarekomponenten 14 und NTT [OSG12a]. Durch so ein großes Konsortium ist es kein Wunder, dass die Entwicklung von OSGi anderen Ansätzen überlegen ist. Die aktuellste Version der OSGi-Framework ist Version 5 (Juni 2012). Diese Masterarbeit befasst sich jedoch nur mit der OSGi Version 4.2, die im Juni 2009 verabschiedet wurde. Abbildung 2.5 veranschaulicht die OSGi-Architektur. Abbildung 2.5: OSGi-Architektur[OSG12b] Bundles Bundles sind die OSGi-Komponenten, die von den Entwicklern erstellt werden. Service-Schicht Die Service-Schicht verbindet Bundles in einer dynamischen Art und Weise. Life-Cycle-Schicht Hier wird die Installation, Starten, Stoppen, Update und Deinstallation von Bundles ermöglicht. Module-Schicht Die Module-Schicht definiert wie Bundles Codes importieren und exportieren können. Security-Schicht Sie behandelt Sicherheitsaspekte und die digitale Signatur.

20 2 Dynamische Verwaltung von Softwarekomponenten 15 Execution Environment Bundles, die nur in einer bestimmten Ausführungsumgebung wie JavaSE-1.6 oder J2SE-1.5 lauffähig sind, müssen dies in der Execution Environment Schicht angeben. In OSGi werden Softwarekomponenten als Bundles bezeichnet. Ein Bundle ist eine Menge von Java-Klassen und anderen Ressourcen, verpackt in ein Java-Archiv (JAR) mit zusätzlichen Header-Informationen (Manifest). Informationen über das Bundle, wie z.b. Name, Version und Abhängigkeit (Dependencies) werden in der Manifest- Datei gespeichert. Alles, was nicht explizit exportiert wird, bleibt im Bundle versteckt. Anders als bei OSGi ist im Standard-Java der gesamte Inhalt einer JAR-Datei für alle sichtbar. Analog zum Export muss ein Bundle die Teile, die es aus einem anderen Bundle nutzen will, explizit importieren. Die Lebenszyklusschicht in der OSGi-Framework ermoglicht die Installation, Starten, Stoppen, Update und Deinstallation von Bundles, unabhängig von der Lebensdauer der JVM. Sie sorgt auch dafür, dass Pakete nur gestartet werden, wenn alle ihre Abhängigkeiten aufgelöst wurden. Dadurch sinkt das Auftreten von der ClassNotFoundException-Ausnahme zur Laufzeit. Falls sich ungelöste Abhängigkeiten ergeben, wird das Bundle nicht gestartet und eine Problemmeldung wird erstellt. Jedes Bundle kann eine Bundle-Activator-Klasse haben, die im MANIFEST.MF als solche gekennzeichnet ist. Ein Bundle-Activator muss über einen öffentlichen Konstruktor ohne Parameter, zum Erzeugen eines Objektes durch Class.newInstance() verfügen. Für jedes auf einer OSGi-Plattform installierte Bundle gibt es ein assoziiertes Bundle- Objekt über das der Lebenszyklus des Bundles direkt gesteuert werden kann. Ein Bundle kann sich in sechs verschiedenen Zuständen befinden [WBB10]: INSTALLED Das Bundle wurde erfolgreich auf der OSGi-Plattform installiert. RESOLVED Alle Java-Klassen, die das Bundle benötigt, sind verfügbar. Das Bundle ist bereit, gestartet zu werden oder wurde gerade gestoppt. STARTING Das Bundle wird über den Aufruf der Start-Methode des BundleActivators gestartet. Die Methode ist noch nicht beendet. Oder die Methode ist beendet, aber das Bundle wird erst aktiv, wenn es von anderen Bundles benötigt wird. ACTIVE Das Bundle läuft. Die Start-Methode wurde erfolgreich beendet. STOPPING Die BundleActivator. Stopp-Methode wurde zum Stoppen des Bundles aufgerufen, aber noch nicht beendet. UNINSTALLED Das Bundle wurde deinstalliert.

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

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

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 JavaBeans Überblick

Enterprise JavaBeans Überblick Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

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

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

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

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

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

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

Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java. Oliver Kalz

Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java. Oliver Kalz Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java Oliver Kalz Agenda Grundlagen Objektpersistenz Objektrelationales Mapping Performance Fazit

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

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

Die OSGi Service Plattform

Die OSGi Service Plattform Die OSGi Service Plattform Seminarvortrag Bernhard Cleven Gliederung 1 Einleitung 2 Das Framework 3 Bundles 4 Services 5 Beispiel 6 Fazit Seite 1/ 17 Einleitung Warum OSGi? Durch Modularisierung flexible

Mehr

CORBA. Eine kurze Einführung. Common Object Request Broker Architecture. Ying Lu

CORBA. Eine kurze Einführung. Common Object Request Broker Architecture. Ying Lu CORBA Common Object Request Broker Architecture Eine kurze Einführung Ying Lu Verlauf der Präsentation Was ist CORBA CORBA-Architektur Ein Beispiel CORBA im Einsatz CORBA im Vergleich Was ist CORBA Begriffe

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

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

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder Michael Greifeneder OSGi The Next Generation Java Service Platform SOA - The Java Way or My classpath is killing me Bilder von Peter Kriens W-JAX Keynote 2007 und Neil Bartletts Getting Started with OSGi

Mehr

Inhaltsverzeichnis. Zusammenfassung CORBA

Inhaltsverzeichnis. Zusammenfassung CORBA Inhaltsverzeichnis 1 Was und wofür ist CORBA?... 2 1.1 Problematik in Verteilten Systemen... 2 1.2 Entwurfszeile... 2 2 Zweck und Ziele von OMG?... 2 3 Was ist eine Schnittstellenarchitektur?... 2 3.1

Mehr

OO Programmiersprache vs relationales Model. DBIS/Dr. Karsten Tolle

OO Programmiersprache vs relationales Model. DBIS/Dr. Karsten Tolle OO Programmiersprache vs relationales Model Vorgehen bisher Erstellen eines ER-Diagramms Übersetzen in das relationale Datenmodell Zugriff auf das relationale Datenmodell aus z.b. Java ER rel. Modell OO

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen?

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? Großer Beleg Christian Wurbs Zwischenbericht http://www.inf.tu-dresden.de/~cw6 cw6@inf.tu-dresden.de Überblick 2 Aufgabenstellung CORBA

Mehr

5. Programmierschnittstellen für XML

5. Programmierschnittstellen für XML 5. Programmierschnittstellen für Grundlagen Dr. E. Schön FH Erfurt Sommersemester 2015 Seite 135 Programmierschnittstelle Notwendigkeit: Zugriff auf -Daten durch Applikationen wiederverwendbare Schnittstellen

Mehr

5. Programmierschnittstellen für XML

5. Programmierschnittstellen für XML 5. Programmierschnittstellen für für Medientechnologen Dr. E. Schön Wintersemester 2015/16 Seite 146 Notwendigkeit: Programmierschnittstelle Zugriff auf -Daten durch Applikationen wiederverwendbare Schnittstellen

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

Gerd Wütherich Martin Lippert. OSGi Service Platform by example

Gerd Wütherich Martin Lippert. OSGi Service Platform by example Gerd Wütherich Martin Lippert OSGi Service Platform by example Die OSGi Service Platform Das Buch» Detaillierte Einführung in OSGi-Technologie» April 2008, dpunkt.verlag» ISBN 978-3-89864-457-0» Website:

Mehr

Gerd Wütherich Nils Hartmann. OSGi Service Platform by example

Gerd Wütherich Nils Hartmann. OSGi Service Platform by example Gerd Wütherich Nils Hartmann OSGi Service Platform by example Die OSGi Service Platform Das Buch» Detaillierte Einführung in OSGi-Technologie» April 2008, dpunkt.verlag» ISBN 978-3-89864-457-0» Website:

Mehr

7 Assemblies. Anwendungen (.exe) bzw. Anwendungskomponenten (.dll) für.net Portable Execution (PE) Files

7 Assemblies. Anwendungen (.exe) bzw. Anwendungskomponenten (.dll) für.net Portable Execution (PE) Files 7 Assemblies 8 Virtual Execution System VES Anwendungen (.exe) bzw. Anwendungskomponenten (.dll) für.net Portable Execution (PE) Files Teil der CLR Class Loader Metadaten (Manifest) zur Selbstbeschreibung

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

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

Enterprise Softwarearchitekturen in Java

Enterprise Softwarearchitekturen in Java Enterprise Softwarearchitekturen in Java Dauer: 5 Tage 1. Tag: Vorbereitungstag...2 Der erste Tag richtet sich an alle, die bislang wenig Praxiserfahrung mit der Programmiersprache Java haben. Die Teilnehmer

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

Kap. 3 Verteilte Objektverwaltung

Kap. 3 Verteilte Objektverwaltung Kap. 3 Verteilte Objektverwaltung 3.1 Einführung in die verteilte Objektverwaltung (Distributed Object Management, DOM) Anforderungen Kurzübersicht Java RMI Microsoft COM+ CORBA 3.2 Der CORBA-Standard

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

3.2 Der CORBA-Standard Common Object Request Broker Architecture

3.2 Der CORBA-Standard Common Object Request Broker Architecture 3.2 Der CORBA-Standard Common Object Request Broker Architecture (Bildquelle: OMG) Kapitel 3.2: Vorlesung CORBA 1 CORBA Middleware im Ueberblick G CORBA = Common Object Request Broker Architecture. Standard

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

Ü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

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

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

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans JPA - JAVA Persistence API Problem In JAVA-programmen arbeitet man mit Hauptspeicherobjekten. Nach Beendigung des Programmes sind diese nicht mehr vorhanden.

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

Multiuser Client/Server Systeme

Multiuser Client/Server Systeme Multiuser /Server Systeme Christoph Nießner Seminar: 3D im Web Universität Paderborn Wintersemester 02/03 Übersicht Was sind /Server Systeme Wie sehen Architekturen aus Verteilung der Anwendung Protokolle

Mehr

OSGi: Anwendungsszenarien, Auswahlkriterien und Ausblick

OSGi: Anwendungsszenarien, Auswahlkriterien und Ausblick OSGi: Anwendungsszenarien, Auswahlkriterien und Ausblick Thementag OSGi 03.11.2009 Autor: Christoph Schmidt-Casdorff Agenda Wo wird OSGi derzeit eingesetzt? Grundsätzliche Anwendungsszenarien OSGi Status

Mehr

Szenario 3: Service mit erweiterter Schnittstelle

Szenario 3: Service mit erweiterter Schnittstelle 2. Hintergrundverarbeitung in Android: Services und Notifications Szenarien für lokale Services Szenario 3: Service mit erweiterter Schnittstelle Ein Service bietet zusätzliche Methoden an, über die sich

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

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

Andreas Mösching Senior IT Architekt Hewlett-Packard (Schweiz) GmbH HP Banking Service Center Bern andreas.moesching@rtc.ch

Andreas Mösching Senior IT Architekt Hewlett-Packard (Schweiz) GmbH HP Banking Service Center Bern andreas.moesching@rtc.ch Eclipse Runtime (OSGi) als Plattform eines Swing Rich Client Andreas Mösching Senior IT Architekt Hewlett-Packard (Schweiz) GmbH HP Banking Service Center Bern andreas.moesching@rtc.ch Zu meiner Person

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

Eclipse und EclipseLink

Eclipse und EclipseLink Eclipse und EclipseLink Johannes Michler Johannes.Michler@promatis.de PROMATIS, Ettlingen Zugriff auf Oracle Datenbanken aus Eclipse RCP Anwendungen via EclipseLink 18.09.2009 1 Gliederung Eclipse als

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

-Testen verteilter Anwendungen

-Testen verteilter Anwendungen -Testen verteilter Anwendungen Seminar Simulation und Bildanalyse mit Java im SS04 Konstantin Tjo, Urs Pricking Testen verteilter Anwendungen 1 Übersicht Einführung in verteilte Anwendungen RMI (Remote

Mehr

Java RMI Remote Method Invocation

Java RMI Remote Method Invocation Java RMI Remote Method Invocation Ziel: Aufruf von Instanzmethoden entfernter Objekte basierend auf Java. Paket: java.rmi und Unterpakete Topologie: RMI Registry RMI Server RMI Client Der Server registriert

Mehr

Seminarvortrag Serviceorientierte Softwarearchitekturen

Seminarvortrag Serviceorientierte Softwarearchitekturen Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?

Mehr

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit Hochschule für Technik und Architektur Chur Dr. Bruno Studer Studienleiter NDS Telecom, FH-Dozent bruno.studer@fh-htachur.ch 1 GSM: 079/610 51 75 Agenda Vorteile von Java und Konvergenz Service Creation

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

Verteilte Systeme. Verteilte Objektorientierte Systeme II. Prof. Dr. Oliver Haase

Verteilte Systeme. Verteilte Objektorientierte Systeme II. Prof. Dr. Oliver Haase Verteilte Systeme Verteilte Objektorientierte Systeme II Prof. Dr. Oliver Haase 1 Überblick Verteilte Objektorientierte Systeme 1 RPC verteilte objektorientierte Architekturen Java RMI Verteilte Objektorientierte

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

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

Modul Software Komponenten 10 Komponentenarchitektur

Modul Software Komponenten 10 Komponentenarchitektur Modul Software Komponenten 10 Komponentenarchitektur Teil 3 Peter Sollberger Eine erste CORBA Anwendung Inhalt Dienstag, 4. November Object Request Broker CORBA Architektur und Komponenten (Teil 1) Übung:

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Projektgruppe 453: Entwurf eines Managementwerkzeugs zur Verwaltung von Sicherheitsdiensten für komplexe eingebettete Dienstesysteme

Projektgruppe 453: Entwurf eines Managementwerkzeugs zur Verwaltung von Sicherheitsdiensten für komplexe eingebettete Dienstesysteme Titel CORBA Eine Middleware-Plattform für objektorientierte Technologien von Martin Villis 6. Mai 2004 Projektgruppe 453: Entwurf eines Managementwerkzeugs zur Verwaltung von Sicherheitsdiensten für komplexe

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

Access und OpenOffice.org

Access und OpenOffice.org Access-Datenbanken in OpenOffice.org 1.1 einbinden Herausgegeben durch das OpenOffice.org Germanophone-Projekt Autoren Autoren vorhergehender Versionen Timo Kozlowski Alle in diesem Dokument erwähnten

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

Windows Azure für Java Architekten. Holger Sirtl Microsoft Deutschland GmbH

Windows Azure für Java Architekten. Holger Sirtl Microsoft Deutschland GmbH Windows Azure für Java Architekten Holger Sirtl Microsoft Deutschland GmbH Agenda Schichten des Cloud Computings Überblick über die Windows Azure Platform Einsatzmöglichkeiten für Java-Architekten Ausführung

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

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

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

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

Persistenzschicht in Collaborative Workspace

Persistenzschicht in Collaborative Workspace Persistenzschicht in Collaborative Workspace Mykhaylo Kabalkin 03.06.2006 Überblick Persistenz im Allgemeinen Collaborative Workspace Szenario Anforderungen Systemarchitektur Persistenzschicht Metadaten

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

IBM SPSS Data Access Pack Installationsanweisung für Windows

IBM SPSS Data Access Pack Installationsanweisung für Windows IBM SPSS Data Access Pack Installationsanweisung für Windows Inhaltsverzeichnis Kapitel 1. Übersicht.......... 1 Einführung............... 1 Bereitstellen einer Datenzugriffstechnologie.... 1 ODBC-Datenquellen...........

Mehr

Java Beans (22.02.2001)

Java Beans (22.02.2001) Component Based Software Development Java Beans (22.02.2001) Stefan Jäger Robert Kalcklösch Veranstalter: M. Bittner W. Koch Inhalt Einführung in Java Die Java Beans Einsatz und Entwicklung von Beans Enterprise

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web

Mehr

SQL, MySQL und FileMaker

SQL, MySQL und FileMaker SQL, MySQL und FileMaker Eine kurze Einführung in SQL Vorstellung von MySQL & phpmyadmin Datenimport von MySQL in FileMaker Autor: Hans Peter Schläpfer Was ist SQL? «Structured Query Language» Sprache

Mehr

OSGi-basierte Webapplikationen Ein Erfahrungsbericht

OSGi-basierte Webapplikationen Ein Erfahrungsbericht OSGi-basierte Webapplikationen Ein Erfahrungsbericht Zürich, 18. März 2009 Pascal Nüesch, Software Engineer 1 www.namics.com Zu meiner Person» Lehre als Elektroniker mit Schwerpunkt SW-Entwicklung» Java

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Ein Vergleich zwischen SCA,JBI und WCF. Marcello Volpi

Ein Vergleich zwischen SCA,JBI und WCF. Marcello Volpi Service Component Architecture Ein Vergleich zwischen SCA,JBI und WCF Marcello Volpi Agenda Einführung Service Component Architecture (SCA) Java Business Integration (JBI) Windows Communication Foundation

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

Der Einsatz von CORBA in verteilten EDA-Tools

Der Einsatz von CORBA in verteilten EDA-Tools Der Einsatz von CORBA in verteilten EDA-Tools Frank Grützmacher Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Fachgebiet Mikroelektronische Schaltungen und Systeme

Mehr

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit

Mehr

Java Message Service im J2EE-Kontext

Java Message Service im J2EE-Kontext Java Message Service im J2EE-Kontext Im Folgenden soll kurz das Konzept der nachrichtenorientierten Kommunikation mit Hilfe von Messaging Services vorgestellt, und im Anschluss deren Einsatzmöglichkeiten

Mehr

Java für C++ Programmierer

Java für C++ Programmierer Java für C++ Programmierer Alexander Bernauer bernauer@inf.ethz.ch Einführung in die Übungen zu Informatik II (D ITET) FS2010 ETH Zürich Ziel Allgemeiner Überblick Kennenlernen der Suchbegriffe Warum Java?

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

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

CORBA. Beispiel einer Middleware-Plattform. Christian Fass WS 2013/14 Software Engineering: Basistechnologien

CORBA. Beispiel einer Middleware-Plattform. Christian Fass WS 2013/14 Software Engineering: Basistechnologien CORBA Beispiel einer Middleware-Plattform Christian Fass WS 2013/14 Software Engineering: Basistechnologien Allgemeines Common Object Request Broker Architecture Middleware: Vermittelt zwischen Obekten/Prozessen

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

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

Mit OSGi Webanwendungen entwickeln Was geht, was nicht?

Mit OSGi Webanwendungen entwickeln Was geht, was nicht? Mit OSGi Webanwendungen entwickeln Was geht, was nicht? Peter Roßbach (Systemarchitekt) Gerd Wütherich (Freier Softwarearchitekt) Martin Lippert (akquinet it-agile GmbH) 2009 by P. Roßbach, G. Wütherich,

Mehr

Java Persistence API 2.x. crud + relationships + jp-ql

Java Persistence API 2.x. crud + relationships + jp-ql Java Persistence API 2.x crud + relationships + jp-ql Grundprinzip 10.02.10 2 Problematik Man muss bei der Persistierung immer das Klassenmodell und dessen Umsetzung im Datenmodell (in der DB) berücksichtigen.

Mehr