Java Magazin 8.2007

8.07Deutschland € 6,50Niederlande € 7,80Österreich € 7,50Schweiz sFr 12,70AufCDAlle Infos auf S. 3Internet & Enterprise TechnologyTestversionen & more• JAX-TV: Interview mit Dierk König• TeamCity 2.1• Groovy 1.0• Ivy 1.4.1• Apache Forrest 0.8• DbUnit 2.2www.javamagazin.de➔ Lesen Sie im Heft ab Seite 67!OSGi➔ Komponenten in Java, jetzt aber richtig!➔ Mit Eclipse OSGi-Bundles entwerfenDie Zukunft Javas?SOA mit Open SourceWas leisten die freien Tools?JSF im HärtetestPraxis in großen ProjektenReporting unternehmensweitEin Bericht sagt mehr als 1.000 ZeilenZahlen & FaktenJSR 275: Internationalewissenschaftliche FormateSpring-FrameworkAvalon-Spring-Migration –ein PraxisberichtCrossmedia mit XMLApache Forrest bedient viele FormateD 45 86 7

Open Source SOARealisierung einer serviceorientierten Architektur auf der Basis von Open SourceSOA auf die leichte ArtVON WOLFGANG PLEUSDerzeit positionieren sich die Großen der Branche als Anbieter von Plattformen für serviceorientierte Architekturen(SOA). Dies lässt erahnen, wie bestimmend das SOA-Paradigma für die nähere Zukunft sein wird. Auchjenseits der etablierten Anbieter entstehen anspruchvolle Produkte im Open-Source-Bereich, die jedoch mangelsMarketing oft kaum wahrgenommen werden. Dabei haben auch diese Produkte eine Menge zu bieten.Getrieben vom eigenen Produktportfoliohat jeder Hersteller eine eigene Vorstellungvon der technischen Ausgestaltung einerserviceorientierten Architektur. Unabhängigvon den Unterschieden finden sich aberimmer wieder gleiche Funktionalitäten,sodass eine serviceorientierte Referenzarchitekturin der Regel einen oder mehrereBausteine aus Tabelle 1 umfasst.Der Enterprise Service Bus sowie dasBusiness Process Management stellen dieKernfunktionalitäten einer SOA bereit, dasie es ermöglichen, Prozesse zu definierenund auszuführen. Eine Rule Engine erlaubtes, fachliche Regeln in die Prozesse einzubeziehenund dynamisch anzupassen. Mitzunehmender Komplexität einer SOAQuellcode auf CDwird die Verwaltung von Services, Regelnoder Richtlinien erschwert. Eine Registry/Repository hilft dabei, die Komplexität zubeherrschen. Sicherheitsaspekte wie Authentifizierungund Autorisierung werdendurch ein Identity-Management-Systemabgebildet. Und schließlich bedarf es derMöglichkeit, eine SOA zu überwachen.Da die Interaktion häufig asynchron undverteilt abläuft, stellt dies eine echte Herausforderungdar. Durch Health Trackinglassen sich Fehlersituationen aufspürenund beseitigen, während Business ActivityMonitoring zur statistischen Aufbereitungder erfassten Daten dient. Daduchlassen sich beispielsweise Nutzungsprofilefür einzelne Services erstellen.Open-Source-BausteineMit Ausnahme der Tracking- und Monitoring-Funktionalitätgibt es für die obengenannten Bausteine Open-Source-basierteImplementierungen mit einem zufriedenstellendenReifegrad (Tabelle 2).Da es den Umfang des Artikels sprengenwürde, alle Bausteine im Detail zu betrachten,konzentrieren wir uns zunächstauf die Kernbausteine Enterprise ServiceBus und Business Process Management.Mit Apache ServiceMix steht ein JavaBusiness Integration-(JBI-)konformerESB zur Verfügung, während ApacheOde die Laufzeitumgebung für BusinessProcess Execution Language (BPEL) bereitstellt.JBI [6] ermöglicht die herstellerunabhängigeWiederverwendung vonJBI-Komponenten und erhöht somit dieInvestitionssicherheit. Dieses Versprechenist nicht neu, wurde ein ähnlichesZiel doch auch mit EJB als Komponentenmodellverfolgt. Dies war aber nurbedingt erfolgreich, da wichtige Detailswww.javamagazin.de8.200767

Open Source SOAAbb. 1:IntegriertesSzenariounterscheiden. Mediationsprozesse dienender Entkopplung von Services, indemsie zwischen dem Konsumenten und demAnbieter vermitteln. Mediation umfasst:• Protokollumsetzung, zum Beispiel vonFTP nach HTTP• Formatkonversion, zum Beispiel Flat-File nach XML• Schematransformation, zum BeispielKunde1.xsd nach Kunde2.xsd• Routing, zum Beispiel Auftragswert> 500 – Lieferant A sonst Lieferant Bwie Verteilung und Verwaltung nicht imStandard geregelt waren.Wie es scheint, hat man dazugelerntund neben der Interaktion und Packetierungder Komponenten auch spezifiziert,wie eine Komponente installiert, gestartetund gestoppt wird. Zudem sind die Verantwortlichkeitenvon JBI-Komponentenklar umrissen. Es wird zwischen BindingComponents und Service Engines unterschieden.Während erstgenannte dieKommunikation zur Außenwelt regeln,also beispielsweise Protokolle wie FTP,FILE oder HTTP implementieren, sindletztere für die interne Verarbeitung bestimmt.Dazu gehören beispielsweiseXSLT-Transformationen oder die Implentierungvon Interaktionsmustern wieSplitter oder Pipeline. Eine vollständigeListe der verfügbaren Komponenten stehtauf der ServiceMix-Website zur Verfügung[1].Apache Ode [2] stellt eine Laufzeitumgebungfür BPEL4WS 1.1- und WS-BPEL2.0-konforme Prozesse zur Verfügung.Die Integration von Ode und ServiceMixerfolgt über eine JBI Service Engine.ProzesseJe nachdem, in welchem Kontext eineserviceorientierte Architektur entsteht,liegt der Schwerpunkt entweder auf derIntegration bestehender Systeme (EAI)oder der Abbildung von Geschäftsprozessen(BPM). Dies führt regelmäßig zuMissverständnissen. Während die BPM-Fraktion meist reflexartig mit BPEL oderBPMN als Mittel der Wahl antwortet,führen die EAI-Verfechter meist die Möglichkeitendes ESB ins Feld. Dabei führtdie naive Anwendung der einen oder anderenTechnologie selten zum Erfolg. Inder Praxis hat es sich bewährt, zwischenMediations- und Geschäftsprozessen zuBausteinVerantwortlichkeitEnterprise Service Bus (ESB)Entkopplung von Services, VermittlungBusiness Process Management (BPM) Abbildung von GeschäftsprozessenRule EngineDynamische Änderung von RegelnRegistry/RepositoryVerwaltung von ArtefaktenIdentity ManagementAuthentifizierung, Autorisierung, Single Sign-OnHealth Tracking / Activity Monitoring (BAM) ÜberwachungTabelle 1: Bausteine einer SOABausteinVerantwortlichkeitEnterprise Service Bus Apache ServiceMix [1], Codehaus Mule [15], Sun OpenESB [16]Business Process Management Apache Ode, JBoss jBPM [17], Intalio BPMS [14]Rule Engine JBoss Drools [11]Registry/Repository Apache jUDDI [10]Identity Management Internet 2 Shibboleth [9]Tabelle 2: Open-Source-BausteineGeschäftsprozesse dagegen modellierenProzesse mit Relevanz zur jeweiligen fachlichenDomäne. Beispielsweise könnte einkomplexer, lang laufender Buchungsprozessüber BPEL abgebildet werden. Einerder Vorteile ist die grafische Repräsentationdes Prozesses und die damit verbundeneeinfachere Kommunikation mit denFachbereichen. Mediationsprozesse undGeschäftsprozesse ergänzen sich somit.SzenarioSoweit zur Theorie. Im Folgenden soll gezeigtwerden, wie sich Prozesse mit Open-Source-Technologien implementieren lassen.Als Beispiel dient das fiktive Szenarioeiner Hotelbuchung (Abb. 1).Im Kern steht dabei ein Geschäftsprozess,der in BPEL implementiert und in ApacheOde ausgeführt wird. Der Geschäftsprozessnutzt einen Service tour operator,der als POJO implementiert ist und durchdie Komponente servicemix-jsr181 anden ESB angebunden wird. Dies stellt dieeinfachste Methode dar, um einen Servicebereitzustellen. Hier wäre es auch möglich,externe Services beispielsweise über HT-TP anzubinden. Der Service tour operatorliefert eine Liste möglicher Hotels in unterschiedlichenPreislagen. Der Geschäftsprozessermittelt das günstigste Hotel undsendet das Ergebnis an den Aufrufer. DerGeschäftsprozess kann entweder synchronüber SOAP/HTTP oder asynchron überXML/Filedrop aufgerufen werden. DieVermittlung und Umsetzung übernimmtder Mediationsprozess im ESB.Die Einbindung einer Rule Enginedurch die Komponente servicemix-droolswäre ebenfalls möglich. Diese würde sichanalog zu servicemix-jsr181 als Service68 8.2007 www.javamagazin.de

Open Source SOAin den ESB integrieren. Prinzipiell ist essekundär, welche Technologie für die Entwicklungeines Service verwendet wird.BPEL, Drools, Groovy oder POJOs sindgleichberechtigt und für den Aufrufertransparent. Der Aufruf erfolgt immerüber klar definierte Schnittstellen. Somitstellt der ESB zusätzlich zur Mediationsfunktionalitäteine Laufzeitumgebung fürServiceimplementierungen bereit.ArtefakteDie Entwicklung von prozessbasiertenSystemen erfolgt zum großen Teil deklarativ.Einzig der tour operator-Service istin Java realisiert. Bei BPEL verschwimmendie Grenzen zwischen deklarativeroder imperativer Programmierung. Spätestenswenn komplexe Zuweisungenoder Transformationen entwickelt werdensollen, sind handfeste Entwicklungskenntnisseerforderlich.Die Hauptaufgabe bei der Entwicklungbesteht darin, die JBI-konformenArtefakte zu erstellen. JBI unterscheidetzwischen Komponenten, Service Unitsund Service Assemblies (Abb. 2).Komponenten werden einmalig in derJBI-Laufzeitumgebung installiert. Dabeikann es sich um bereits verfügbare oderselbst entwickelte Komponenten handeln.Um eine Komponente zu nutzen, muss sieparametrisiert werden. Dies erfolgt durcheine Service Unit. Eine Service Unit ist eineZIP-Datei mit den für eine Komponenteerforderlichen Konfigurationsdateien. DieseDateien können für jede Komponenteunterschiedlich sein. Beispielsweise enthältdie Service Unit booking-ode-su.zipunter anderem eine BPEL-Datei für denBuchungsprozess, während booking-filesu.zipnur die Datei xbean.xml enthält.Die ServiceMix-Komponenten werdenüber XBean [3] konfiguriert, sodass dieDatei xbean.xml in den meisten ServiceUnits zu finden ist. Listing 1 zeigt dies amBeispiel der Konfiguration für die Komponenteservicemix-http.Die Konfiguration der Endpunkte istabhängig von der jeweiligen Komponente.Ein Endpunkt beschreibt den Einstiegspunktfür den Aufrufer innerhalb des ESB.Die Angaben service und endpoint adressiereneinen Endpunkt eindeutig. Über diein Listing 1 gezeigt Konfiguration könnteAbb. 2: JBI-Artefaktebeispielsweise der touroperator serviceals Web Service über HTTP bereitgestelltwerden.In der Regel bilden mehrere ServiceUnits einen Verbund, der beispielsweiseum einen Mediationsprozess abzubilden.Dieser Verbund wird in Form einer ServiceAssembly realisiert. Dabei handeltes sich ebenfalls um eine ZIP-Datei, diealle erforderlichen Service Units enthält.Eine Service Assembly ist die Einheit, diein den JBI-Container deployt wird. JedesJBI-Artefakt enthält einen Deskriptor mitNamen jbi.xml, der zusätzliche Informationengemäß der JBI-Spezifikationenthält. Diese Deskriptoren werden, wiespäter noch zu sehen sein wird, vollständiggeneriert, sodass der Inhalt an dieserStelle nicht relevant ist.EntwicklungsprozessAls Entwicklungsumgebung bietet sichdie Kombination von Maven2 für denListing 1wsdl/in-out“Build-Prozess, eine Java-Entwicklungsumgebungfür die Bearbeitung von Javaund XML sowie ein BPEL-Designeran. Einen wirklich vollständigen, freienBPEL-Designer gibt es momentan nochnicht, vielversprechend sind aber Net-Beans 5.5 inklusive Enterprise Pack [4]und das Eclipse BPEL-Designer-Plug-in.Insbesondere NetBeans verfügt über eineanspruchsvolle, BPMN-ähnliche Visualisierung,unterstützt aber noch nichtall BPEL-Merkmale, wie beispielsweiseKompensation. Dafür verfügt es über einenBPEL Mapper, der bei der Erstellungvon BPEL Assigns hilfreich ist (Abb. 3).Listing 24.0.0net.pleus.globaltravelbooking-ode-su1.0jbi-service-unitbooking-ode-suorg.apache.odeode-jbi2.0-SNAPSHOTorg.apache.servicemix.toolingjbi-maven-plugintruewww.javamagazin.de8.200769

Open Source SOAAbb. 3: NetBeansBPEL-DesignerUm den manuellen Aufwand für dieErstellung der JBI-Artefakte zu minimieren,bietet ServiceMix das Maven-Plug-injbi-maven-plugin, mit dessen Hilfe sichService Units, Service Assemblies undJBI-Komponenten inklusive der jbi.xml-Deskriptoren generieren lassen. Listing 2zeigt die Maven-Datei pom.xml zur Generierungeiner Service Unit für die OdeBPEL Engine.Die Komponente, auf die sich die ServiceUnit bezieht, wird durch das dependency-Elementangegeben. Die Angabejbi-service-unitbewirkt die Erstellung einer Service Unitmit Namen booking-ode-su-1.0.zip. Ummehrere Service Units zu einer Service Assemblyzusammenzufassen, kann das MavenPom aus Listing 3 verwendet werden.Dieses Mal wird jbi-service-assemblyangegeben.Die dependencies-Auflistung enthält Informationenzu den enthaltenen Service Units.Listing 3 verwendet exemplarisch die ServiceUnit für die Ode BPEL Engine. DasErgebnis der Ausführung des Kommandosmvn install ist eine Service Assembly mitNamen globaltravel-sa-1.0.zip.Deployment und ManagementEine JBI-konforme Laufzeitumgebungmuss Java Management Extensions (JMX)in der Version 1.2 unterstützen. Durch diebereitgestellten MBeans lassen sich die folgendenOperationen ausführen:• Installation von Komponenten und gemeinsamgenutzten Bibliotheken im laufendenServer (Hot Deployment)• Hot Deployment von Service Units undService Assemblies für installierte Komponenten• Starten und Stoppen von Komponentenund Service AssembliesZusätzlich zu diesem Ansatz unterstütztServiceMix auch Hot Deployment überdas Dateisystem. Nach der Installationder Distribution stehen die Verzeichnisseinstall und deploy bereit. Standardmäßigsind dort noch keine Komponenteninstalliert. Diese stehen im Verzeichniscomponents bereit. Um eine Komponentezu installieren, muss sie lediglich in dasinstall-Verzeichnis kopiert werden. AllgemeineKlassen sind in der Bibliothekservicemix-shared enthalten. Daher mussdiese zuerst installiert werden.Die Komponente ode-jbi für die BPEL-Integration ist nicht Teil der ServiceMix-Distribution und muss manuell erstelltwerden. Eine Beschreibung dazu findetsich auf der Website von Apache Ode [2].70 8.2007 www.javamagazin.de

Open Source SOAService Assemblies, wie beispielsweiseglobaltravel-sa-1.0.zip aus demBeispiel, werden durch Kopieren in dasdeploy-Verzeichnis bereitgestellt. Zusätzlichzu den JBI-konformen Merkmalenstellt ServiceMix noch ein leichtgewichtigesVerfahren für das Deploymentzur Verfügung. Dabei werden Komponentendirekt in der Startkonfigurationservicemix.xml parametrisiert, die sichim Verzeichnis conf befindet. Da diesesVerfahren aber kein Hot Deploymenterlaubt und nicht standardkonform ist,sollten bestenfalls Prototypen auf dieserBasis erstellt werden. Idealerweise solltedie Datei servicemix.xml nur die unmittelbareKonfiguration des Containersenthalten.Durch die JMX-Fähigkeit kann jederbeliebige JMX-Client, wie beispielsweiseJConsole für die Administration genutztwerden (Abb. 4).Die Abbildung zeigt die installiertenKomponenten sowie die Service Assemblyund Service Units. Alle MBeanssind ebenfalls über Ant-Tasks erreichbar,die ebenfalls Teil der JBI-Spezifikationsind. Somit lässt sich der gesamte Build-Prozess inklusive Packetierung und Verteilungautomatisieren.Erfahrungen und PotenzialeAbb. 4: JMX-ManagementDie gebotene Funktionalität ist bereitssehr leistungsfähig. Dennoch gibt es Bereiche,in denen es Verbesserungspotenzialgibt. Durch den Zugriff auf den Sourcecodelassen sich fehlende Merkmale mitvertretbarem Aufwand selbst entwickeln.Die folgenden Abschnitte zeigen dies aneinigen Beispielen.Sowohl ServiceMix als auch Ode befindensich noch im Inkubationsstatus.Obwohl es zahlreiche Implementierungsbeispielegibt, ist die Entwicklung nichttrivial. Oft sind es Kleinigkeiten, die dieArbeit erschweren. Da viele Fehler erstzur Laufzeit sichtbar werden, wie z.B.unterschiedliche XML-Namensräume inden Deskriptoren, sind diese nur schwerzu lokalisieren. Eine aktive Communityund verschiedene Online-Foren [7], [8]stehen als Hilfe zur Verfügung. Die Reaktionszeitensind kurz und liegen meistunterhalb einer Stunde.AktivierungIn klassische Anwendungen, wie beispielsweiseWebanwendungen, werdenListing 34.0.0net.pleus.globaltravelglobaltravel-sa1.0jbi-service-assemblyglobaltravel-sanet.pleus.globaltravelbooking-ode-su1.0Anzeige...org.apache.servicemix.toolingjbi-maven-plugintruewww.javamagazin.de

Open Source SOAAbb. 5: Broker-NetzwerkProzesse häufig durch Zugriff von außenaktiviert. Dieses Muster wird auch vonServiceMix, beispielsweise durch dieBinding Component servicemix-http,unterstützt. In prozessgetriebenen Szenarienerfolgt die Aktivierung ebenfallsvon innen. Beispielsweise dann, wennregelmäßig Daten von einem FTP Serverabgeholt werden sollen. Diese Art vonProzess wird in der Regel zeitgesteuertaktiviert. Die ServiceMix-Binding Componentsunterstützen einen einfachen, intervallgesteuertenMechanismus. Bei derKonfiguration einer Komponente für denDatentransfer über FTP oder das Dateisystemwird ein Intervall angegeben, wiedas folgende Beispiel zeigt:Für eine genauere Steuerung steht dieKomponente servicemix-quartz zurVerfügung. Diese erlaubt die Planungkomplexer Abläufe beispielsweise durchCron-Ausdrücke. Allerdings werdenBinding Components nicht durch eineNachricht über den ESB aktiviert, sodasseine Verbindung von servicemix-httpund servicemix-ftp nicht funktioniert.Listing 4Eine Lösung besteht in der Entwicklungeiner kombinierten Binding Component/ServiceEngine, die sowohl durcheine Nachricht über den ESB aktiviert alsauch Daten externe Systeme anbindet.ServiceMix stellt dafür die BasisklassenDefaultComponent, ProviderEndpointund ConsumerEndpoint im Paket org.apache.servicemix.common zur Verfügung.Im Zusammenhang mit dem Service-Mix-Maven-Plug-in und der Angabejbi-componentbeschränkt sich der Aufwand aufein Minimum. Die Unterscheidung zwischenBinding Components und ServiceEngines ist eher konzeptioneller Natur.Auf technischer Ebene sind die Unterschiedemarginal.ÜberwachungHealth Tracking und Activity Monitoringstellen wichtige Bestandteile einerserviceorientierten Architektur dar.Beide basieren auf Informationen, diewährend der Prozessausführung aufgezeichnetwerden. Eine vollständige,produktionsfähige Lösung bietet wederServiceMix noch Ode an. Beide unterstützenjedoch die Registrierung eigenerListener, die bei ausgewählten Ereignissenaufgerufen werden. Dadurch lässtsich ein eigenes Tracking realisieren. ServiceMixerfordert die Implementierungder Schnittstelle org.apache.servicemix.jbi.event.ExchangeListener. Die JAR-Datei mit der Listener-Implementierungmuss in das Verzeichnis lib der ServiceMix-Distributionkopiert werden.Zudem muss der eigene Listener in derDatei servicemix.xml registriert werden(Listing 4).Der Listener wird bei jeder über denESB gesendeten Nachricht aufgerufen.Aus den übermittelten Daten lassen sichder Prozessfluss und etwaige Fehler derKomponenten ableiten.Um einen Listener für Ode zu erstellen,muss die Schnittstelle org.apache.ode.bpel.iapi.BpelEventListener implementiertwerden. Aufgrund einer Classloader-Problematikmuss der ListernerBestandteil der JAR-Datei der Ode-Komponentewerden. Die JAR-Datei mit derImplementierung wird dazu in der Dateipom.xml für Ode als Abhängigkeit definiert.Der Listener wird in der Datei odejbi.propertieswie folgt registriert:ode-jbi.event.listeners=net.pleus.globaltravel.tracking.OdeListenerNach der Kompilierung von Ode ist derListener integraler Bestandteil der Komponenteode-jbi und wird mit ihr im ESBinstalliert. ServiceMix stellt einfache Listenerfür JDBC und Lucene im Paket org.apache.servicemix.jbi.audit bereit.Produktiver EinsatzDas wohl wichtigste Kriterium bei derAuswahl einer Technologie ist die Einsetzbarkeitim produktiven Umfeld.Hierbei sind Merkmale wie Skalierbarkeit,Hochverfügbarkeit und Lastverteilungentscheidend. ServiceMix basiertauf Apache ActiveMQ [12] als MessageBroker das wiederum Apache Derby [13]als Datenbank für persistentes Messagingeinsetzt. Beide Produkte erlauben einesehr flexible Konfiguration, die sowohleine eingebettete, als auch eine im Netzverteilte Ausführung ermöglichen. ServiceMixlässt sich sehr gut in einem Broker-Netzwerk betreiben. Dabei werden mehrereidentische Knoten eingesetzt und aufder Ebene von ActiveMQ miteinanderverbunden. Diese Konfiguration wird alsNetwork of Brokers bezeichnet und lässtsich durch den Einsatz weiterer Knotensehr gut skalieren (Abb. 5).Durch den Einsatz identischer Knotenkann Hochverfügbarkeit bezogenauf das Broker-Netzwerk erreicht werden.Wenn einer der Knoten fehlerhaftist, stehen immer noch die anderenKnoten für die Verarbeitung bereit. Dieausgeführten Prozesse des fehlerhaftenKnotens können allerdings nicht fort-72 8.2007 www.javamagazin.de

Open Source SOAgesetzt werden. Um Hochverfügbarkeitfür einzelne Knoten zu erreichen, kannActiveMQ in einer Master/Slave-Konfigurationbetrieben werden, wobei jedemMaster Broker ein oder mehrere SlaveBroker zur Seite gestellt werden. Diesereplizieren alle Nachrichten. Im Fehlerfallübernimmt einer der Slave Brokerdie Verarbeitung und wird selbst zumMaster.ActiveMQ implementiert Lastverteilungnach dem Round-Robin-Prinzip.Wenn ein Endpunkt auf mehreren Knotenin einem Cluster bereit steht, wird dieLast gleichmäßig auf den gesamten Clusterverteilt. Wenn ein Endpunkt nur aufeinem Knoten zur Verfügung steht, wirddie Nachricht an diesen Knoten gesendet.Dadurch ist auch eine Distributed-Broker-Konfiguration realisierbar. Dasbedeutet, der ESB umfasst mehrere Knoten,wobei die Knoten unterschiedlicheKomponenten und ServiceAssembliesenthalten können. Ein Mediationsprozesskann so auf den gesamten Clusterverteilt werden. Das kann erforderlichsein, wenn Komponenten eingesetztwerden, die eine spezielle Hardware oderLizenz benötigen, beispielsweise für eineVerbindung zum Mainframe. Durch einenDistributed Broker lassen sich dieseKomponenten vom Rest des Clustersisolieren, wodurch Kosten gespart werdenkönnen.Die beschriebene Lastverteilung beziehtsich auf die Verteilung innerhalbdes Clusters. Ein vorgeschalteter LoadBalancer wird benötigt, um die Last aufdie einzelnen Knoten aufzuteilen. Füreingehende Kommunikation wie HT-TP sind Verfahren, wie beispielsweiseHardware Load Balancer weitgehendetabliert.Für ausgehende Kommunikation, wieFTP oder File, sind diese Verfahren jedochnicht brauchbar, da diese Komponentenintern aktiviert werden. ServiceMixverfügt noch nicht über Synchronisationsmechanismenfür Komponenten imCluster, sodass in der Beispielanwendungbeide File-Komponenten gleichzeitigdieselbe Datei verarbeiten würden. EineLösung kann darin bestehen, einen Aktiv/Passiv-Cluster für alle intern aktiviertenKomponenten zu verwenden und alle anderenKomponenten in einem Aktiv/Aktiv-Clusterbereitzustellen.FazitMit Apache ServiceMix und ApacheOde stehen die Kernbausteine für dietechnische Implementierung einer serviceorentiertenArchitektur zur Verfügung.Zwar ist an einigen Stellen eigenerEntwicklungsaufwand erforderlich, umfehlende Merkmale zu realisieren. Aberdennoch lohnt sich der Aufwand, da sichauf dieser Basis bereits heute eine 100%Open-Source-basierte und standardkonformeSOA-Infrastruktur realisierenlässt.Der vollständige Quellcode zu diesemArtikel befindet sich auf der beiliegendenCD.Wolfgang Pleus arbeitet als Technologieberater,Autor und Trainer im Bereich serviceorientierterArchitekturen. Seit über10Jahren unterstützt er internationale Unternehmenbei der Realisierung komplexerGeschäftslösungen auf der Basis von Java EE und .NET.Sie erreichen ihn unter wolfgang.pleus@pleus.net.Links & Literatur[1] Apache ServiceMix:incubator.apache.org/servicemix[2] Apache Ode: incubator.apache.org/ode[3] Apache Xbean: geronimo.apache.org/xbean[4] Netbeans: www.netbeans.org[5] Eclipse BPEL Designer: download.eclipse.org/technology/bpel/update-site[6] JBI Spezifikation: jcp.org/aboutJava/communityprocess/final/jsr208/index.html[7] Apache Ode User Forum: www.nabble.com/Apache-Ode-User-f16255.html[8] ServiceMix User Forum: www.nabble.com/ServiceMix---User-f12050.html[9] Shibboleth: shibboleth.internet2.edu[10] jUDDI:ws.apache.org/juddi[11] JBoss Rules (Drools): labs.jboss.com/portal/jbossrules/docs[12] Apache ActiveMQ: activemq.apache.org[13] Apache Derby: db.apache.org/derby[14] Intalio: www.intalio.com[15] Codehaus Mule: mule.codehaus.org[16] Sun OpenESB: open-esb.dev.java.net[17] JBoss jBPM: www.jboss.com/products/jbpmFeedbackDie Redaktion freut sichüber Ihr Artikel-Feedback:feedback@javamagazin.deAnzeigewww.javamagazin.de