Pragmatic SOA - nur das Wesentliche
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
SOA Praxis bei 1&1 SOA Center
Pragmatic SOA –
nur das Wesentliche
Das Kürzel „SOA“ hat seinen Weg in fast jeden entlegenen Winkel der Unterneh-
menswelt gefunden. Komplettpakete für Service-oriented Architecture gibt es
auf dem Markt inzwischen in großer Zahl. Leider wird das Architekturparadigma
SOA oft auf die vorwiegend eingesetzte Technologie reduziert, z. B. Web Service
oder Enterprise Service Bus. Darüber geraten leicht die eigentlichen Ziele und
die Komplexität einer SOA aus dem Blickfeld. Die Technologie sollte dafür nur
das Mittel zum Zweck sein. Abseits ausgetretener Pfade stellt dieser Artikel eine
pragmatische SOA-Lösung auf Basis von Open-Source-Software vor, die den
Grat zwischen der Komplexität einer spezifischen Servicelandschaft und den
harten Ansprüchen eines Unternehmensalltags gemeistert hat.
von Matthias Wittum, Dirk Schmid und Dr. Thomas Breitkopf
ieser Beitrag befasst sich mit ei- erung der Onlinewerbeabläufe auf den ing“ – ein automatisiertes Einordnen
ner leichtgewichtigen Lösung, konzerneigenen Portalen (z. B. Web. von Benutzern nach deren Affinitäten,
die in einem Unternehmensbe- de, GMX), entwickelt wurde. Zu diesen um zielgruppenorientiert Werbung
reich der 1&1 Internet AG für die Steu- Abläufen zählt z. B. das Produkt „Target- aussteuern zu können. Die zentralen
www.JAXenter.de javamagazin 2|2010 91
SOA Center SOA Praxis bei 1&1
Abb. 1:
Executables
und Sphären
Abb. 2:
Networklayer
Anforderungen an die Steuerung dieses tektur, spielt bei GEPPI eine zentrale der Konsequenz, dass die Anbindung der
verteilten Systems ist die einfache und Rolle. Auf technischer Ebene wurde Services auf jeder Zielmaschine durch ei-
schnelle Einbindung bereits vorhande- das durch eine völlige Entkopplung der nen Agenten realisiert wird. Bildlich ge-
ner und zukünftiger Funktionalitäten Service-Consumer und -Provider von sehen stecken wir die anzusprechenden
als Service, als flexible Umsetzung der der Technik der Kommunikation und Softwareartefakte in eine Sphäre, wo sie
Geschäftsprozesse sowie als Ausrich- des Routings realisiert. Die vorhande- die von ihnen benötigte Technologiewelt
tung an der Organisation vorfinden, während die Au-
des Bereichs. Dazu wurde ßenwelt – das verteilte System
vor etwa drei Jahren das Es wurde beschlossen eine Lö- – hinter der Hülle für sie ver-
Projekt „GEPPI“, die Be- borgen bleibt (Abb. 1).
zeichnung ist ein Akro- sung auf Basis von frei verfüg- Im GEPPI-Jargon spre-
nym für „General Enter- chen wir bei den Softwarear-
prise Process and Planning barer Software zu entwickeln. tefakten von Executables,
Infrastructure“, ins Leben also ausführbaren Einheiten
gerufen. Schnell wurde klar, dass mit den ne Funktionalität lag in Form von Pro- (Dreieck, Rechteck usw.), und bei den
damals zur Verfügung stehenden SOA- grammen oder Skripten in den unter- Agenten von ExecutionUnits, den Sphä-
Softwarekomponenten ein solches Sys- schiedlichsten Sprachen vor (Java, C, ren, die sich um die Kommunikation
tem nicht ohne Weiteres zu realisieren Perl, Python etc.). Bei den meisten dieser nach außen und das Auftragsmanage-
ist. Es wurde deshalb beschlossen, eine Softwareartefakte handelt es sich um ment kümmern (Kreise).
Lösung auf Basis von frei verfügbarer einen Batch-artigen Betrieb. Die Pro- In der Praxis ist es naturgemäß nicht
Software zu entwickeln, die genau diese gramme oder Skripte werden beim Start so trivial, wie sich das in einem schönen
Anforderungen adressiert. mit Nutzdaten versorgt und bearbeiten abstrakten Bild ausdrücken lässt. Als
Die zu diesem Zeitpunkt bereits diese gemäß vorgegebener Aufrufpara- Architekturlösung für das Umsetzungs-
bestehende Servicelandschaft war sehr meter. Nach Abschluss der Verarbeitung problem wurden im Sinne des Separati-
heterogen und in unterschiedlichsten liegen dann beispielsweise veredelte on of Concerns Zuständigkeitsbereiche
Softwaretechnologien auf diversen Be- Nutzdaten als Ergebnis vor, die vom identifiziert und abgegrenzt.
triebssystemplattformen realisiert. Her- nächsten Verarbeitungsschritt wieder Wie in Abbildung 2 zu sehen, vermit-
ausgekommen ist eine serviceorientierte aufgegriffen werden können. telt die ExecutionUnit zwischen verteil-
Architektur, die sich auf die Elemente des Eine Harmonisierung der heteroge- ter Kommunikationsinfrastruktur und
SOA- Paradigmas konzentriert, die für nen Landschaft war aus vielen Gründen den konkreten Service-Providern (Exe-
die vorhandenen Anforderungen we- keine ernsthafte Option (z. B. Third-Par- cutables). Sie stellt den von der Middle-
sentlich sind und diese konsequent um- ty-Produkte, performanteste Technolo- ware im Netz ansprechbaren Endpunkt
setzen. Nicht zuletzt durch diese Fokus- gie für den jeweiligen Anwendungsfall). und verwaltet Plug-ins, die die Ausfüh-
sierung auf die tatsächlichen Belange des Auf der anderen Seite erschien uns die rungsumgebung für die jeweils techno-
täglichen Bedarfs konnte eine Lösung ge- Entwicklung von Wrapper-Code für logisch unterschiedlichen Programme
schaffen werden, die durch ihre Klarheit alle eingesetzten Sprachen zur Einfüh- bereitstellen. Ihre Hauptaufgabe besteht
und zielgerichtete Leichtigkeit besticht. rung eines einheitlichen Kommunka- darin, Aufträge entgegenzunehmen und
tionsprotokolls zu aufwändig. Deshalb an die einzelnen Plug-ins zu delegie-
Lose Kopplung wurde beschlossen, die Kommunikati- ren, die dann konkrete Programme zur
Lose Kopplung, als wesentliches Merk- onsinfrastruktur für die Services völlig Ausführung bringen. Deren Ergebnisse
mal einer serviceorientierten Archi- transparent zu machen. Das bedeutet in werden über die ExecutionUnit zurück
92 javamagazin 2|2010 www.JAXenter.de
SOA Praxis bei 1&1 SOA Center
an die Middleware gemeldet. Zwischen Abb. 3: Perl
Plug-in und Executable ist es durchaus Script als Ser-
vice mittels Ant
möglich, eine zusätzliche Adapter-
schicht zu verwenden.
Ein weiterer wichtiger Aspekt der
ExecutionUnit ist das Publizieren der
Serviceeigenschaften (z. B. Ein- und
Ausgabeparameter) jedes Executables
als überprüfbare Vertragsbedingungen
zur Nutzung des Service. Jedes Plug-in
verwaltet seine ihm zugeordneten Exe-
cutables, für die es die Ausführungsum-
gebung stellt. Als erstes Plug-in wurde
von unserer Seite zunächst ein Ant-Plug-
in erstellt.
Ant ist vielen noch als Build-Tool
bekannt, das auf XML-Basis sehr ein-
fach bedient werden kann und seit Lan-
gem über viele Erweiterungen und gute lungen damit arbeiten können. Bei uns Betriebssystemen mit ein paar Zeilen
Dokumentation verfügt. Ant-Skripte wurden sie als eine Art Adapterschicht Code ausführen.
können fast alles aufrufen, auf beliebi- eingesetzt, um jede Art von Programm/ Abbildung 3 zeigt beispielhaft die
gen Plattformen ausgeführt werden und Skript aufrufen zu können. Mit Ant als Schritte, die nötig sind, um ein einfaches
sind im GEPPI-Kontext meist so ein- Adapterschicht lassen sich praktisch al- Perl Script inklusive Ein/Ausgabe und
fach zu verstehen, dass auch Fachabtei- le Softwareartefakte auf allen wichtigen Fehlerbehandlung mittels Ant-Skript als
Anzeige
BPM-Umfrage 2009
Business Process Management (BPM) wird für Unternehmen in
allen Branchen ein zunehmend wichtigeres Thema. Wege und
Bis zu
Ziele zu einer erfolgreichen Umsetzung von BPM sind dabei 25. Janu m
a
vielfältig. mitmac r 2010
hen un
INTEL d
LIBOO
Wie ist es in deutschen Unternehmen um BPM bestellt? gewinn K
en!
Das Business Technology Magazin möchte gemeinsam mit SAP
genau diese Frage beantworten.
Nehmen Sie unter www.bt-magazin.de/bpm-umfrage an der
BPM-Umfrage 2010 teil und gewinnen Sie ein INTELLIBOOK
des Software & Support Verlags!
Präsentiert von:
www.bt-magazin.de/bpm-umfrage
www.JAXenter.de javamagazin 2|2010 93
SOA Center SOA Praxis bei 1&1
Bei der Middleware haben wir uns Schnittstelle zum Service, dem GEPPI-
für Jini entschieden, das inzwischen un- Service-Adapter, obliegt dann der Exe-
ter dem Projektnamen „Apache River“ cutionUnit. (Man könnte diese Lösung
weiterentwickelt wird [1]. Das hatte im durchaus als eine Art verteilten ESB [2]
Wesentlichen zwei Gründe: Zum einen verstehen).
ist Jini ist von Hause aus darauf ausge-
legt, Teilausfälle durch Redundanz Geschäftsprozesse: flexibel und
kompensieren zu können, zum anderen einfach
können neue Services extrem flexibel Orchestriert oder kombiniert, wie es au-
hinzugefügt werden. Wird z. B. ein neu- ßerhalb der SOA-Welt heißt, werden die
er Jini-Service in Betrieb genommen, einzelnen Services über eine Workflow-
so meldet er sich (ohne weiteren Kon- Engine, in unserem Fall die jBPM von
figurationsaufwand) an der Jini Service JBoss. Das erlaubt die flexible Kombi-
Abb. 4: Verteilter ESB
Registry an, beschreibt seinen Funkti- nation von Services zu neuen Geschäfts-
Service verfügbar zu machen. Wie man onsumfang und steht dann sofort zur prozessen und die Prozessschritte indi-
erkennen kann, werden hier auch die (Remote-)Verwendung bereit. Das ent- viduell durch eigene Logik zu erweitern
Serviceeigenschaften definiert, die von spricht in einer typischen SOA der Ser- [3]. Entsprechend der Kategorienklassi-
der ExecutionUnit im Netz publiziert vice Registry oder einem UDDI-Dienst, fikation in [4] bildet die jBPM den Kern
werden, um diesen Dienst sowohl auf- nur komfortabler. des Business Process Service (BPS) von
findbar als auch auswählbar zu machen. Die Kommunikation zwischen den GEPPI.
Hierbei handelt es sich um Informatio- Service-Consumern und -Providern Bei vielen SOA-Systemen besteht
nen wie Servicename, Servicemethode, erfolgt dabei nicht über eine zentrale zusätzlich noch die Möglichkeit, Servi-
Ein- und Ausgabeparameter usw. – aber Infrastrukturkomponente, einen ESB, ces aus einem Service heraus im Sinne
auch eine „Human Readable“-Service- sondern auf Basis der Jin Middleware als eines Composite Service anzusprechen
beschreibung sollte nicht fehlen. Punkt-zu-Punkt-Verbindung zwischen (nicht nur aus dem BPS heraus). Das ist
Consumer und Provider. Auf komple- ein mächtiges, aber potenziell auch sehr
Kommunikationsinfrastruktur: xe Routing-Funktionalität wie Con- komplexes Konstrukt. Da die Flexibi-
(k)ein Enterprise Service Bus tent Based Routing wurde mit diesem lität dieser Composite Services zwei-
Hat man die Hoheit über die Kommu- Lösungsansatz bewusst verzichtet und felsfrei die Komplexität des Betriebs
nikationsendpunkte, bringt das den stattdessen der Fokus auf einen einfa- erhöht, aber in dem beschriebenen
Vorteil mit sich, dass das Protokoll frei chen, stabilen Betrieb gerichtet. Umfeld der 1&1 kein unverzichtbares
wählbar ist. Die anzusprechenden Exe- Die Middleware Jini übernimmt Architekturmerkmal darstellt, wurde
cutables müssen sich lediglich an die somit Teile der Aufgaben, die typischer- diese Möglichkeit in GEPPI explizit aus-
lokale Schnittstelle des entsprechenden weise in einem SOA-System vom Enter- geschlossen. Es gibt in der Aufrufhie-
Ausführungs-Plug-ins halten und sind prise Service Bus erledigt werden. Das rarchie der Services also nur zwei Ebe-
damit fein raus aus der Netzwerkkom- Mapping zwischen dem einheitlichen nen: Die erste Ebene besteht ausschließ-
munikation. Kommunikationsprotokoll und der lich aus einem zentralen Business Pro-
cess Management, das alle anderen
Services orchestriert. Darunter steht
die flache Ebene von gleichberechtigten
GEPPI-Services, die selbst keine ande-
ren GEPPI-Services aufrufen können.
Durch diese Einschränkung konnte die
Betriebstransparenz deutlich erhöht
und die Komplexität des Systems stark
verringert werden.
Bleibt die Frage, wie unter dieser
Einschränkung mit technischen oder
Utility Services [4] umgegangen wird:
Sie sind weder verzichtbar, noch kann
ihr Aufruf sinnvoll auf die Ebene des
Workflows verlagert werden. Hier wur-
de ein Kompromiss gewählt, der sowohl
die Nutzung technischer Services er-
möglicht als auch die Entwicklung der
Abb. 5: Aufruf von „Service“ aus „Workflow“ Services vereinfacht. Ähnlich wie die
94 javamagazin 2|2010 www.JAXenter.de
SOA Praxis bei 1&1 SOA Center
Entkopplung der GEPPI-Services von (gibt es mehrere Dienste, die den gefor- Schnittstelle wie ein Java- oder ein Perl-
der Kommunikationsinfrastruktur wer- derten Merkmalen entsprechen, kann Plug-in. Sogar ETL-Jobs sind dank eines
den auch die Utility-Services nicht vom ein finaler Kandidat z. B. anhand der Kettle-Plug-ins (mittlerweile eher unter
GEPPI-Service direkt angesprochen, aktuellen Serviceauslastung oder Loka- Pentaho Data Integration bekannt [5])
sondern in der Schnittstelle (Adapter), lisierungsbedingungen bestimmt wer- kein Problem. Und sollte doch was feh-
die den GEPPI-Service mit der Execu- den). Auftragnehmer ist in diesem Fall len, besteht die Möglichkeit, selbst eine
tionUnit verbindet, deklarativ beauf- zunächst eine ExecutionUnit, die den „neue“ Technologie über ein eigenes
tragt. Die Schnittstellentechnologie Auftrag über das jeweilige Plug-in an das Plug-in anzubinden.
(z. B. Ant) bleibt die gleiche Vor allem im agilen Um-
und die ExecutionUnit feld bietet die Orchestrie-
sorgt für das Auffinden und Grundlegende Konzepte wur- rung über flexibel anpass-
die Kommunikation mit bare Workflows einiges an
den Utility Services. den an der bestehenden Orga- Dynamik und Flexibilität.
Abbildung 4 visuali- So wurde bei uns binnen
siert die angesprochene nisation ausgerichtet. vier Wochen ein komplett
Klassifizierung und zeigt neuer Ablauf zur Verwen-
exemplarisch die beteiligten Elemente. Executable weiter delegiert. dung unserer Targeting Services für
Zentraler Unterschied zum klassischen Um eine Überwachbarkeit zu rea- einen neuen Kunden kreiert, wobei die
SOA-Ansatz ist die Verwendung eines lisieren, wurde ein zentraler Logging- Workflows als auch die Anbindung an
„verteilten ESBs“ sowie die Aufteilung Mechanismus namens GAM (GEPPI die tatsächlichen Programme allein
in Business- und Utility Services (wobei Activity Monitoring) entwickelt. GAM durch unser Betriebspersonal realisiert
der BPS, wie bereits erwähnt, eine spezi- sammelt während der Serviceausfüh- wurde und sich die Entwickler auf die
elle Variante davon darstellt). rung zusätzlich noch Informationen tatsächlichen Herausforderungen im
zu Status und Fortschritt und kann Businesslogikbereich konzentrieren
Praktisch gesehen diese entsprechend visualisieren. Zur konnten.
JBPM als Workflow Engine bietet die Unterstützung der ExecutionUnits im
Möglichkeit, die XML-Syntax der Work- Alltagseinsatz gibt es einen Plug-in- SOA Governance und
flow-Definition um eigene Elemente zu Updateservice, der die Aktualisierung Geschäftsprozesse
erweitern. Das geschieht durch Definiti- der Plug-ins zentral koordiniert und In den einleitend aufgelisteten Kernan-
on eigener ActionHandler. Dieses Vor- weitgehend automatisiert. Das GEPPI- forderungen an das beschriebene SOA-
gehen wurde verwendet, um eine naht- System an sich ist umgebungsneutral System wird auch der organisatorische
lose Integration in das GEPPI-System zu und kann durch einen eigens dafür Aspekt des Paradigmas SOA adressiert:
ermöglichen. integrierten Konfigurationsmecha- Die grundlegenden Konzepte hinter
Abbildung 5 zeigt beispielhaft den nismus an eine bestimmte Umgebung GEPPI wurden an der bestehenden Or-
Aufruf eines Service aus einem Work- angepasst werden (z. B. Dev-/QS-Sys- ganisation des Unternehmensbereichs
flow heraus. Bis zum Action-Element tem). Auf diese Weise bleiben die Soft- ausgerichtet.
handelt es sich noch um Standard- warekomponenten unverändert und Das Feld der Geschäftsprozesse rund
jBPM-Syntax. Unterhalb der verwen- werden lediglich an die Gegebenheiten um die Onlinewerbeabläufe auf den Un-
deten ServiceCallAction kommt die angepasst. ternehmensportalen ist auf mehrere
GEPPI-eigene Syntax zum Tragen. Hier Zur Administration und zur Schaf- Projektteams aufgeteilt, die sich jeweils
wird beschrieben, welcher Service ange- fung der notwendigen Transparenz im auf eine spezielle Fachdomäne der ge-
sprochen werden soll (Servicename und Betrieb wurde zusätzlich eine GUI-Platt- samten Prozesskette konzentrieren. In
Servicemthode), was er als Parameter form aufgesetzt, in die einzelne Sichten diesen Teams sind sowohl die fachlichen
übergeben bekommt und was zurück- und GUIs wie die Standard-JBPM-Con- Experten als auch die Entwicklung, Qua-
erwartet wird. Hier gibt es außerdem sole oder auch ein GAM-Monitoring- litätssicherung und der applikationsna-
etliche Möglichkeiten, um den Aufruf GUI eingeklinkt werden können. he Betrieb zusammengefasst. In einem
noch detaillierter zu konfigurieren (z. B. zusätzlichen Team werden technische
bestimmte Serviceeigenschaften, die er- Anwendungsszenarien Infrastrukturaufgaben bearbeitet, hier
füllt sein müssen, oder diverse Timeouts Wie bzw. wo nutzt man so ein System? wird auch GEPPI weiterentwickelt und
wie ein Ausführungs-Timeout). Die Eine ExecutionUnit kann prinzipiell betrieben.
ServiceCallAction delegiert den Auftrag auf jedem Betriebssystem installiert Durch den fachlichen Zuschnitt der
asynchron an eine zentrale Komponen- werden, um so alle möglichen Arten Projektteams können innerhalb eines
te, die sich anhand der Jini Registry pas- von Programmen aufrufen zu können. jeden Teams die jeweils zugehörigen
sende Dienste sucht, diese in eine kon- Sei es über die sehr breite und allgemei- GEPPI-Services und der entsprechen-
figurierbar sinnvolle Reihenfolge bringt ne Ant-Adapterschicht, über das Ant- de Teil des Gesamtprozesses, realisiert
und den optimalsten Dienst beauftragt Plug-in oder durch eine sehr konkrete als Subworkflow [3], entworfen, imple-
www.JAXenter.de javamagazin 2|2010 95
SOA Center SOA Praxis bei 1&1
mentiert und betrieben werden. Für lich der ablaufenden Geschäftsprozesse einzuhalten oder gegebenenfalls Al-
domänenübergreifende Prozesse ist können verwendet werden, um diverse ternativmaßnahmen wie Notfallpläne
zusätzlich meist nur noch ein schlanker Sichten wie eine Art Frühwarnsystem einleiten zu können.
Superworkflow nötig, der die Klammer bereitzustellen. Auch Interpretationen
um die fachdomänenspezifischen Sub- von Veränderungen in den Prozessen Feedback
workflows bildet. sind als Report denkbar (z. B. Auswir- Für uns als Begründer dieser Ausprä-
kungen bei Änderung des Datenvolu- gung einer pragmatischen SOA ist es
Zusammenfassung mens auf die Prozesslaufzeit). Darüber natürlich interessant zu wissen, wie
Mit der General Enterprise der Rest der SOA-Welt
Process and Planning Infra- diesen Ansatz und diese
structure wurde bei der 1&1 Für domänenübergreifede Konzepte einschätzt. Ge-
Internet AG eine Steuerung rade der Austausch von
eines verteilten Systems auf- Prozesse ist nur noch ein Erfahrungen rund um die
gebaut, die sowohl technisch SOA-Welt ermöglicht uns,
als auch fachlich und organi- schlanker Superworkflow nötig mögliche Schwachstellen
satorisch in ihren Konzepten frühzeitig zu erkennen
einer serviceorientierten Architektur hinaus ist eine Planungskomponente und anzugehen. Unter www.pragma-
entspricht. Abweichungen von typi- geplant, die die zur Verfügung stehen- tic-soa.de [8] freuen wir uns über euer
schen SOA-Umsetzungen finden sich den Ressourcen in Echtzeit überwacht Feedback (dort findet ihr auch noch mal
bei den technischen Konzepten und den und die Workflows entsprechend be- ein paar Details mehr sowie ein kleines
eingesetzten Technologien. So wurde einflussen kann, um Ablauftermine Demovideo).
u. a. anstelle eines zentralen Enterprise
Service Bus auf eine verteilte Infrastruk-
Matthias Wittum ist Software Engineer bei der 1&1 Internet AG in Karls-
tur auf Basis von Jini gesetzt und die ruhe. Sein Aufgabenbereich umspannt die architekturelle Weiterentwick-
Kopplung der Services auf technischer lung einer hausinternen SOA in einem sehr agilen Umfeld. Ansonsten gilt
Ebene durch die vollständige Transpa- seine Aufmerksamkeit weiteren spannenden Einflussfaktoren der Soft-
renz des Kommunikationsprotokolls wareentwicklung wie technologische Reife neuer Frameworks, Trends und
Entwicklungen der Branche und dem Faktor Mensch als komplizierteste,
mit einem Agenten (der ExecutionUnit) aber auch wesentlichste Größe.
und Adapterskripten minimiert.
Mit dem bewussten Verzicht auf ei-
nige typische SOA-Funktionalität haben Dirk Schmid beschäftigt sich als Software Engineer bei der 1&1 Internet AG
wir die Komplexität des Systems deut- mit der Entwicklung von SOA, BPM und Grid-Infrastrukturen im Umfeld einer
massiv parallelen und hochverfügbaren Unternehmenslandschaft. Die Architek-
lich verringert. Dazu zählen z. B. der in
tur von GEPPI hat er von Anfang an geprägt und ist bis heute in die Weiterent-
der Architektur verankerte Verzicht auf wicklung involviert. Durch seine mehrjährige Beratertätigkeit kann er aus einem
Composite Services, die Unsichtbarkeit reichen Schatz an Technologien, Verfahren und Lösungsansätzen schöpfen.
der technischen Services für die Busi-
nessservices oder die Beschränkung der
Routing-Funktionalität. Dr. Thomas Breitkopf ist Entwickler und Projektleiter bei der 1&1 Internet
AG. Er hat in 10 Jahren als Softwareentwickler umfangreiche Erfahrung
Die Vorteile dieser Selbstbeschrän-
mit verteilten Systemen in unterschiedlichen Technologien gesammelt. Seit
kung liegen in der verringerten Kom- einiger Zeit gilt sein Interesse der serviceorientierten Architektur und den
plexität der Technik, der dynamischen Konzepten dahinter. Daneben beschäftigt er sich mit agilen Methoden der
Erweiterbarkeit und dem einfachen Be- Softwareentwicklung.
trieb. Die Umsetzung von Anwendun-
gen und das Einbinden bereits bestehen-
der Funktionalität in die SOA ist einfach Links & Literatur
und sehr schnell zu bewerkstelligen. [1] Apache River: http://incubator.apache.org/river/RIVER
Mit Java als Basistechnologie und Ant [2] Oliver Wolf: „Open Source SOA“, in Java Magazin 2.2009
als wichtigster Adapterskriptsprache [3] JBoss jBPM: http://www.jboss.com/products/jbpm/
konnte außerdem eine weitgehende Un- [4] Maier, Normann, Trops, Utschig-Utschig, Winterberg: „Die SOA-Service-Kategori-
abhängigkeit von Betriebssystem und enmatrix“, in Java Magazin 2.2009 und SOA Spezial Vol. 1
Plattform erreicht werden. [5] Pentaho Data Integration: http://www.pentaho.com/products/data_integration/
[6] GEPPI-Projekthomepage: http://www.pragmatic-soa.de
Wo geht der Weg hin? [7] Maier, Normann, Trops, Utschig-Utschig, Winterberg: „Lose Kopplung – Warum
2010 steht vor allem im Zeichen von das Loslassen verbindet“, in Java Magazin 3.2009 und SOA Spezial Vol. 1
Komfort und Bedienerfreundlichkeit. [8] Nicolai M. Josuttis: „SOA in Practice“, O’Reilly
Viele der vorhandenen Daten bezüg-
96 javamagazin 2|2010 www.JAXenter.de
1/1 SOA Special
Sie können auch lesen
