Effizientes Performancemanagement. Deutschland 7,50. Rundumerneuerung. Flex 4 mit Java. Frischer Wind für Java-RIAs. Android Security » 92

Transkript

1 inkl. JAVA Mag Java Magazin You spoke. We listened. Introducing Liferay Enterprise Edition. CD Spring 3.0 Spring Roo Oracle Fusion 11g Liferay Enterprise Edition gives you all the benefits of open source with the stability, security, and reliability of an enterprise subscription. Android And with version 5.1, get the latest in SOA, Social Networking, and Collaboration technology, all at a fraction of the cost of Oracle or IBM. Flex 4 mit Java Liferay 5.1 Enterprise Edition Maintenance Subscription EUR / server / year Platinum Support (24x7) EUR / server / year Compare Oracle WebCenter Suite: EUR / processor, support EUR / yr, as of 6 / 2008 Domain-driven Design Session von der JAX 2009 in voller Länge DIE HIGHLIGHTS Spring Roo: Das neue SpringSource-Projekt Flex 4: Freies WEITERE INHALTE Apache JMeter Spring Framework Java Twitter Alle CD-Infos ab Seite 3 EUROPEAN HEADQUARTERS - LANGEN, GERMANY magazin SOA-Architekturen JavaFX-Tutorial Wie kommt man zu passenden Services? 108 Teil 3: Was taugt der Twitter-Client in der Praxis? 24»» Alle Infos zur Konferenz siehe Beihefter Spring 3.0 Neue Features auf einen Blick» 48 Spring Roo: Codegenerierung the Spring Way Interview mit Jürgen Höller: Spring 3 ist flexibler als Java EE 6. Oracle Fusion 11g Rundumerneuerung» 62 Flex 4 mit Java Frischer Wind für Java-RIAs LIFERAY GMBH ROBERT - BOSCH - STRASSE 11, LANGEN, GERMANY TEL: (0) Ý FAX: (0) Österreich 8,60 Schweiz sfr 15,80 Framework für RIAs RiftSaw For more information, us at sales@liferay.com. Deutschland 7,50» 85 Java Architekturen SOA Agile CD-INHALT Now get the best of both worlds. Effizientes Performancemanagement» 36 Android Security Sicher ist sicher» 92» 54»57

2 SOA Center SOA aus dem wahren Leben Teil13 Data Access Services oder: Wie komme ich an meine Daten? Automatisch ablaufende Prozesse arbeiten auf Daten, die bereits in den verschiedensten Systemen vorhanden sind. Auf dem Weg zu einer SOA ist es wichtig, eine einheitliche Vorgehensweise zu entwickeln, wie diese bestehenden, datenliefernden Systeme eingebunden werden. von Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig und Torsten Winterberg Sonderheft Alle Artikelteile auf einen Blick finden Sie im neuen Sonderheft SOA Spezial! n diesem Artikel beschäftigen wir uns mit den Herausforderungen im Umgang mit verteilten Daten in einer SOA. Für die Umsetzung von Datenservices unterscheiden wir je nach Kontext zwischen automatisch erzeugten Datenzugriffsservices und solchen, die auf bestehenden Applikations-APIs aufsetzen. Wir beleuchten, wie in einer verteilten Anwendungslandschaft Transaktionalität sichergestellt werden kann. Daten in Applikationen und in einer SOA Eine SOA geht einen Schritt weiter: Die nach außen sichtbaren Datenservices (Wir haben sie im Artikel Servicekategorien, S.34, Business Entity Services, BES genannt) exponieren jeweils einen zusammenhängenden Ausschnitt der Gesamtdaten auf Entitätenebene (Kunde, Vertrag etc.) und abstrahieren vollkommen, woher die Daten kommen: Oft stammen diese Daten aus mehreren Datenbanken oder sogar aus mehreren Systemen. Mismatches zwischen Datendialekten werden über einen ESB aufgelöst, möglichst in Richtung eines einheitlichen, kanonischen Datenmodells. Aus dieser Verteilung ergeben sich Herausforderungen nicht nur an das Design, sondern auch für die Organisation: Applikationen können nicht mehr direkt miteinander Daten austauschen, sondern sollten das über einen zentralen Data Access Layer tun. Sind wir bereit, die Aufwände, die mit der SOAfizierung einer Applikationslandschaft einhergehen, mitzutragen? Stellen wir uns dieser Aufgabe als Gesamtunternehmung? Oder bleiben wir mit unserer kleinen SOA-Lösung auf einer Insel, die neben den monolithischen Inseln ein isoliertes Dasein fristet? Es ist eine Frage der Hoheit: Erst wenn nicht mehr die Applikationen und ihre APIs, sondern die SOA-Services die Einsprungspunkte für das Benutzen von 100 javamagazin

3 Daten und Funktionen sind, werden sich die Vorteile einer SOA verwirklichen: ein Bausteinkasten aus Funktionalität und Daten, der sich leicht zu neuen Lösungen zusammenbauen lässt. Um zu einer informierten Entscheidung zu gelangen, welcher Weg der richtige ist, betrachten wir nun die möglichen Lösungen, um zu einer wirklich serviceorientierten Architektur zu gelangen. Abb. 1: Klassischer Datenzugriff Abb. 2: Datenzugriff in Enterprise SOA Data Access in SOA = Business Entity Service In den ersten Artikeln haben wir eine SOA-Architektur vorgestellt, in der automatische Geschäftsprozesse Business Process Services (BPS) aus Einzelschritten bestehen. Diese Einzelschritte sind als Business Activity Services (BAS) realisiert. Ein BAS arbeitet entsprechend dem Composite-Pattern auf atomaren Services. Diejenigen atomaren Services, die den Datenzugriff kapseln, heißen Business Entity Service (BES). Ein Business Entity Service (BES) kapselt Daten und Funktionalitäten einer logischen Businessentität (Kunde, Vertrag etc.) in einem bestimmten Kontext: organisationsweit, domänen- bzw. subdomänen- (abteilungs-)bezogen. BES sind damit möglichst lose gekoppelte Kernservices auf Entitätenebene. Das bedeutet zwangsläufig, dass ein BES vollständig die Basisfunktionalität eines Businessobjekts darstellt, inklusive entsprechender Basisgeschäftslogik, die an diesem Businessobjekt verankert ist. Die Ziele aller BES, also der Datenzugriffsschicht, sind das Sicherstellen der Anforderungen an das Transaktionsverhalten, besonders in Bezug auf Datenintegrität und Isolation, sowie die Abstraktion, und dadurch eine Änderbarkeit bis hin zur Austauschbarkeit der zugrunde liegenden Applikationsfunktionalität, ohne dass Konsumenten von den Änderungen betroffen sind. BES wirken somit als abstrahierende Fassade auf die physische Datenhaltung, die Abstraktion erfolgt über Private Services (Abb. 3). Unterschiedliche Ausgangssituation Da es je nach Kontext völlig unterschiedliche Lösungsansätze gibt, teilen wir die Projektwelt in grüne Wiese und Sumpf ein. Das Ziel ist in beiden Fällen ein erschlossenes Baugelände. Anzeige Artikelserie: SOA aus dem wahren Leben Teil 01: Rent your car Service-oriented (Use Case) Teil 02: SOA Blueprint Ein Werkzeugkasten für Architekten Teil 03: SOA-Bausteine im Kontext konkreter Projekte von klein nach groß Teil 04: Servicekategorisierung Teil 05: Lose Kopplung Teil 06: Service Requirements Teil 07: Governance Organizational Change Teil 08: SOA Security Teil 09: SOA Pattern 1: Compensation Teil 10: SOA Pattern 2: Benutzeroberflächen und SOA Teil 11: SOA Pattern 3: Kanonisches Datenmodell Teil 12: Change Management Teil 13: Data Access Teil 14: Event-driven SOA

4 SOA Center SOA aus dem wahren Leben Teil13 Abb. 3: Implementierung von BAS und BES am RYLC- Beispiel Abb. 4: Isolierte Daten in Grüner-Wiese-SOA Auf der grünen Wiese können wir starten und uns eine perfekte SOA-Welt nach unserem Gusto bauen, ohne uns über bestehende Applikationen Gedanken machen zu müssen. Existiert jedoch eine noch nicht agile, heterogene Applikationslandschaft, verhält diese sich wie ein dreckiger Sumpf, der erst trockengelegt und bebaubar gemacht werden muss. Diesen Prozess des Trockenlegens nennen wir SOAfizieren einer Applikationslandschaft. Dabei werden existierende Applikationen in ihrer interner Struktur auf die neu gestellten Anforderungen umgebaut und mit SOA-Business-Service-Schnittstellen versehen, die die im Artikel Von klein nach groß (S. 25) beschriebenen Serviceeigenschaften aufweisen. Grüne Wiese Eines der Hauptprobleme in einer existierenden Applikationslandschaft ist, dass Daten redundant in verschiedenen Datenbanken liegen. Damit gehen große Herausforderungen im Umfeld der Transaktionssicherheit einher. Besonders die Isolation und die Datenintegrität sind nur mit hohem und teurem Aufwand sicherzustellen. Auf der grünen Wiese können wir diesem Mechanismus begegnen und im Design fordern, dass ein BES immer nur auf genau einer Datenbank arbeitet. Damit ist der Aufwand für die Datenaspekte einer SOA dramatisch gesunken. In einem Projekt, das eher im Umfeld des Sumpfs anzusiedeln ist, sahen wir, dass ca. 60 % der Aufwände und Kosten sich daraus ergeben, die oben genannten Transaktionsanforderungen im Umfeld redundanter, aber voneinander abhängiger Daten in verschiedenen Datenbanken umzusetzen. Abb. 5: Ein ESB stellt die BES-Schnittstelle zur Verfügung und verwendet private Services zur Implementierung CRUD-Services: Die DB als Service Moderne Werkzeuge generieren sehr einfach aus Datenbanktabellen oder SQL-Statements automatisch Web Services, um CRUD-Operationen als Web Services bereitzustellen. Als CRUD- Services bezeichnet man Web Services, die das Anlegen, Lesen, Verändern und Löschen von Daten ermöglichen. CRUD-Services sind ein guter Start in einer SOA auf der grünen Wiese, in der wir Applikationslogik und Datenbanken von Grund auf gestalten können. In einer SOA auf der Basis einer Sumpf -Situation werden wir selten über SQL oder Stored Procedures direkt an die Daten gelangen, diese sind über APIs gekapselt. Lösungen in derartigen Kontexten beschreiben wir weiter unten. CRUD-Services und lose Kopplung Sind CRUD-Services bereits vollgültige Services auf Datenzugriffsebene? In einer lokalen SOA mag das ausreichen. Wenn wir eine Enterprise SOA zum Ziel haben, ist Vorsicht geboten: Würde man CRUD-Services direkt als BES bereitstellen, führte das zu einer engen Kopplung zwischen Applikation und Datenhaltung. Die generierten BES verwenden dann eine auf die Datenquelle abgestimmte Datenstruktur und Änderungen bzw. Datenstrukturanpassungen würden sich direkt auf alle Konsumenten durchschlagen und die von den nativen Systemen vorgegebenen Datentypen würden sich in der Abstraktionsschicht auf unerwünschte Weise fortpflanzen. Nichtsdestotrotz kann man generierte CRUD-Services sehr gut innerhalb von BES nutzen, solange sie nicht direkt von Service-Consumern oder aus Geschäftsprozessen heraus aufgerufen werden. So sind generierte CRUD-Services mit ihren proprietären Schnittstellen ein Implementierungsdetail der Public BES, die mit einer wohl definierten Top-Down-Schnittstelle ausgestattet sind. Vom CRUD-Service zum BES Die enge Kopplung von BES zu der zugrunde liegenden Datenspeicherung lässt sich durch Indirektion auf Datenebene mithilfe des kanonischen Datenformats verhindern. Wir bilden deshalb einen Wrapper um die aus Datenbanken generierten CRUD-Services. Dieser realisiert das Adapter-Pattern, also das Anpassen der öffentlichen Schnittstelle des BES an die proprietäre Schnittstelle des CRUD-Services. Der Adapter-Service-Kontrakt, also die nach außen exponierte Schnittstelle des BES, wird unter Verwendung der kanonischen Datentypen Top-Down 102 javamagazin

5 SOA aus dem wahren Leben Teil13 SOA Center Abb. 6: BES arbeitet auf privatem CRUD- Service modelliert. Die Integrationslogik erfolgt dann im ESB durch Anwenden des VETRO-Pattern (Validate, Enrich, Transform, Route, Operate) Auf diese Weise erreichen wir im Fall der grünen Wiese recht trivial eine konsistente Datenzugriffsschicht. Sumpf In der Regel entsteht eine SOA nicht auf der grünen Wiese. Bestehende Anwendungen halten meist eine eigene Datenzugriffsarchitektur bereit, die sich für jedes System unterscheiden kann. Betrachten wir daher Lösungen für die Ausgangslage, in der wir eine SOA auf der Basis bestehender Applikationen erstellen. APIs als private Datenservices Wenn wir keine direkten Datenzugriffe über CRUD-Services erstellen können, da wir kein Interface direkt zu den Da- tenbanken haben, können wir im Idealfall bestehende Applikations-Wrapper- Services nutzen, die den Datenzugriff aus den bestehenden Applikationen über APIs kapseln. Diese Wrapper-Services werden dann innerhalb der BES genutzt. Im Gegensatz zur CRUD-Anwendung lassen diese APIs den direkten Datenbankzugriff, etwa mittels SQL, nicht zu, sondern bieten eine Abstraktionssicht. Ein bekanntes Beispiel sind die BAPIs von SAP, die über Wrapper-Services angebunden werden können. Problem: APIs enthalten nicht nur Datenzugriffslogik Die Welt wäre in Ordnung, wenn bestehende Applikationen den Zugriff auf die Daten, die sie kapseln, in Reinform, etwa als CRUD-Services, anbieten würden. Viele der APIs von ERP-Systemen wie SIEBEL, SAP oder andere Applikationen sehen auch tatsächlich wie unschuldige CRUD-Services mit Funktionen wie lege Kunden an aus. Leider enthalten diese API-Funktionen aber oft Geschäftslogik. Das Anlegen eines Kunden im CRM-System kann gleichzeitig einen Prozess beinhalten, der die Genehmigung über mehrere Benutzerinteraktionen regelt. Diese Geschäftslogik steht im architektonischen Wiederspruch zu der Servicekategorie Business Entity Service (BES). Sie wird daher schnell zu Seiteneffekten führen. Aus diesem Abb. 7: BES arbeitet auf privatem API- Service Abb. 8: BAS arbeitet auf API Grund ist es wichtig, pro System ein Servicekonzept zu erarbeiten, das den Umgang mit Daten beinhaltet. Damit geht ein Auflösen von Seiteneffekten und Abhängigkeiten auf Datenebene zwischen Applikationen einher sowie das Bereitstellen von Funktionen, die ausschließlich Datenzugriffslogik auf die Applikationen enthalten. Diese Anzeige javamagazin

6 SOA Center SOA aus dem wahren Leben Teil13 Abb. 9: Transaktionalität mit verteilten Systemen Abb. 10: BES ohne Wächterfunktion Aufgaben sind oft einer der aufwändigsten Aspekte bei der SOAfizierung einer bestehenden Applikationslandschaft. API- und Datenzugriff auf Activity-Service-Ebene Wenn die beschriebene SOAfizierung zu aufwändig ist und sich nicht durch ein Geschäftsziel vermitteln lässt, besteht eine Alternative darin, auf die kanonische Datenzugriffsschicht zu verzichten und direkt auf Einzelaktivitätsebene auf die APIs durchzugreifen. Dabei wird auf die Etablierung der BES verzichtet. Damit gehen aber die Vorteile verloren, die sich aus einem gemanagten zentralen Datenzugriffs-Layer ergeben. Architekturbetrachtung: BES und berechnete Daten In dieser Diskussion schwingt eine der Haupt-SOA-Herausforderungen mit, die bei uns für einige Hirnverrenkungen sorgt: Wenn BES den Zugriff auf Daten kapseln, was ist mit abgeleiteten Daten, zu deren Berechnung komplexe Geschäftslogik oder gar ein Workflow mit Benutzerinteraktion gehört? Die befriedigendste Lösung besteht darin, BES wirklich nur aus puren Datenzugriffen bestehen zu lassen und wenn komplexere Dinge geschehen, Wenn BES den Zugriff auf Daten kapseln, was ist mit abgeleiteten Daten? diese in einen Business Activity Service (BAS) hochzuziehen, der konzeptionell zu der selben Entität gehört. Ein klassisches Beispiel ist das boolesche Attribut kreditwürdig der Entität Kunde. Die Belegung dieses Attributs kann beliebig komplex sein. Die Operation ermittle- Kreditwuerdigkeit sollte also nicht auf BES, sondern auf BAS-Ebene liegen. Der entsprechende BAS ruft, nachdem er die Kreditwürdigkeit geprüft hat, den Kunde-BES auf und übergibt das Ergebnis, das schließlich durch den BES persistiert wird. Transaktionen mit verteilten Systemen Ein BES hat die Datenhoheit, er kapselt also den Datenzugriff für eine Entität und ist dafür verantwortlich, dass Basisanforderungen an das Transaktionsverhalten eingehalten werden können. Besonders spannend sind dabei die Themen Datenintegrität und Isolation, da bei lose gekoppelten SOA-Systemen übergreifende technische Transaktionen, wie wir sie von Datenbanken her kennen, nicht möglich sind. Ein Szenario aus unserer Autovermietung RYLC: Fahrzeugdaten werden in zwei Applikationen mit zwei Datenbanken angelegt. Der BES muss selbst sicherstellen, dass niemals Wagen-IDs in einem der beiden Systeme existieren, die nicht auch im anderen existieren (Datenintegrität) und niemals ein Fahrzeugsatz schreibend bearbeitet wird, der gerade in einer der Applikationen bearbeitet wird (Isolation). Abb. 11: Isolation mit Cache Datenintegrität: Transaktionssteuerung Die beschriebenen API-Funktionen aus den bestehenden Applikationen sind in der Regel so designt, dass sie das alleinige Zugriffsrecht auf die Daten haben, auf denen sie arbeiten. Das kollidiert mit der Vorstellung von Activity-Services, die auf Basisfunktionen aus BES 104 javamagazin

7 SOA aus dem wahren Leben Teil13 SOA Center arbeiten und dabei Daten austauschen. Die RYLC-Wagenbestandsystem-API- Operation pruefewagenverfuegbarkeit etwa kapselt alle Daten, auf denen sie arbeitet und arbeitet auf internen Datenbeständen des Wagenbestandsystems. Es gehört zu den Anforderungen der Operation, dass sie garantiert, dass die gelieferte Ergebnismenge eine valide Menge darstellt, d. h. die gelisteten Wagen auch tatsächlich verfügbar sind. Im Sinne des API-Service bedeutet das, dass der Service auch die Hoheit über die Daten, die er bereitstellen muss, besitzt und somit konsistente und valide Daten liefern kann. Das wäre nicht der Fall, wenn an anderen Stellen im Gesamtsystem ebenfalls Fahrzeugdaten gehalten und verändert werden, über die unser Service pruefewagenverfuegbarkeit keine Information hat. Nun sind solche verteilten Datenbestände durchaus üblich und es entstehen Zugriffsund Konsistenzprobleme. Im Beispiel pruefewagenverfuegbarkeit müsste die Operation legefahrzeugan sicherstellen, dass die Wageninformationen in alle betroffenen Applikationen gelangen. Falls ein Transaktionsmanager auf SOA-Seite existiert und der angebundene Service mit WS-Transaction mit den einbezogenen Applikationen umgehen kann, könnte man diesem die Aufgabe überlassen, die Datenintegrität sicherzustellen. Das ist derzeit jedoch noch Zukunftsmusik, weshalb wir zu allen schreibenden Operationen der Applikationen eine commit- und eine kompensierende undo-operation anbieten müssen. Dabei stellt die schreibende Operation die Daten in einen Schwebezustand. Diese Daten sind nach außen noch nicht sichtbar. Erst wenn die letzte Applikation an den BES zurückmeldet, dass ihre Daten sicher gespeichert wurden, ruft der BES die commit-operation auf allen vorangegangenen schreibenden Funktionen auf. Diese überführen die Daten aus dem Schwebezustand in einen finalen persistenten Stand. Falls entlang der Aufrufe in einer Applikation etwas schiefgeht, ruft der BES die jeweiligen undo-operationen auf. Die Daten werden aus dem Schwebezustand entfernt. Was ist nun, wenn beim Commit in einer Applikation etwas schiefgeht? Abb. 12: Service Data Object (Graf inklusive ChangeSummary) Man könnte sich weitere Ebenen der Absicherung vorstellen, also ein Mehrphasen-Commit. Jedoch bewegen wir uns dann auf der Ebene, einen Transaktionsmanager nachzuprogrammieren, bei dem Entwicklungsaufwände explodieren können. Wir raten deshalb, stets die Wahrscheinlichkeit einer fachlichen Nebenläufigkeit den Aufwänden gegenüberzustellen und eventuell auch organisatorisch Transaktionssicherheit durch manuelle Korrekturmaßnahmen in Betracht zu ziehen. Datenintegrität: Datenhoheit und verteilte Daten Falls die API-Operation legewagenan des anderen Systems A für jedermann direkt benutzbar wäre, könnte man nicht ausschließen, dass jemand diese Operation benutzt und einen Wagen hinzufügt, der nicht in anderen Applikationen, etwa im Wagenbestandssystem bekannt ist. Die fachlichen Anforderungen an die Operation pruefewagenverfuegbarkeit wären damit verletzt. Daher ist es notwendig, den schreibenden Zugriff auf die Kernentitäten zentral in BES zu kapseln, um sicherzustellen, dass die neu erstellten Services ihre fachlichen Anforderungen an Datenintegrität erfüllen. Das bedeutet, jeder schreibende Zugriff muss über das entsprechende BES erfolgen und darf nicht mehr als direkte Kommunikation zwischen einzelnen Applikationen geschehen. Wir sind uns darüber im Klaren, dass die Forderung eines Single Point of Entry, also eines globalen Datenwächters für Kernentitäten, für große bestehende Applikationslandschaften mit stark interagierenden Altsystemen ein Problem darstellt. Das Auflösen dieser Abhängigkeiten ist oft eine mehrjährige Aufgabe im Rahmen eines SOAfizierungs- Programms. Ein Weg, relativ schnell Datenintegrität wenigstens ansatzweise zu erlangen, besteht in einem Event-getriebenen Design: Die direkten Aufrufe der Datenmanipulation werden um ein Change Event erweitert, das den BES über entsprechende Veränderungen aufgrund schreibender Zugriffe informiert. Der BES kann dann die entsprechenden Anzeige

8 SOA Center SOA aus dem wahren Leben Teil13 schreibenden Zugriffe auf den anderen Applikationen vornehmen. Isolation Ein RYLC-Kunde interessiert sich für ein Auto. Er entscheidet sich für ein bestimmtes Modell, das nur noch einmal im Bestand ist und befindet sich in den Formalitäten des Ausleihprozesses. Für die Dauer dieses Prozesses sollte dieses spezielle Auto für den Zugriff anderer Interessenten gesperrt sein. Dieses Beispiel verdeutlicht, dass unsere BES oft sicherstellen müssen, dass Daten, die gerade in Bearbeitung sind, für den Zugriff weiterer Servicekonsumenten gesperrt sein sollen man spricht von Isolation. Diese Anforderung wird in einer SOA oft durch Status-Flags realisiert. Alle Zugiffsservices wissen, welche Daten gerade in Arbeit sind. Bei schreibenden Zugriffen fragt der BES nach, ob die Instanz der Entität, die der Konsument bearbeiten möchte, gerade in Arbeit ist und daher gesperrt werden sollte. Ist das der Fall, weist der BES die Anfrage ab und informiert den Konsumenten entsprechend. Integrität: Kontextabhängige Datenservices Wir benötigen ein Status-Flag etwa Kundensatz ist im System angelegt, jedoch noch nicht zur weiteren Verarbeitung freigegeben. Diese Flags muss der BES und alle sonstigen Zugriffsfunktionen kennen und entsprechend auswerten. Übertragen auf unser RYLC- Beispiel wird beim Autoreservierungsprozess im ersten Prozessschritt ein neuer Kunde angelegt. Dieser Kunde darf Takeaways CRUD-Services sind praktischer als private Services, deren Contract sollte aber niemals als public Service bereitgestellt werden Datenservices sollten nur an unterster Stelle verwendet werden und keine Geschäftslogik beinhalten vom Autoreservierungssystem erst dann verwendet werden, wenn die Schufa- Anfrage erfolgreich war. Dagegen muss der Kunde in der Serviceanwendung des Callcenters sofort sichtbar sein. Der Data-Access-Service findcustomerby- Id() ist also kontextabhängig und kann deshalb nicht global publiziert werden. Wir empfehlen, hier für jeden Typ einen separaten Service mit eindeutigem Bei SDOs als Datenhalter zwischen Services müssen weniger Daten versendet werden. Kontrakt zu implementieren: findunrestrictedcustomerbyid() und findunrestrictedandrestrictedcustomerbyid(), diese können mit dem Public-Attribut versehen werden, im Gegensatz zu dem generalisierten internen Service findcustomerbyid(id, Flag). Datenaktualität mit SDO Bei lang laufenden Prozessen können schnell Dateninkonsistenzen auftreten: Ein BES erhält eine Anfrage und stellt eine Antwortnachricht zusammen, etwa zu einem Kunden und seiner Adresse. Diese Nachricht wird von einem Prozess verarbeitet, er schickt etwa eine Ware an diesen Kunden. Sollte der Kunde nun anrufen und eine Adresskorrektur durchgeben, ist es für den Prozess zu spät, er arbeitet auf veralteten Daten. Hier setzt der Standard Service Data Object (SDO) an. Die Idee ist, dass ein Service, etwa ein Geschäftsprozess, nicht auf historischen Daten arbeitet, sondern auf einem Pointer in die physische Datenhaltung. In der Service-Data-Object-Welt gibt es zwei grundlegende Konzepte: Der Data Access Service ist für die Bereitstellung von Daten verantwortlich und implementiert auch die Funktionen, um veränderte Daten wieder in die Ursprungssysteme zurückzubringen. Das Service Data Object, das nicht nur Daten in Form eines hierarchischen Baums hält (z. B. Angestellter Adresse Straße), sondern auch eine so genannte Change Summary, die Veränderungen dokumentiert (z. B. eine neu angelegte Straße). SDO beschreiben Daten mit XSDs. Während Servicekonsumenten wie auch -provider entweder auf einem POJO oder dem generischen SDO arbeiten, wird XML automatisch als Transport verwendet. Somit ist SDO ein hervorragender Mittler zwischen der programmatischen Welt der in Java geschriebenen Geschäftslogik und der des Datenaustauschs, der in XML erfolgt. Wenn SDOs als Datenhalter zwischen Services verwendet werden, müssen weniger Daten versendet werden. Es wird nicht das ganze Objekt, beziehungsweise eine große XML-Nachricht versendet, sondern jeweils nur die Change Summary. Durch das implizite Versionskonzept in SDO kann das Data-Management-System hier schnell reagieren und sicherstellen, dass der Servicekonsument seine Änderungen auf der aktuellen Datenbasis vornimmt. Integrität: Schlüsselverwaltung Datenservices müssen Objekte mit eindeutigem Schlüssel liefern, die über den gesamten Lebenszeitraum eines Objekts Gültigkeit haben. Bedingt durch die verteilte Speicherung von Objekten ist das Anwenden des Foreign-Key-Konzepts mit Datenbank-Constraints nur innerhalb einer Domäne sinnvoll. Externe Referenzen sind durch übergreifende Schlüssel und externe Validierungsmechanismen umzusetzen. Eine übergreifenden Schlüsselgenerierung und das Führen eines Versionsattributs nimmt in der verteilten Datenhaltung eine besondere Stellung ein. Die automatische Vergabe der Schüssel durch die DB beim Commit ist meist ungeeignet, da Objektreferenzen damit kaum synchron gehalten werden können. Das Platzieren eines globalen Sequenzgenerators hat sich hier durchgesetzt. Fazit Wir haben aus unserer Sicht die Themen adressiert, die uns in Projekten am häufigsten begegnet sind, konnten jedoch 106 javamagazin

9 Impressum SOA Center nicht alle Aspekte betrachten. Hier haben wir gesehen, dass die Herausforderungen für das Datenmanagement in einer SOA davon abhängen, inwieweit heute Systeme bestehen, die direkt miteinander Daten austauschen und deren Daten voneinander abhängen. Erst das Auflösen dieser Abhängigkeiten führt zu einer übergreifenden SOA und den damit verbundenen Vorteilen. Verlag: Software & Support Verlag GmbH Anschrift der Redaktion: Java Magazin Software & Support Verlag GmbH Geleitsstraße 14 D Frankfurt am Main Tel. +49 (0) Fax. +49 (0) Berthold Maier arbeitet als Chefarchitekt für Oracle Consulting Deutschland und hat mehr als 15 Jahre Erfahrung als Entwickler, Coach und Architekt im Bau von komplexen Enterprise-Anwendungen und Integrationsszenarien. Seit 2006 hat er die Rolle des Chefarchitekten für die gesamte deutsche Consulting-Organisation übernommen und ist in dieser Rolle verantwortlich für Referenzarchitekturen rund um Integration, Java EE und die hauseigenen Entwicklungsframeworks. Berthold ist bekannter Konferenzsprecher, Buch- und Artikelautor. Hajo Normann ist SOA/BPM-Architekt bei EDS. Er beschäftigt sich als Autor und Konferenzsprecher mit dem Zusammenspiel automatischer Geschäftsprozesse und SOA Services, die in die Gesamtbebauung eines Unternehmens greifen, sowie mit den architektonischen und organisatorischen Herausforderungen, die mit der Einführung einer Enterprise SOA einhergehen. Hajo ist Oracle ACE Director und leitet zusammen mit Torsten Winterberg die DOAG SIG SOA. Bernd Trops ist Leiter Consulting bei der SOPERA GmbH. In dieser Funktion ist er für die Kundenprojektbetreuung und die SOPERA- Trainings verantwortlich. Als System Engineer war er in verschiedenen Projekten für GemStone, Brokat und WebGain tätig und verfügt daher über umfangreiche Erfahrungen im Bereich J2EE. Von 2003 bis 2007 war Bernd Trops als SOA Architect bei Oracle beschäftigt. Er hat bereits auf vielen Messen und Kongressen zu SOA und Open Source gesprochen. Clemens Utschig-Utschig arbeitet im SOA-Suite-Product- Management-Team der Oracle Corporation. Er ist mitverantwortlich für die Strategie und die Entwicklung Richtung neuer Standards. Im Moment arbeitet er mit dem Fusion-Applications-Development-Team als dessen SOA-Architekt und Advisor. Er ist regelmäßiger Sprecher auf Konferenzen wie der Oracle Open World, der JAX und OOP und publiziert in englischprachigen Magazinen rund um SOA. Torsten Winterberg arbeitet als Direktor für Strategie und Innovation sowie als Leiter des Competence Centers SOA bei der OPITZ CONSULTING GmbH. Er ist bekannt als Autor von Fachartikeln und Sprecher auf diversen Konferenzen und besitzt langjährige Erfahrung als Trainer, Projektcoach und Architekt rund um die Erstellung von Java-EE-Anwendungen. Sein besonderes Interesse liegt im Design und der Entwicklung von komplexen IT-Systemen unter Berücksichtigung von BPM, BPEL, ESB, BAM sowie allgemein den serviceorientierten Architekturen. Links & Literatur [1] Hohpe, Gregor; Wool, Bobby: Enterprise Integration Patterns : [2] Introduction to Service Data Objects: [3] Clarke, Doug; Utschig, Clemens: Where has my data gone : Chefredakteur: Sebastian Meyen Redaktion: Claudia Fröhling, Hartmut Schlosser, Mirko Schrempp Chefin vom Dienst: Nicole Bechtel Schlussredaktion: Nicole Bechtel, Katharina Klassen, Frauke Pesch Leitung Grafik & Produktion: Jens Mainz Layout, Titel: Daniela Albert, Kristin Brockmann, Pobporn Fischer, Karolina Gaspar, Melanie Hahn, Yaman Andreas Lämmlein, Katharina Ochsenhirt, Maria Rudi, Patricia Schwesinger, Franziska Sponer CD/DVD-Erstellung: Daniel Zuzek Autoren dieser Ausgabe: Alphonse Bendt, Torsten Fink, Andreas Frey, Gerrit Grundwald, Rudolf Jansen, Klaus Kreft, Thomas Kruse, Angelika Langer, Berthold Maier, Florian Müller, Hajo Normann, Alois Reitbauer, Stefan Roock, Lars Röwekamp, Herrmann Schlamann, Volker Stiehl, Dalibor Topic, Bernd Trops, Clemens Utschig-Utschig, Matthias Weßendorf, Mike Wiesner, Torsten Winterberg, Eberhard Wolff Anzeigenverkauf: Software & Support Verlag GmbH Patrik Baumann Tel. +49 (0) Fax. +49 (0) pbaumann@javamagazin.de Es gilt die Anzeigenpreisliste Nummer 12 Pressevertrieb: DPV Network Tel.+49 (0) , Druck: PVA Landau ISSN: X Abo-Service: Software & Support Verlag GmbH Tel. +49 (0) Fax +49 (0) Abonnementpreise der Zeitschrift: Inland: 12 Ausgaben 79, Europ. Ausland: 12 Ausgaben 89, Studentenpreis (Inland) 12 Ausgaben 69, Studentenpreis (Ausland): 12 Ausgaben 79, Einzelverkaufspreis: Deutschland: 7,50 Österreich: 8,60 Schweiz: sfr 15,80 Erscheinungsweise: monatlich Software & Support Verlag GmbH Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktionen jeglicher Art (Fotokopie, Nachdruck, Mikrofilm oder Erfassung auf elektronischen Datenträgern) nur mit schriftlicher Genehmigung des Verlages. Jegliche Software auf der Begleit-CD zum Java Magazin unterliegt den Bestimmungen des jeweiligen Herstellers. Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz Prüfung durch die Redaktion vom Herausgeber nicht übernommen werden. Honorierte Artikel gehen in das Verfügungsrecht des Verlags über. Mit der Übergabe der Manuskripte und Abbildungen an den Verlag erteilt der Verfasser dem Herausgeber das Exklusivitätsrecht zur Veröffentlichung. Für unverlangt eingeschickte Manuskripte, Fotos und Abbildungen keine Gewähr. Java ist ein eingetragenes Waren zeichen der Sun Microsystems Inc. javamagazin