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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10. J2EE eine Plattform für betriebliche Anwendungen Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Plattform Betriebliche Anwendung J2EE Kontrahenten J2EE im Überblick Was ist

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

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

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

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

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

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

Hello World from CORBA

Hello World from CORBA Hello World from CORBA ein erster Überblick Aufruf einer Objekt-Methode Client gettemperature() Thermometer Objekt- Implementation Thermometer th = new Thermometer(); double t = th.gettemperature(); th

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

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

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

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

SpringSource Enterprise & Application Platform: Wo geht die Reise hin?

SpringSource Enterprise & Application Platform: Wo geht die Reise hin? SpringSource Enterprise & Application Platform: Wo geht die Reise hin? Eberhard Wolff Regional Director & Principal Consultant SpringSource Copyright 2007 SpringSource. Copying, publishing or distributing

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

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

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

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

Mehr

Grundlagen und Implementation. Jan Kraft

Grundlagen und Implementation. Jan Kraft Grundlagen und Implementation Jan Kraft Gliederung 1 die OMG 2 Was ist CORBA? 3 Funktionsweise 3.1 die Interface Definition Language 3.2 Objekt Adapter 3.3 weitere Komponenten des ORB 3.4 InterORB Protokolle

Mehr

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org)

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Dynamische Plug-ins mit Eclipse 3 Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Überblick Die Ausgangslage Dynamische Plug-ins Warum? Eclipse 3 Die OSGi-basierte

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

Komponentenmodelle II

Komponentenmodelle II Komponentenmodelle II DCOM / CORBA Detlef Streitferdt Technische Universität Ilmenau DCOM Architektur Client Proxy Stub Component CoCreateInstance Security Provider DCE RPC Protocol Stack Security Provider

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

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

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

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

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

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

Mehr

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

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH

.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH Make Applications Faster.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH Agenda Vorstellung InterSystems Überblick Caché Live Demo InterSystems auf einen Blick 100.000

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

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

Mehr

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

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

Mehr

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Neue Möglichkeiten der Datenintegration Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Begriffsbestimmung ODBC, OLE DB, COM, ADO... Unterschiede zwischen

Mehr

Kommunikation ist alles

Kommunikation ist alles Kommunikation in verteilten Systemen mit Kommunikation ist alles >> alexander ziegler In einem verteilten System müssen die Anwendungsbestandteile miteinander interagieren nur so funktioniert ein großes

Mehr

explizite, orthogonale Interaktion Verteilte Anwendungen und Middleware uniforme / nicht-uniforme Interaktion implizite, nicht-orthogonale Interaktion

explizite, orthogonale Interaktion Verteilte Anwendungen und Middleware uniforme / nicht-uniforme Interaktion implizite, nicht-orthogonale Interaktion Verteilte Anwendungen und Klassifikation von Interaktionsformen explizit implizit orthogonal nicht-orthogonal uniform nicht-uniform transparent nicht-transparent explizite, orthogonale Interaktion weit

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

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

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

Mehr

Architektur iterativ auf Basis von OSGi entwickeln

Architektur iterativ auf Basis von OSGi entwickeln Architektur iterativ auf Basis von OSGi entwickeln Ein Vortrag von Sven Jeppsson (syngenio AG) und Karsten Panier (Signal Iduna Gruppe) 1 Inhalt Motivation Architektur Architektur Evolution OSGi Refactoring

Mehr

Enterprise JavaBeans

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

Mehr

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

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

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

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

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen Sommersemester 2013 Michael Theis, Lehrbeauftragter Java EE Spezifikation definiert ein Programmiermodell für Applikationen die Eigenschaften

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

SaaS-Referenzarchitektur. iico-2013-berlin

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

Mehr

Hibernate. Vortragender : Nabil Janah Kursleiter : Prof. Dr. Björn Dreher Lehrveranstaltung : Komponenten-Architekturen. Nabil janah 1 Hibernate

Hibernate. Vortragender : Nabil Janah Kursleiter : Prof. Dr. Björn Dreher Lehrveranstaltung : Komponenten-Architekturen. Nabil janah 1 Hibernate Hibernate Vortragender : Nabil Janah Kursleiter : Prof. Dr. Björn Dreher Lehrveranstaltung : Komponenten-Architekturen Nabil janah 1 Hibernate Inhalt Hibernate allgemeines Vorteile von Hibernate Hibernate-Architektur

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

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

Android Kurs Online Kurs Entwicklung auf Android-Handys

Android Kurs Online Kurs Entwicklung auf Android-Handys Android Kurs Online Kurs Entwicklung auf Android-Handys Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses Modul Eins - Programmierung J2ee 1) Grundlegende Java - Programmierung : Grundlegende

Mehr

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

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

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

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

Client/Server-Programmierung

Client/Server-Programmierung lient/server-programmierung WS 2014/2015 etriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, üro: H- 8404 Stand: 15. Oktober 2015 etriebssysteme / verteilte Systeme

Mehr

Enterprise Java Beans

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

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

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

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

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

Mehr

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

Kapitel DB:VI (Fortsetzung)

Kapitel DB:VI (Fortsetzung) Kapitel DB:VI (Fortsetzung) VI. Die relationale Datenbanksprache SQL Einführung SQL als Datenanfragesprache SQL als Datendefinitionssprache SQL als Datenmanipulationssprache Sichten SQL vom Programm aus

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

Verbinde die Welten. Von Oracle auf MySQL zugreifen

Verbinde die Welten. Von Oracle auf MySQL zugreifen Verbinde die Welten Von Oracle auf MySQL zugreifen Ronny Fauth DB Systel GmbH Zertifizierter MySQL 5.0 DBA Zertifizierter Oracle 11 DBA Einleitung: - keine Allroundlösungen mehr - Verbindungen zwischen

Mehr

Internetanbindung von Datenbanken

Internetanbindung von Datenbanken Internetanbindung von Datenbanken Oracle Application Server Oracle Application Server - 1 Gliederung Einführung Oracle Application Server (OAS) Praxis- und Diplomarbeitenverwaltung LiveHTML Kritik Becker,

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

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

Komponentenbasierte Entwicklung und Datenhaltung. FB4 - Angewandte Informatik - Prof. Dr. Ing. Elke Naumann

Komponentenbasierte Entwicklung und Datenhaltung. FB4 - Angewandte Informatik - Prof. Dr. Ing. Elke Naumann basierte Entwicklun und Datenhaltun Aenda Einführun standards Einführun die Bausteine verteilter Applikationen standards das serverseities modell -Standards Java Database Connectivity (JDBC) EJBs Java

Mehr

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

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

Mehr

Web Services mit Java

Web Services mit Java Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich

Mehr

Client/Server-Systeme

Client/Server-Systeme Client/Server-Systeme Prof. Dr.-Ing. Wilhelm G. Spruth SS 2005 Teil 16 RMI, DCOM, Webservices cs 1100 ww6 sch 05-97 Remote Method Invocation (RMI) JVM JVM Client Server Stub Java Remote Skeleton Method

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Corba. Common Object Request Broker Architecture. Von: Oliver Spiegel SoSem 2004. Seminar: Komponentenorientierte Softwareentwicklung

Corba. Common Object Request Broker Architecture. Von: Oliver Spiegel SoSem 2004. Seminar: Komponentenorientierte Softwareentwicklung Corba Common Object Request Broker Architecture Von: Oliver Spiegel SoSem 2004 Überblick Client/Server Technik Integration von bestehenden Softwaresystemen und Anwendungen Java-Unterstützung, um mobile,

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

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 Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

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

11. Enterprise Java Beans Grundlagen der Programmierung II (Java)

11. Enterprise Java Beans Grundlagen der Programmierung II (Java) 11. Enterprise Java Beans Grundlagen der Programmierung II (Java) Prof. Dr. Bernhard Humm Hochschule Darmstadt University of Applied Sciences Sommersemester 2006 Übersicht Grundlagen der Programmierung

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

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

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

Einsatz von Java-fähigen GPRS-Terminals

Einsatz von Java-fähigen GPRS-Terminals Einsatz von Java-fähigen GPRS-Terminals Ein Bericht aus der Praxis Dr. Fred Könemann INSIDE M2M GmbH 15. VDE/ITG Fachtagung Mobilkommunikation Osnabrück 19.-20. Mai 2010 Dr. Fred Könemann, INSIDE M2M GmbH

Mehr

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Die Herausforderung: Hostanbindung Viele Unternehmen besitzen Mainframe- und Legacy-Anwendungen, so genannte Enterprise Information Systems (EIS),

Mehr