DATENBANK KNOW-HOW. Plus CD! ENTWICKLER UND DBAS: DATENBANK-PERFORMANCE: Java Magazin. Java Architekturen SOA Agile. CD-Inhalt

Transkript

1 Plus CD! Stellenmarkt 64 JavaFX 1.0: Die Finalversion ist da! Deutschland 7,50 Österreich 8,60 Schweiz sfr 15,80 Java Magazin Java Architekturen SOA Agile CD-Inhalt Java-Frameworks Google Guice 1.0 Swordfish Spring Framework 3.0 M1 Webportale JBoss Portal Liferay Portal 5.5 exo-portal 2.5 Apache Pluto Jürgen Höller: Spring 3.0 (WJAX 2008) DATENBANK KNOW-HOW Datenbank H2 (Hypersonic 2) Alle CD-Infos 3 Core Services à la OSGi Immer in Bewegung 14 Web Liferay 5.0 Portal auf Open-Source-Basis 20 JBoss Seam Workshop: Kickstart mit Seam 36 ENTWICKLER UND DBAS: So arbeiten sie optimal zusammen 104 SOA Center Sopera Open-Source-Server auf Eclipse-Basis 70 DATENBANK-PERFORMANCE: Die vernachlässigte JDBC-Ebene 53 D Web 27 Eclipse im Web: Rich Ajax Platform (RAP) Softwarehersteller sehen sich zunehmend vor die Aufgabe gestellt, sowohl Desktop- als auch Webclients zur Verfügung zu stellen. Diese basieren aber auf sehr unterschiedlichen Technologien, die auch unterschiedliche Programmierkenntnisse erfordern. Die Rich Ajax Platform (RAP) wurde entworfen, um diese Probleme für die Eclipse-Welt zu lösen.

2 SOA aus dem wahren Leben Teil IV Die SOA-Service- Kategorienmatrix Wie kommt man zu wirklich wiederwendbaren kanonischen Businessservices, die auf Funktionalität in einer heterogenen Systemlandschaft abgebildet sind? Die hier vorgestellte Kategorisierungsmatrix stellt einen Konzeptbaukasten dar, der Lösungen für typische Herausforderungen im Umfeld von größeren SOA- Initiativen gibt. Dieser Artikel soll ein Vokabular bieten, das sich in konkreten Projekten bewährt hat. von Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig und Torsten Winterberg nsere virtuelle Autovermietung Rent-your-legacy-Car (RYLC) möchte den Autoverleihprozess und die Zusammenarbeit mit dem neu eingeführten CRM-System automatisieren. RYLC s Artikelserie: SOA aus dem wahren Leben Chefarchitekt steht vor der Herausforderung, eine Begrifflichkeit für die verschiedenen Logikarten zu finden, die sich über Prozess-Engines, Integrationslösungen und existierende Systeme erstrecken. Der Versuch, die 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 + Use Case Teil 10: SOA Pattern 2: Benutzeroberflächen + Use Case Teil 11: SOA Pattern 3: Common Data Format + Use Case Teil 12: SOA Pattern 4: Dataaccess + Use Case Teil 13: SOA Anti-Pattern 1 Teil 14: SOA Anti-Pattern 2 Schichtenaufteilung aus objektorientierten Architekturen in die neue SOA- Architektur herüberzuretten, wird schnell als nicht vielversprechend erkannt: Sie bezog sich auf eine einzelne Applikation, während wir es bei einem übergreifenden SOA/BPM-Programm mit Geschäftsprozessen zu tun haben, die sich über mehrere Applikationen und Abteilungen erstrecken. Der Chefarchitekt kommt zum Schluss, dass es für Services je nach Art der (Wieder-) Verwendung unterschiedliche Architektur- und Governance-Vorgaben gibt. Zudem beeinflusst eine Gliederung und Strukturierung die Serviceanalyse, das Servicedesign und damit die Granularität maßgeblich. Auf Basis einer Kategorisierung kann die Einbindung von Services in eine Prozesslandschaft aus Nutzungssicht gesteuert und so ungewollte Verstrickungen vermieden werden. Die Erfahrung hat gezeigt, dass SOA-Architekturen schnell in Adapter-SOAs ohne klare 76 javamagazin

3 Verantwortlichkeit enden, wenn keine Kategorisierung eingeführt wird, und somit die Orchestrierung der Businessprozesse u. a. mit technologischen Serviceaufrufen vermischen und nicht kontrollierbare Aufrufzyklen entstehen. Um diesen Herausforderungen zu begegnen, soll dem SOA-Architekten ein Vokabular für unterschiedliche Servicearten an die Hand gegeben werden, und es soll aufgezeigt werden, welche Möglichkeiten es gibt, Services einzuteilen. Die folgende SOA-Service-Kategorisierungsmatrix (Abb. 1) stellt die in diesem Artikel vorgestellten Konzepte in einen Gesamtzusammenhang. Wir werden zunächst die wichtigsten Servicekategorien für fachlich motivierte, über eine Registry (z. B. UDDI) publizierte Services einführen, die wir zur Gruppe der Public Business Services zählen. Weiter unten werden wir erläutern, wie diese Public Services mithilfe von Private Services implementiert werden können und welche weiteren Kategorisierungsmöglichkeiten sinnvoll sind. Public-Business-Service- Kategorien Die folgende Enterprise-Architektur (Abb. 2) zeigt das Zusammenspiel von Business Process Services (BPS), Business Activity Services (BAS), Business Entity Services (BES) und Business Rule Services (BRS). Achtung: Dies ist keine Mehr-Schichten-Applikationsarchitektur, da sie zeigt, wie die Public- Services-Funktionalität aus mehreren Applikationen bzw. Systemen bereitgestellt wird. Business Process Services (BPS) Business Process Services (BPS) bestehen aus rein fachlichen Aspekten von Geschäftsprozessen. Sie basieren auf Prozessmodellen (etwa von Sprachen wie BPMN oder ereignisgesteuerten Prozessketten EPKs), die in ausführbare Prozesse, etwa BPEL, XPDL oder BPMN 2.0 übersetzt, wurden und Services orchestrieren. Das heißt, dass die Fachlichkeit durch Fachseiten festgelegt ist und BPEL-Designer die Struktur nicht mehr ändern sollen, sondern lediglich das BPEL-Skelett, das sich z. B. 1:1 aus der manuellen oder automatischen Generierung ergibt, mit BPEL-spezifischen Details anreichern. Tiefere fachliche und technische Details (wie Transformationen zu unterschiedlichen Datendialekten) sind ausgelagert in Geschäftsprozessschritten und aufgerufenen Services. Geschäftsprozesse sind in einer Organisation hierarchisch organisiert, um die Komplexität zu bewältigen. BPS sind typischerweise langlaufend (was sie in der Regel von einem Use Case Controller unterscheidet) und enthalten oft Benutzerinteraktion über Workflow- Funktionalität. Um die mit BPM versprochene lose Kopplung und Flexibilität zu erreichen, sollte man beim Design darauf achten, ausschließlich auszudrücken, was ein Prozess fachlich macht, nicht wie er es macht. Das Wie drückt sich in potenziell alternativen Implementierungen der Prozessschritte aus. BPS konzentrieren sich ausschließlich auf Fachliches, technische Aspekte wie Transformationen von und zum kanonischen Modell sollten in Integrationslogik ausgelagert sein. So arbeiten BPS ausschließlich auf Daten, die durch das kanonische Servicedatenmodell definiert sind. Änderungen am Prozess sollten im Fachmodell getätigt werden. Es ist strikt darauf zu achten, dass das Fachmodell und die Implementierung nicht auseinanderlaufen. Namenskonventionsvorschlag: Verb, das den Prozess ausmacht, plus Substantiv, auf dem das Verb arbeitet, plus Kategoriekürzel BPS. Beispiel aus RYLC: verleihe- AutoBPS. Business Activity Services (BAS) Business Activity Services (BAS) reagieren auf fachlich relevante Geschäftsereignisse. Sie kapseln kontextspezifische Controller-Logik. Der Kontext der BAS kann ein Prozessschritt eines Geschäftsprozesses sein oder ein Use Case Controller einer Applikation (Achtung: Aus Platzgründen ist diese Variante nicht in der Abbildung oben ausgedrückt!). BAS arbeiten auf generische- Anzeige

4 SOA aus dem wahren Leben Teil IV (typischerweise BES, aber oft stellt BAS auch Funktionalität aus BAS, BPS und BRS zusammen) Wrapper/Funktionalitätserweiterung: Arbeitet auf einem Service, oft einem generischen Business Entity Service, und reichert diesen um kontextspezifische Logik (oft mithilfe von Geschäftsregeln) an. Falls er nicht kontextspezifische Logik zu einem Entity Service hinzufügt, sollte man überlegen, die entsprechende Funktion an BES selbst anzugliedern. Diese Entscheidung hängt davon ab, ob er kontextspezifisch ist, also etwa für einen konkreten Use Case designt wurde (BAS) oder ob er eher generisch ist (BES). Namenskonventionsvorschlag: Verb, das die Aktivität ausmacht, plus Substantiv, auf dem das Verb arbeitet, plus Kategoriekürzel BAS. Beispiele aus RYLC: checkaufguterkundebas (über Regel in Rule Engine) ermittlepkwsundpreisebas (aus dem CarRental-System) schreiberechnungbas (über das Invoice-System) erstellemeldungankundenbas (über Notification Service) Abb. 1: SOA-Service-Kategorisierungsmatrix Abb. 2: Zusammenspiel der Public Business Services und Private Services in einer Enterprise-Architektur ren, basishafteren Services typischerweise auf ein oder mehreren Business Entity Services (BES) oder auf Business Rules Services (BRS). Im Rahmen eines BPM-Projekts können BAS aber auch einen Business Process Service aufrufen: So wird sichergestellt, dass jeder Prozessschritt auf BAS abgebildet ist, dessen Implementierung aus einfachen Serviceaufrufen bis hin zu komplexen Prozessen bestehen kann. Business Activity Services haben oft folgende Ausprägungen im Design: Composite Service: Komposition von mehr als einem aufgerufenen Service Business Entity Services (BES) Business Entity Services (BES) kapseln Daten und Funktionalität einer logischen Businessentität wie Kunde, Vertrag usw. in einem bestimmten Kontext: organisationsweit, domänen- bzw. subdomänen- (abteilungs-)bezogen. BES sind damit möglichst lose gekoppelte Kernservices auf Entitätenebene. Die Daten und Funktionen basieren auf ein oder mehreren Quellen (Applikationen oder einzelnen Komponenten). Geschäftslogik, die eng mit dieser Entität verknüpft ist und die nicht stark kontextbezogen ist, kann an BES angegliedert werden. Sehr komplexe Enititäten, die eine Vielzahl von Operationen haben, können jeweils in entsprechende zusammenhängende BES herunter gebrochen werden, wichtig ist hier das Kriterium der Kohärenz, also der kontext-, daten- und funktionsbezogenen Zusammengehörigkeit. Namenskonventionsvorschlag: Substantiv, das die Entität fachlich beschreibt, plus Kategoriekürzel BES. Beispiele aus RYLC: KundeBES. Diskussion: Kontext in BES führt zu BAS Business Entity Services weisen oft Operationen auf, die sich unterschiedlich verhalten, je nach Status, in dem sich diese Entität befindet. Es ist unter Umständen sinnvoll, die kontextbezogeneren Funktionalitäten in eigene BAS auszulagern, die dann auf statischeren, noch basishafteren Entitäten arbeiten: So gibt es bei RYLC etwa ein 78 javamagazin

5 Zusammenspiel aus dem kontextspezifischen KundeBeimVerkaufBAS, der auf dem generischeren KundeBES arbeitet. Hier kommt die Natur der BAS, eine Kontextfassade zu sein, zum Tragen. So könnte ein weiterer Service KundeAnlegenImVerleihBAS fachlich beschrieben werden, der im Rahmen der Erstellung eines Mietvertrages eine Adressvalidierung und einen Kreditkartencheck impliziert während ein KundeAnlegenInMarketingAktionBAS den Kunden und seine Stammdaten lediglich anlegt, damit ihm die Marketingabteilung Informationsmaterial zuschicken kann. Business Rule Services (BRS) Business Rule Services (BRS) kapseln eine Entscheidung in einem Ablauf: Wenn Guter Kunde, dann... eine Validierung, oft auch als Vorbedingung einer Funktion benutzt, die sicherstellt, dass sich Daten in einem (manchmal kontextbezogen) korrekten Zustand befinden: Kundendaten sind valide Namenskonventionsvorschlag: Sprechender Name, der das Ergebnis der Regel ausdrückt, plus BRS. Beispiele aus RYLC: berechneobguterkundebrs. Private vs. Public Im Ringen um lose Kopplung und ein sauberes Verständnis von Separation of Concern in einer SOA, ist uns eine weitere Kategorisierung auf einer höheren Abstraktionsstufe wichtig geworden, nämlich Public Service und Private Service. Diese Unterscheidung hilft zu verstehen, wie existierende Funktionalität zu öffentlichen, wiederverwendbaren und lose gekoppelten Services zusammengebaut werden kann. Die Objektorientierung unterscheidet zwischen private und public, um die Sichtbarkeit und den Bereich von Objekten und Methoden zu kennzeichnen. Eine private Methode oder ein privates Attribut ist ein Implementierungsdetail, das nicht nach außen sichtbar ist. Eine public-methode jedoch ist Teil der von außen wahrnehmbaren (und zumeist verwendbaren) Schnittstelle. Das ist eine gute Analogie für den Unterschied von Services, die als Public Services die SOA-Bausteine ausmachen, aus denen Geschäftsprozesse und Applikationen zusammengebaut werden, und ihren Implementierungen, den Private Services (bzw. privaten Komponenten), die durchaus WSDLs und SOAP nutzen können aber nicht müssen. Organisatorische Aspekte Beispiele für private oder lokale Services sind solche, die im Rahmen lokaler Projekte entstehen, wobei die Funktionalität redundant zu der von Services oder Applikationen in anderen Abteilungen und Projekten sein kann. So ist in Abbildung 3 ein Service, der in der Abteilung 3 erstellt wurde, dann privat, wenn er nicht auf Wiederverwendung in anderen Abteilungen oder Applikationen hin entwickelt wurde (wie die Public Services in der Public Shared Services -Gruppe), sondern ad-hoc für die lokalen Bedürfnisse in der Abteilung 3. Was ist nun ein Private Service? Anzeige Ausblick: Lose Kopplung, Governance Wie oben beschrieben, besteht ein Public Service vor allem aus dem WSDL. Zur Implementierung kann diese Funktionalität von Grund auf neu entwickelt oder auf der Basis von existierenden Systemen erstellt werden. Dazu benötigen wir private Integrationsservices. Wir werden im Artikel zur Losen Koplung diskutieren, wie diese Integrationsservices realisiert werden können. Wir haben gezeigt, dass eine der Hauptaufgaben im Querschnittsarchitekturteam darin besteht, die für die Projektsituation passende Kategorisierung entsprechend des Separation of Concern -Prinzips vorzunehmen. Dann gilt es, eine Teamkultur zu etablieren, in der die Richtlinien in Bezug auf Analyse, Design, Sichtbarkeit und Lifecycle-Management entlang dieser Kategorien eingehalten werden womit wir beim Thema SOA Governance sind, für das wir hier einige Grundlagen geschaffen haben und das wir in einem eigenen Artikel näher beleuchten.

6 SOA aus dem wahren Leben Teil IV Abb. 3: Private Services sind lokal und noch nicht auf Wiederverwendung ausgelegt Abb. 4: Überlappende Funktionalität in existierenden Systemen Er ist eins von potenziell mehreren Implementierungsdetails eines Public Service. Falls er Geschäftslogik zur Verfügung stellt, tauscht er Daten potenziell in einem proprietären (also nicht kanonischen) Datenformat aus. Er folgt oft nicht den strengeren Designvorgaben, die sich an Public Services ergeben. So kann er durchaus nur einen Ausschnitt aus der Gesamtfunktionalität eines logischen Bausteins zur Verfügung stellen. Beispiele für Private Services können sein: Ein CustomerORMapperService. Ein Rechter-Mausklick-Service, also eine Java-Klasse, die ein Entwickler z. B. mit ein paar Mausklicks zu einem Service gemacht hat, ist ein typischer Private Service, der seine proprietäre Datenstruktur lediglich dem Entity- Service bekannt geben und niemals von einer Vielzahl von Services genutzt werden darf. Ein WSDL-basierter Service, der Funktionalität von existierenden Applikationen oder von SAP (etwa das WSDL einer BAPI) oder Oracle Enterprise Applikationen bereitstellt und dabei Datentypen (und -formate) aus diesen Applikationen exponiert. Ein IntegrationsprozessServiceFuer- CustomerDaten, der Kundendaten aus mehreren Systemen holt und bereitstellt. Ein hypothetischer RYLC_CRM_Customer_update-Service sagt schon im Namen, dass hier RYLC_CRM - applikationsspezifische Implementierung angeboten wird und die Daten in einem RYLC_CRM -spezifischen Dialekt vorliegen. Rehabilitierung des Rechter-Mausklick-Service Java-basierte Services (also Bottom up -entwickelte Services, erstellt mithilfe des rechten Mausklicks Create Web Service from Class ) oder solche, die Funktionen von Applikations-APIs als WSDL-basierte Web Services zur Verfügung stellen, werden oft als nicht richtige SOA Services diskreditiert. Wir möchten hier diese Art von Services rehabilitieren. Sie sind potenziell wertvolle Bausteine, damit sich ein Public Service zusammenbauen kann. Es ist jedoch überaus wichtig, die Trennung von Private und Public nicht zu verletzen: Ebenso wie es schlechtes OO- Design wäre, in einer Java-Klasse nicht zwischen private- und public-accessor zu unterscheiden, wäre es misslungenes SOA-Design, wenn man jedes Stückchen Funktionalität ohne Governance, die Redundanzfreiheit zum Ziel hat, veröffentlichen würde. Public Services konsolidieren verteilte Funktionalität Ein WSDL beschreibt die Schnittstellen von Services. In einer naiven Herangehensweise, die man in frühen SOA-Projektphasen beobachten kann, binden Entwickler die Schnittstelle (den abstrakten WSDL-Anteil) eines Service an eine bestimmte Implementierung, etwa eine Ad-hoc-Serviceimplementierung oder einen konkreten Workflow, wie wir es im letzten Artikel beschrieben haben. Diese Bindung der Schnittstellenspezifikation an die Implementierung weist folgende Probleme auf: Die Schnittstelle ist nicht fachlich motiviert, sondern ergibt sich aus der Implementierung. Dies entspricht dem Contract-Last-Design und ist problematisch, auch wenn der Implementierung eine objektorientierte Analyse und Design vorangegangen sind, da ein Service eine gröbere Granularität aufweisen sollte als eine objektorientierte Klasse. Ein Public Service sollte nicht eine weitere Implementierung eines organisationsrelevanten Konzepts wie Kunde sein, die redundant neben ähnlicher Funktionalität in einer Organisation steht. Vielmehr sollte er alle Funktionalität, die zu einem organisationsrelevanten Konzept gehört, kapseln. Ein Public Service ist damit die Summe und der kanonische Repräsentant aller Private Services, die zusammen dieses Konzept ergeben. Ein solches Konzept könnte sein: Ein Geschäftsprozess wie Ausleihen eines Wagens Eine wichtige Aktivität im Rahmen eines Geschäftsprozesses oder Anwendungsfalls, wie ermittleausgeliehene- Wagen Eine relevante Organisationsentität wie Kunde, Produkt Eine komplexe Berechnung mit vielen Geschäftsregeln wie RabattStaffelung In RYLC ist die Funktionalität von lese Kunden auf zwei Systeme verteilt (Abb. 4). Wenn wir den Public Service KundeBES erstellen, konsolidieren wir die Funktionalität nach fachlichen Gesichtspunkten (Abb. 5). Ein Konsument eines Public Service kennt damit ausschließlich die abstrakte Definition (das WSDL). Dabei folgt der Public Service dem Fassade Design Pattern. Die Private Services hängen also nicht starr am Public Service, sondern werden über ein Composite zusammengefügt. Wie dieser Public Service implementiert wird, ist damit für den Konsumenten komplett unsichtbar. Der Fokus liegt in diesem Fall wirklich auf dem Wort komplett. Generell abstrahiert ein über WSDL beschriebener Service immer von seiner Implementierung, hier ist allerdings auch die völlige Entkopplung sämtlicher Daten gemeint. Das kanonische Datenformat kommt zum Einsatz, private Datenstrukturen werden in der Schnittstelle des Public Service nicht akzeptiert. Um den Public Service in verschiedenen Kontexten 80 javamagazin

7 Anzeige

8 SOA aus dem wahren Leben Teil IV Abb. 5: Public Services konsolidieren zusammenhängende Funktionalität wiederverwenden zu können, entscheidet ein ESB zur Laufzeit über die konkret zu verwendende Implementierung und virtualisiert damit die Implementierung vollständig gegenüber dem Konsumenten. Dies erlaubt später auch die vielzitierte Flexibilität innerhalb der SOA, da Änderungen durch Konfiguration am ESB und nicht durch aufwändige Anpassungen der Prozesse realisiert werden können. Man sieht, dass die Gesamtfunktionalität des Public Business Entity Service Customer Service über einige Private Services und deren WSDLs verteilt ist, die Gesamtfunktionalität wird jedoch über das kohärente Public Service WSDL angeboten. Der ESB stellt Daten dann als Hochsprache, also als Teil des kanonischen Datenmodells zur Verfügung und übersetzt intern in die Dialekte der Private Services der beteiligten Applikationen. Der Designer des WSDL von Public Business Services sollte darauf achten, dass Daten, Servicenamen und Operationsnamen ausschließlich darauf rückschließen lassen, was ein Service tut und nicht wie er es tut. Damit sind derartige Business Services lose gekoppelt und ihre Implementierung kann ausgetauscht werden. Zusammenfassung: Was ist ein Public Service? Ein Public Service ist eine auf die fachliche Schnittstelle ausgerichtete Fassade auf die Implementierung, die sich aus Private Services zusammensetzt. Das heißt, er ist rein aufgrund der Bedürfnisse und fachlichen Wahrnehmung des Konsumenten motiviert. ist strikt implementierungsneutral. Seine Schnittstelle beschreibt ausschließlich das von außen wahrnehmbare Verhalten und exponiert keinerlei Implementierungsdetails. Business Entity Services (BES), die auf der Ebene von Private Services und Utility Services intern Datenbankzugriffe benutzen, stellen diese als Fachdaten zur Verfügung und propagieren ihre technischen Details (etwa DB-Schlüssel) nicht nach außen. ist daraufhin ausgerichtet, potenziell wiederverwendet zu werden. Dies impliziert, dass der Service möglichst wenig Kontext- und Statusabhängigkeit besitzt, damit er in möglichst vielen Kontexten verwendbar ist wobei die verschiedenen Ausprägungen unterschiedlich viel Kontextabhängigkeit zulassen. So sind Business Activity Services wesentlich kontextspezifischer als Business Entity Services. tauscht Daten ausschließlich in kanonischem Datenformat aus. ist in einer (UDDI-)Service Registry auffindbar und dort als public service kategorisiert. stellt seine Gesamtfunktionalität als zusammenhängendes Set von Operationen zur Verfügung, die zusammen logisch zum entsprechenden Konzept gehören. ist entsprechend der Service Taxonomy kategorisiert, etwa als Business Process Services (BPS), Business Activity Services (BAS), Business Entity Services (BES) oder Business Rule Services (BRS). Eine Public-Service-Operation prüfe- Kreditwürdigkeit bekommt also Daten eines Kunden und gibt zurück, ob er kreditwürdig ist oder nicht. Wie er implementiert ist, als komplexer Workflow, bei dem die Besitztümer des Antragstellers bewertet werden oder als Aufruf eines Super-Schufa-Services, ist damit dem Aufrufer nicht einsehbar. Vorteil: Die Implementierung kann ausgetauscht werden, ohne dass der Konsument betroffen ist, solange das WSDL stabil bleibt. Diskussion: Gibt es Private Entity Services In unserer Kategorisierung ist eine Spiegelung der Public-Service-Kategorien auf Private Services, also etwa ein Private Entity Service etc. nicht vorgesehen. Falls es in einer Applikation eine entsprechende Kategorisierung gibt, ist das völlig in Ordnung. Es ist jedoch wichtig zu verstehen, dass dies applikationsbezogene Governance (Einhaltung von Designrichtlinien etc.) mit sich bringt, die sich von der Governance von Public Services strikt unterscheidet: Erstere bezieht sich auf eine Organisationseinheit, etwa die Abteilung, die eine Applikation erstellt. Letztere ist auf applikations- und abteilungsübergreifende Organisationsbündel ausgerichtet, idealerweise auf das Gesamtunternehmen. Takeaways Nur eine saubere Servicekategorisierung von Anfang an erlaubt dem Implementierungsteam, wiederverwendbare Services zu entwerfen. Servicekategorisierung ist der erste Schritt zu ganzheitlicher Governance und muss in den Projektdesignrichtlinien verankert sein. Nicht jedes SOA-Projekt braucht Business Process Services (BPS), Business Activity Services (BAS) oder Business Entity Services (BES). Public und Private Services sind jedoch ein Muss. Diskussion: Die Intermediary Services aus Enterprise SOA Es kommt immer wieder zu Diskussionen, welche Rolle die Intermediary Services, die z. B. im Buch Enterprise SOA eingeführt wurden, spielen, während die dort vorgestellten Basic Service und Process Centric Service ganz gut auf unsere Kategorisierung 82 javamagazin

9 SOA aus dem wahren Leben Teil IV SOA Center mappen. Im Sinne der Unterteilung nach Public und Private Services ist festzustellen, dass die Intermediary Services eher den Private Services zuzuordnen sind, da sie schon in der Kategoriebezeichnung Aufschluss über die Implementierung geben: Sie sind im Buch als Technologie-Gateways, Adapter, Fassaden etc. bezeichnet und erlauben Zugriff auf existierende Systeme. Wir würden sie daher eher den oben beschriebenen Private Integrations Services zuordnen. An dieser Diskussion kann man jedoch sehen, dass die von uns vorgeschlagene Einteilung eine von mehreren validen ist: Es gibt große Projekte, die anderen Kategorisierungen folgen und damit sehr erfolgreich sind. Bevor man also als Architekt die von uns vorgestellte Kategorisierung einem Projekt überstülpt, sollte man die Kultur und die Konzepte, die im Team bereits etabliert sind, berücksichtigen und sich gegebenenfalls diesem Gruppenverständnis unterordnen: Das wichtigste Ziel ist es, zu einer Separation of Concerns und zu gut geschnittenen Services zu gelangen und im Team eine gemeinsame Sprache zu schaffen. Abb. 6: Wie RYLC-Funktionen aufgrund der Kategorisierungsmatrix realisiert sind Die SOA-Service-Kategorisierungsmatrix in RYLC Servicekategorien wurden schon oft eingeführt. Wenn der Leser versucht, sie in einer konkreten Projektsituation anzuwenden, knirscht es häufig im Gebälk. Wir wollen daher unsere Matrix an den Autoverleihgeschäftsprozess, den wir in Artikel 2 beschrieben haben, anlegen. Abbildung 6 zeigt, wie die ersten zwei Prozessschritte mit BPS, BAS, BES und BRS realisiert sind. Unten diskutieren wir einige Knackpunkte. Zunächst werden die Daten des Kunden, der sich ein Auto ausleihen möchte, ausgelesen. Der entsprechende Prozessschritt wird durch den Business Activity Service aggregierekundendatenbas realisiert. Diesen findet der Prozessmodellierer entweder in einer Service-Registry oder gibt ihn, wenn er noch nicht existiert, in Auftrag. Er arbeitet auf zwei weiteren Services: Der erste, KundeBES, kapselt die Funktionalität von zwei Systemen, die über die entsprechenden Private Services bereitgestellt werden. Dabei übersetzt der Integrationsservice lesekundendatenaus die Datendialekte aus CRM1 und Car- Rental in das kanonische Datenformat, das vom BAS angeboten wird. Die Implementierung des zweiten Public Services, holeverleihhistoriebas, ist hier nicht dargestellt. aggregierekundendatenbas ist damit ein kontextspezifischerer Service als KundeBES, da er speziellere Anfragen realisiert. Er aggregiert die Funktionalität der zwei Services, die er aufruft. Wir haben diskutiert, ob der aggregierekundendatenbas nötig ist: Der Prozess selbst könnte ja die benötigten Services direkt aufrufen. Dies ist durchaus möglich, damit wäre aber das Separation of Concern Prinzip verletzt: Mit der gezeigten Ausgliederung in einen BAS besteht der Prozess ausschließlich aus dem Fluss von Prozessschritten, deren Innereien in BAS ausgelagert sind. berechneobguterkundebas zeigt, dass ein BAS Business Process Services (BPS) aufrufen kann. Er entscheidet über die Implementierung als Prozess oder als Geschäftsregel. Weitere Service-Kategorisierungsmöglichkeiten Es gibt mehrere Kriterien, nach denen Services kategorisiert werden. So könnte man strukturell vorgehen: Services können atomar sein oder als Composite mehrere abstraktere Services zusammenstellen bzw. kontrollieren. Dies ist reflektiert in der Unterscheidung BES (atomar) und BAS (Composite). Eine weitere sinnvolle Einteilung ist die in Business Services (die rein fachlich motiviert sind und Geschäftslogik bereitstellen) und in Utility Services (technische Querschnittsfunktionalität, wie ein einheitlicher, zentraler Logging-Mechanismus). Diese Trennung ist wichtig: Alle oben genannten Public Business Services (BPS, BAS, BES, BRS) sind rein fachlich und exponieren keinerlei technische Details. Die Private Services, die sie implementieren, kön- javamagazin

10 SOA aus dem wahren Leben Teil IV nen aber Utility Services benutzen. Ob sich für Utility Services eine Unterscheidung nach Public und Private lohnt, wird sehr kontrovers diskutiert. Für die Einteilung spricht, technische Dienste, die globaler eingesetzt werden sollen, entsprechend als Public zu exponieren, während lokal eingesetzte technische Dienste über den Private-Mechanismus nur eingeschränkt wiederverwendbar sind. Dagegen spricht, dass sie streng genommen Implementierungsdetails von Public Services sind. Es kann daher zur Verwirrung beitragen, wenn dann auf einmal Implementierungsdetails doch wieder Public sind. Typische Public Utility Services, die querschnittlich benutzt werden können, sind Logging, Print, oder Security Services. Fazit: Was gewinnt man mit einer guten Servicekategorisierung? Hat man im Team eine gemeinsame Sprache geschaffen, werden Services entlang ihrer Kategorisierung entworfen. Die von uns vorgeschlagene Einteilung in Public und Private Services hilft, rein fachlich motivierte Services zu erstellen, die zusammen einen Servicebausteinkasten ergeben. Inhärent kommt mit dem Fokus auf das von außen beobachtbare Verhalten lose Kopplung und damit Services, deren Implementierung sich austauschen lässt, ohne dass die Konsumenten betroffen sind. Auch die vielzitierte Flexibilität von ausführbaren Geschäftsprozessen wird auf diese Weise überhaupt erst möglich. Die von uns vorgeschlagene Einteilung nach Business Process Services (BPS), Business Activity Services (BAS), Business Entity Services (BES) und Business Rule Services (BRS) hilft Struktur in Services zu bringen und Serviceaufrufe in ein Metakonzept zu überführen, sodass Funktionen verständlich werden: Eine Serviceaufrufkette liest sich wie ein Buch: Ein WagenAusleiheBPS ruft einen berechneleihgebührbas auf, der auf lieferekundenkonditionenbes und liefererechnungsadressebes arbeitet, die mit Funktionalität aus den Systemen WagenAusleiheSystem und InvoiceSystem implementiert sind. Sind die Public Business Services sauber in einer Registry registriert, lassen sich sehr interessante Auswertungen und Reports generieren: Wie viele BPS gibt es, wie viele BAS etc.? Welchen Grad an Wiederverwendung weisen die einzelnen Servicearten auf? Nicht zuletzt Links & Literatur lässt sich eine Service-Usage-basierende Abrechnung leicht implementieren. Wir hoffen, dass sich entsprechende Kategorisierungen bald als Standard durchsetzen, damit es leichter wird, auf einem gemeinsamen Verständnis aufsetzende Services zu entwerfen. 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 für Referenzarchitekturen rund um Integration, JEE und die hauseigenen Entwicklungs-Frameworks verantwortlich. 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 architektonischer und organisatorischer 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 als Sprecher 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 deren 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 ist Bereichsleiter der Anwendungsentwicklung bei der OPITZ CONSULTING GmbH, Autor diverser Fachartikel und Sprecher auf nationalen Konferenzen. Er besitzt langjährige Erfahrung als Trainer, Projekt-Coach 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. [1] Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg: Rent your Car Service-oriented, in Java Magazin [2] Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg: SOA Blueprint, in Java Magazin [3] Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterber: Charakteristiken von SOA-Projekten, in Java Magazin [4] Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA: Service-oriented Architecture Best Practices, javamagazin