Interessen

Sicherheit in der Informationstechnologie:

Der umfassende Einsatz von rechnergestützten Informations- und Kommunikationssystemen in allen betrieblichen Funktionsbereichen hat gegenwärtig zu einer hohen Abhängigkeit der Unternehmen von der Verfügbarkeit ihrer Systeme geführt. Der Länder- und Unternehmensgrenzen überschreitende Zugriff auf bestehende Systeme und Daten z. B. über das Angebot von Web-Services für Lieferanten, den Betrieb von Internet-Portalen für Kunden, sowie das Bereitstellen von Mobile Business-Lösungen für Außendienstmitarbeiter hat jedoch bis heute nicht zu einer ausreichenden Sensibilisierung der Unternehmen gegenüber möglichen Sicherheitsproblemen beigetragen. Eine weltweit angelegte Studie von Ernst & Young (Global Information Security Survey 2005, Report on the Widening Gap) belegt in diesem Zusammenhang, dass sich die Diskrepanz zwischen den gewachsenen Sicherheitsrisiken und den Bemühungen der Unternehmen, Informationssicherheit auf ausreichendem Niveau zu gewährleisten, in den letzen Jahren weiter verstärkt hat. Die nachfolgend aufgeführten Beispiele verdeutlichen, dass eine Vernachlässigung der IT-Sicherheit für Unternehmen, Mitarbeiter oder Kunden erhebliche Folgen (z. B. nachhaltige Schädigung der Reputation, wirtschaftliche Auswirkungen bei Diebstahl von Forschungsergebnissen, Geschäftsgeheimnissen oder Kundendaten etc.) haben kann:

August 2008: Massenhafter Missbrauch von Bankkonten-Daten: Vier Millionen deutsche Kontendaten wurden für 850 Euro verkauft (vgl. www.heise.de/newsticker/meldung/114124/).
Januar 2008: Aufgrund einer Schwachstelle in einer Such-Seite des Bundeskriminalamts war nach Angaben von Heise Security mit Hilfe von SQL-Injections so möglicherweise der direkte Zugriff auf die zugrunde liegende Datenbank möglich (vgl. www.heise.de/newsticker/meldung/101776/).
November 2007: Den britischen Steuerbehörden kommen zwei CDs mit den persönlichen Daten von 25 Millionen Briten abhanden. Auf diesen befinden sich Daten aller Kindergeldempfänger inklusive Namen, Adressen, Geburtsdaten, Versicherungsnummern und der jeweilgen Bankverbindung (vgl. www.heise.de/newsticker/meldung/99315/).
Dezember 2006: Die Universität von Kalifornien meldet, dass ein Computerhacker in eine Datenbank eingedrungen war und Zugang zu persönlichen Informationen wie Namen, Adressen oder Sozialversicherungsnummern von nahezu 800.000 Studenten, Dozenten und Beschäftigten hatte (vgl. www.heise.de/newsticker/meldung/82437).
August 2006: Angreifern gelingt der Einbruch in ein internes Computersystem des Telekommunikationsunternehmens AT&T. Hierdurch können die persönlichen Informationen und Kreditkartendaten von ca. 19.000 Kunden erbeutet werden (vgl. www.heise.de/newsticker/meldung/77455).
April 2005: "Unbekannte" stehlen die Kreditkartendaten von ca. 1,4 Millionen Kunden der Einzelhandelskette DSW Shoe Warehouse (vgl. www.heise.de/newsticker/meldung/58733).

Angesichts dieser Beispiele, den skizzierten Risiken und den rechtlichen Verpflichtungen gegenüber Mitarbeitern, Gesellschaftern oder Dritten im Umgang mit Unternehmensdaten sollte Informationssicherheit im Rahmen eines effektiven Security Managements grundsätzlich als Aufgabe der Unternehmensführung aufgefasst werden.

Java Data Objects (JDO)

Die Java Data Objects-Spezifikation wurde im Rahmen des Java Community Process (JCP) im Mai 2002 verabschiedet und stellt in der aktuellen Version 2.0 Entwicklern ein einheitliches und transparentes Framework für den Zugriff auf persistente Objekte zur Verfügung in das sich sowohl beliebige Datenhaltungssysteme wie objektorientierte und relationale Datenbankbanken als auch Resource Manager (Enterprise Information Systems) integrieren lassen.

Die JDO-Spezifikation umfasst neben dem Standard zustäzlich eine Referenzimplementierung, die jedoch ausschließlich einer nicht kommerziellen Nutzung vorbehalten ist sowie eine Testumgebung (Technology Compatibility Kit), welche die Kompatibilität von JDO-Implementierungen gegenüber dem Standard sicherstellt. Die kommerzielle oder auch freie Entwicklung von JDO-Implementationen übernehmen sogenannte JDO Vendors, denen die konkreten Details der Umsetztung, wie z.B. Anzahl und Typen der unterstützten Datenbanken, Organisation des Mappings, etc. überlassen bleibt.

Die JDO-Spezifikation definiert als primäre Anwendungsschnittstelle den PersistenceManager, der Methoden zur Verwaltung persistenzfähiger Objekte zur Verfügung stellt und zur Erzeugung von JDOQuery- und Transaction-Instanzen dient. Durch Implementierung des PersistenceCapable-Interfaces werden transiente Java Klassen in persistenzfähige Klassen überführt. Hierzu sieht der Standard u. a. den Einsatz von technischen Werkzeugen vor, die den Quell- oder Bytecode entsprechend erweitern ("Reference Enhancement").

Die Java Data Object-Spezifikation zeichnet sich insbesondere durch die Eigenschaften transparente Persistenz, Datenbank Unabhängigkeit, Persistenz durch Erreichbarkeit (Persistenz by reachability), Integrationsmöglichkeit in unterschiedliche Plattformen (J2EE) sowie einer java-orientierten Anfragesprache (JDOQL) aus. Mit zahlreichen auf dem Markt verfügbaren Implementationen besitzt JDO gegenüber vergleichbaren Spezifikationen wie etwa dem ODMG-Standard einen wichtigen Vorteil: Die Akzeptanz durch die Hersteller und damit die Umsetzung der Spezifikation in reale Produkte.

Trotz der auf den ersten Blick ersichtlichen Vorteile existieren auch einige Vorbehalte gegenüber JDO. Dies galt inbesondere für die vorhergehende Version 1.0.1 der JDO-Spezifikation. Die Kritik bezog sich hier u. a. auf die JDOQL-Anfragesprache (eingeschränkte Funktionalität, keine Projektion, fehlende Aggregatfunktionen sowie erst zur Laufzeit erkennbare semantische Fehler), den Prozess des Reference Enhancements (zusätzlicher Schritt im Entwicklungsprozess der u. U. nachteilig auf die Neutralität des Codes wirken kann), keine automatisch verwalteten bidirektionalen Objektbeziehungen und ein mangelhaftes bzw. fehlendes Sicherheitsmodell (siehe auch Korthaus und Merz, A Critical Analysis of JDO in the context of J2EE).

In der aktullen Version von JDO (2.0) wurden diese Vorbehalte durch zahlreiche Erweiterungen berücksichtigt. Entsprechend wurde die JDOQL-Anfragesprache erweitert, ein einheitliches Mapping für relationale Datenbanken festgelegt sowie eine Operation zum ab- und ankoppeln persistenter Objekte vom PersistenceManager (Detach/Attach) integriert. Insbesondere die vorhandenen Sicherheitsdefiziete wurden jedoch nicht behoben (vgl. JDOSecure).

High Performance Computing

Das IPACS-Projekt wird vom Bundesministerium für Bildung und Forschung (BMBF) im Rahmen des Progammes "High-Performance-Computing" gefördert. Derzeit sind folgende Partner an diesem Projekt beteiligt: Fraunhofer-ITWM, T-Systems (Solutions for Research GmbH), Universität Mannheim (Rechenzentrum), Universität Rostock (Technische Informatik).

Aufgrund des anhaltenden exponentiellen Wachstums der Leistungsfähigkeit von Computern und der zunehmenden Bedeutung von PC-Clustern muss eine neue Grundlage für Systembenchmarks, wie beispielsweise NPB, geschaffen werden. Zum gegenwärtigen Zeitpunkt fehlen zuverlässige Systembenchmarks (abgesehen von dem bei TOP500 verwendeten LINPACK Benchmark), welche den Benutzer in der Bewertung und Anschaffung von Computersystemen, insbesondere Parallelrechnern, unterstützen.
In Zusammenarbeit mit dem Lawrence Berkeley National Laboratory (LBNL, USA) und dem National Energy Research Scientific Computer Center (NERSC, USA) will IPACS eine neue Grundlage für Systembenchmarks von verteilten Computersystemen schaffen. Die folgenden Punkte stellen die Hauptarbeitspakete von IPACS dar:

Entwicklung und Verteilung von skalierbaren, portablen und realistischen Benchmarks
Entwicklung von Verfahren zur Bewertung Anwendungssoftware- und Hardware-spezifischer Parameter
Performance-Vorhersage kommerzieller Codes und
Werkzeuge zur Unterstützung der Benutzer.

IPACS verfolgt das Ziel, Bewertungsmethoden auf Grundlage neuer Anwendungen, Low-Level- und Grid-Benchmarks zu entwickeln, sowie eine Vorhersage der Systemperformance zu ermöglichen. Diese Methoden sollen Anwendern helfen, ihre System-Performance zu optimieren. Ein wesentlicher Punkt der neuen Benchmarkumgebung soll die einfache Nutzbarkeit der Benchmarks durch den Anwender sein. Dazu sind Mechanismen für die automatische Installation und Ausführung der Benchmarks vorgesehen.

Die Top500-Liste der weltweit leistungsstärksten Computer für technisch-wissenschaftliche Anwendungen wurde im Frühjahr 1993 erstmals ermittelt und wird seitdem halbjährlich im Wechsel in den USA und Deutschland präsentiert.

Bei der ersten Liste im Juni 1993 führte eine CM-5 von Thinking Machines mit knapp 60 GigaFlops und das letzte System auf Rang 500, eine Fujitsu VP-200, erreichte 0,4 GigaFlops. Ab Juni 2002 führte die Liste der japanische Earth Simulator von NEC mit 36 TeraFlops für viele Jahre unangefochten an und steuert damit alleine 10 Prozent der weltweiten Gesamtleistung bei. Seit November 2005 belegt das IBM-System BlueGene/L (USA, Livermore) mit einem Rmax von 280 TeraFlops den ersten Platz.

Die TOP500-Liste wird durch die Performance der HPC-Systeme bestimmt, die mit Hilfe des skalierbaren Linpack-Benchmarks gemessen wird. Die Linpack-Leistung hängt allerdings i. a. nur von der Geschwindigkeit der Prozessoren, nicht jedoch von der Performance des Kommunikationssystems ab, die jedoch für realistische Anwendungen ebenfalls von Bedeutung ist. Ausgehend von dieser Kritik am Linpack-Benchmark versucht das IPACS-Projekt mit der Entwicklung neuer Anwendungs-, Low-Level- und Grid-Benchmarks, eine realistischere Bewertung vorzunehmen.

SAP-R/3 und Java

Der SAP Java Connector (JCo) stellt als Java-Sprachanbindung eine Schnittstelle für SAP-Systeme bereit. JCo ermöglicht einerseits den inbound Zugriff auf ABAP-Module und gestattet andererseits den Zugriff aus SAP-Systemen auf Java-Anwendungen (outbound). Näher betrachtet erfolgt der Zugriff über die Funktionen der SAP RFC-Bibliothek. Dazu implementiert JCo eine zusätzliche Sprachschicht in Java, die über das Java Native Interface (JNI) den Zugriff auf die RFC-Bibliothek realisiert.

Über die RFC-Schnittstelle können innerhalb eines SAP-Systems Methoden sogennanter Business Objects aufgerufen werden. Business Objects repräsentieren eine eigenständige Geschäftseinheit und können vereinfacht als Untermenge RFC-fähig markierter ABAP-Bausteine (RFC-enabled Function Modules) betrachtet werden. Der Aufruf erfolgt letztlich über das Business Application Programming Interface (BAPIs).

Soll JCo zur Kommunikation mit SAP R/3 eingesetzt werden, muss als erstes eine Verbindung zum SAP-System aufgebaut werden. Mittels JCO.Client wird eine direkte Verbindung hergestellt. Durch die Verwendung von JCO.Pool wird eine freie Verbindung aus einem Verbindungspool bereitgestellt. Im nächsten Schritt wird ein JCO.Function-Objekt erzeugt das ein entsprechendes BAPI-Objekt mit dessen Parametern und Rückgabewerten vertritt. Die dazu nötigen Informationen werden durch das SAP Business Object Repository des verbundenen SAP R/3-Systems bereitgestellt. Nach setzten entsprechender Import-Parameter erfolgt ein Funktionsaufruf und die Auswertung der Rückgabewerte sowie anschließend das Beenden der Verbindung.