GOOGLE

Plus CD!JAX TV, Tools, BeispieleStellenmarkt 46Deutschland € 7,50D 45 86 7Österreich € 8,60 Schweiz sFr 15,80Java • Architekturen • SOA • Agilewww.javamagazin.de8.08SOA CenterSchöne globalisierteServicewelt?Servicekommunikation zwischen Javaund .NET mithilfe von WSIT 76EnterpriseJBoss ESB im EinsatzSo kontrollieren Sie Komponentenheterogener Systeme 40WebAutomatisch TestenWebtests mit Selenium, Groovy,TestNG und Maven 65GOOGLEANDROIDSo funktioniert‘s 92ToolsLego-Roboter mit JavaprogrammierenleJOS: Java für Lego Mindstorms 103ArchitekturArchi-Zack!-tureAuf Gratwanderung zwischenArchitektur und Entwicklung 58CD-Inhalt Alle CD-Infos 3JAX 2008KEYNOTE VONMARTIN ODERSKY:SCALA –The Challenge ofScalable LanguagesAlle Quellcodes & Beispiele!Testversionen und ToolsApache Axis2, JAX-WS 2.1.4, Metro, Milyn Smooks,Spring Web Services, Spring Integration, Apache Felix,Maven 2.0.9, Equinox, Grails 1.0.3, Selenium, CXFOSGi 52ZukunftsentwürfeOSGi ist in aller Munde. Das „nächste Dingnach Spring“ adressiert Themen, die für dieAnwendungsarchitektur relevant sind: Mittelzum Abhängigkeitsmanagement etwa oderdas dynamische Servicemodell. Will man vonOSGi profitieren, sollten beim Applikationsentwurfeinige Aspekte beachtet werden.Neue Serie 100Effective JavaKlaus Kreft und Angelika Langer werden inZukunft regelmäßig im Java Magazin unterdem Titel „Effective Java“ über Fallstrickeund aktuelle Themen aus dem Bereich desJava-Sprachkerns und des JDKs berichten.In dieser Ausgabe beginnt eine Reihe überAspekte des Java-Memory-Modells.Datenträger enthält nur Lehr- oder Infoprogramme

SOA-TransformationSOA CenterSOA-Transformation –Rollen und TeamsWie der organisatorische Übergang von der klassischen zur serviceorientierten Softwareentwicklunggelingen kann – Der zweite Teil dieser Serie beschäftigt sich mit denorganisatorischen und personellen Veränderungen, die mit einer SOA-Transformationeinhergehen.von Wolfgang Pleusn der IT-Branche werden Unternehmenund Softwareentwicklerpermanent mit neuenParadigmen konfrontiert. Sei es Objektorientierung,Schichtenarchitekturenoder Dependency Injection, immerwieder ändert sich die Art, wie Softwareentwickelt wird. Während diese Paradigmenwechseleine ständige Anpassungund Weiterentwicklung etablierter Entwicklungsmethodenerfordern, bleibtdie Rollenverteilung in den Teams weitgehendunverändert. Dies erleichtert dieUmstellung auf das jeweils neue Paradigma,da sich die Organisation als solchenicht verändert. Im Gegensatz dazuhandelt es sich bei dem serviceorientiertenParadigma zu etwa gleichen Teilenum ein technisches wie auch organisatorischesThema. Damit wird eine Umstellungungleich schwieriger, da zusätzlichzu den technischen ebenso personelleAspekte berücksichtigt werden müssen.In der Praxis stellt die Vernachlässigungder organisatorisch-personellen Aspektedas Hauptrisiko für eine nachhaltigeSOA-Einführung dar.Klassische TeamsIn heutigen IT-Projekten finden sichbestimmte Rollen immer wieder (Abb.1). Dazu gehören Entwickler mit unterschiedlichemSpezialisierungsgrad,zum Beispiel für Client- und Serverprogrammierungsowie Projektleiter, dieden Ablauf koordinieren und die Projektplanungübernehmen. In der Regelfinden sich diese Rollen in jedem Einzelprojektwieder. Daneben gibt es einigezentrale Rollen. Die Analysten arbeitenin den Fachabteilungen und definierendie fachlichen Anforderungen an dieAnwendungen. Architekten gestaltendie Konsistenz der Anwendungen undder gesamten IT-Landschaft. Danebengibt es Tester, die sicherstellen, dass dieAnwendungen vor der Inbetriebnahmedie funktionalen und nichtfunktionalenAnforderungen erfüllen. Es kommt auchvor, dass die zentralen Rollen projektspezifischbesetzt sind. In diesem Fall verfügtein Projekt über eigene Tester und/oder Architekten. Zudem können mehrereRollen von einer Person verkörpertwerden. Dies ist beispielsweise der Fall,wenn ein Architekt ebenfalls Entwicklungsaufgabenübernimmt.Während diese Rollen in einemprojektzentrischen Umfeld adäquatsind, sind sie in einem serviceorientiertenUmfeld in der Regel nicht mehrausreichend. Der Grund ist vor allemder wesentlich größere Kontext und diedamit steigende Komplexität. Um dieserSituation gerecht zu werden, ist einestärkere Spezialisierung der einzelnenRollen sowie die Einführung neuerRollen erforderlich.SOA-RollenDurch die klarere Trennung der Verantwortlichkeitenund den höheren Spezialisierungsgradin einer SOA ändern sichdie Ausprägungen der klassischen Rollen.So wird sich ein Entwickler, der sichin einem Projekt bislang mit Integrationsthemenund Oberflächenprogrammierungbeschäftigt hat, wahrscheinlichals Serviceentwickler eher mit Fachlogikinnerhalb einer Fachdomäne beschäftigen,oder er wird sich auf die Oberflächenfür die Benutzerschritte im Workflowspezialisieren. Für Architekten,Projektleiter und Tester ändert sich vorallem der technische Fokus durch denEinsatz von Business Process Management(BPM) oder Enterprise ServiceBus (ESB).In einer serviceorientierten Architekturrichten sich die Rollen nicht mehran Projekten, sondern an horizontalenSchichten oder fachlichen Domänenaus. Zudem werden wichtige Themenwie beispielsweise Integration, Sicherheitoder Prozesse zentralisiert. Diesführt zu neuen Rollen, die diese zentralisiertenBereiche ausfüllen. Diese neuenRollen sind essenziell, um langfristigeine konsistente Service- und Prozess-www.JAXenter.de javamagazin 8|2008 85

SOA CenterSOA-TransformationAbb. 1:KlassischeProjektrollenlandschaft zu gewährleisten. Wichtigeneue Rollen sind Domänenexperte, Bibliothekar,Integrationsspezialist undProzessdesigner (Abb. 2).Der Domänenexperte verfügt überdetailliertes, semantisches Wissen überdie fachliche Domäne, beispielsweiseKunden oder Produkte. Er bestimmt,welche Fachlichkeit in seiner Domäneabgebildet wird und wie diese von anderengenutzt werden kann. Er stellt sicher,dass die Domäne jederzeit konsistentund klar strukturiert ist, und dass es keineÜberschneidungen mit anderen Domänengibt. Zudem ist er der fachlicheAnsprechpartner für potenzielle Servicenutzer.Diese Rolle ist wichtig, umServicewildwuchs zu vermeiden, wie eroft bei rein anforderungsgetriebenenServiceimplementierungen auftritt. DerDomänenexperte ist gewissermaßen derfachliche Architekt seiner Fachdomäne.Während in einem kleinen Unternehmenein Experte mehrere Domänen betreuenkann, findet in größeren Unternehmeneine stärkere Spezialisierung auf einzelneFachdomänen statt. Dies ist erforderlich,um auch in komplexen SOA-LandschaftenKonsistenz zu gewährleisten. Zuseinen Fähigkeiten gehört vor allem einegenaue Kenntnis der jeweiligen Domäne.Daher kommen für diese Rolle beispielsweisefrühere Analysten oder auch Projektleiterin Frage. Aber auch Anwendermit detailliertem Fachwissen können sichfür diese Rolle qualifizieren.Der Bibliothekar stellt eine Schlüsselrollein Bezug auf die Wiederverwendbarkeitvon Prozessen und Services dar.Wir erinnern uns, dass ein großer Teil derAgilität einer SOA aus der Kopplung allgemeinerServices zu Verbundservicesoder Prozessen erwächst. Wiederverwendungbeschäftigt die IT seit jeher.Erfolge in diesem Bereich sind jedocheher bescheiden. Wie kann es also diesmalgelingen, Teile des Gesamtsystemsmehrfach zu nutzen? Der Schlüssel liegtim Einsatz von Repositories, die Services,Prozesse und andere Artefakte auffindbarmachen. Die Vorstellung, dassdie Entwickler ein solches Werkzeugbenutzen, um Services aufzufinden, istaufgrund der oft komplexen fachlichenAbb. 2:SOA-RollenZusammenhänge jedoch naiv. Bevor einService verwendet werden kann, mussklar sein, ob er die erforderlichen fachlichenund technischen Anforderungentatsächlich erfüllt. Der Bibliothekar istder Ansprechpartner für Serviceentwicklerund Prozessdesigner. Er führtim Auftrag dieser Personen Recherchendurch, um geeignete Servicekandidatenzu ermitteln. Dazu kann er das Repositoryeinsetzen und arbeitet eng mit denDomänenexperten zusammen, um es zupflegen. Zu seinen Fähigkeiten gehörendie Kenntnis des eingesetzten Repositoriessowie ein solider fachlicher Hintergrund.Technische Kenntnisse, beispielsweiseüber WSDL oder UDDI, sindebenfalls erforderlich. Für diese Rollekommen daher Analysten oder Projektleitermit technischer Affinität in Frage.Der Integrationsspezialist stellt sicher,dass die Services universell erreichbarsind. Die Integration eines Servicesin die SOA-Infrastruktur ist nicht mehrprimär Aufgabe des Serviceentwicklers,sondern wird in enger Abstimmung mitdem Integrationsspezialisten realisiert.Dem Integrationsspezialisten kommtdabei eine beratende Rolle zu. Er bindetdie Services mit den jeweils geeignetenProtokollen an und stellt eine hochverfügbareKommunikationsinfrastrukturbereit. Zudem entwickelt er Vorgabenfür Schnittstellenspezifikationen, umeine bestmögliche Integration einzelnerServices zu erreichen. Da die Integrationund Kommunikation von Servicesfür den Betrieb einer SOA grundlegendist, sollte diese Rolle möglichst nicht mitanderen Rollen geteilt werden. Zu seinenFähigkeiten gehören eine genaueKenntnis der eingesetzten Kommunikationsinfrastrukturund Standards wiebeispielsweise Java Business Integration(JBI) [2], Erfahrungen mit den gängigenProtokollen, wie SOAP, FTP, HTTP,SMTP etc. Zudem sollte er über Kenntnisseder gängigen Integrationsmusterverfügen [3]. Als Kandidaten für diesesehr technische Rolle kommen Entwickleroder Architekten in Frage.Der Prozessdesigner ist für die Abbildungder Geschäftsprozesse in die technischeLaufzeitumgebung zuständig. Erdefiniert die Prozesse zusammen mit denFachabteilungen und modelliert diese86 javamagazin 8|2008www.JAXenter.de

SOA-TransformationSOA CenterJetzt NEU:Das deutsche Programm!Abb. 3: Rollenmatrixzunächst in grober Form. Zudem beräter die Fachabteilungen und versetzt sie soin die Lage, eigenständig Prozesse zu definieren.Diese Prozesse werden danachvom Prozessdesigner in eine technischeForm überführt. Der Prozessdesignerstellt somit die Schnittstelle zwischender fachlichen Sicht und der technischenAbbildung dar. Dies ist eine besondereHerausforderung, da sie Kenntnisse inbeiden Bereichen erfordert. Dennochist es sinnvoll, diese Rolle nicht in einefachliche und eine technische aufzuteilen.Dadurch wird sichergestellt, dass dieProzesse tatsächliche technisch abgebildetwerden können, Reibungsverlustewerden so vermieden. Als Kommunikationsmittelwerden primär grafischeModellierungswerkzeuge eingesetzt. EinProzessdesigner sollte über Kenntnissein Business in den Bereichen BusinessProcess Modeling Notation (BPMN),Unified Modeling Language (UML),Business Process Execution Language(BPEL), Web Service Description Language(WSDL) und Extensible Markup Language(XML) verfügen. Damit kommenPersonen sowohl aus dem fachlichen alsauch aus dem technischen Bereich in Frage,sofern Sie über Kenntnisse in beidenBereichen verfügen. Da dies eher seltender Fall ist, ist diese Rolle erfahrungsgemäßschwer zu besetzen. Eine praktikableMöglichkeit ist es, dass zwei Personen mitFach- und Technikwissen für eine Übergangszeitsehr eng zusammenarbeitenund sich somit das Wissen des jeweilsanderen aneignen. Voraussetzung ist eineausgeprägte Lernbereitschaft.Und die Anwender?Von einer SOA-Transformation sindnicht nur die Entwicklungsteams undFachabteilungen, sondern auch die Anwenderbetroffen. Sie kennen die Geschäftsprozesseund Funktionalitäten,die durch die SOA unterstützt werdensollen. Aufgrund fehlender Dokumentationsind sie oft die einzigen, die überdieses Wissen verfügen. Eine SOA-Einführunghat in der Regel deutliche Auswirkungenauf den Arbeitsbereich derAnwender. Manche Rollen fallen unterUmständen weg, da Prozesse automatisiertwerden und sich die Benutzerinteraktionauf ein Minimum beschränkt.Andere Rollen ändern sich durch dieEinführung neuer Werkzeuge. Darausergibt sich ein Spannungsfeld, das nichtzu unterschätzen ist. Die Einbeziehungder Anwender ist daher im Rahmen einerSOA-Transformation essentiell. Abbildung3 zeigt sinnvolle Entwicklungsperspektivenfür Teammitglieder auf.SOA-TeamsDie hier vorgestellten Rollen sollen vorallem ein Bewusstsein für die neuenAufgaben schaffen, die mit Einführungeiner serviceorientierten Architekturwahrgenommen werden müssen. Damitstellt sich die Frage, wie Teamstrukturenauf Basis dieser Rollen gebildet werdenkönnen. Grundsätzlich orientierensich die Teams an den horizontalenSchichten Oberflächen, Prozesse undDomänen [1]. Folglich gibt es ein odermehrere Prozess- und Oberflächenteams,sowie je ein Team pro Fachdomäne.Bei der Rollenverteilung empfiehltsich ein pragmatischer Ansatz. So sindbei kleinen Vorhaben manche Rollennoch optional. Aufgrund der geringenKomplexität kann in der Regel auf denBibliothekar und Integrationsspezialistenzunächst verzichtet werden. BeiShameem Akhter, Jason RobertsMulti-CoreProgrammierungIntel hat ein neues Zeitalter der Prozessorarchitektureingeleitet – Multicore-Computing.Bei der Intel Multicore-Architektursind zwei oder mehrProzessorkerne bzw. Recheneinheitenin einem einzigen Prozessorgehäuseuntergebracht. Mit der entsprechendenSoftware können diese Systeme mehrereSoftware-Threads parallel ausführen.Die autorisierte Übersetzung des Originalbuchsvon Intel Press USA zeigt dieGrundlagen und erläutert Software-Entwicklern,wie sie ihre Programme optimalan die Intel-Prozessoren anpassen.ca. 350 Seiten, Softcover, 54,90 ISBN 978-3-939084-70-9Powered by:Weitere Informationen und Bestellmöglichkeitenfinden Sie unter www.entwickler-press.de.Unsere Bücher erhalten Sie auch in jeder gutsortierten Buchhandlung.www.JAXenter.de javamagazin 8|2008 87I3_002

SOA CenterSOA-Transformationmittleren Vorhaben haben einzelnePersonen in der Regel mehrere Rolleninne. So können zum Beispiel die RollenBibliothekar und Domänenexperte zusammengefasstwerden. So lassen sichalle Rollen auch mit wenigen Personenabbilden. Bei großen Vorhaben findeteine weitere Spezialisierung statt. DieFolge ist eine explizite Rollenbesetzungdurch jeweils eine Person.GovernanceAls SOA-Governance bezeichnet mandie Überwachung der Einhaltungwichtiger Standards mit dem Ziel, langfristigeine stabile und wartbare SOA-Landschaft zu schaffen. Die Produktherstellerbezeichnen ihre Repositoriesoft auch als Governance-Lösungen.Dabei geht es jedoch meist eher umdas Thema Servicemanagement, dasheißt die Verwaltung von Informationenzu bestehenden Services und Prozessen.SOA-Governance ist ein reinorganisatorisches Thema, bei dem dieZusammenarbeit und Ausrichtung derSOA-Teams geregelt wird. Bei den zuüberwachenden Standards kann es sichum offene Standards wie WSDL- oderBPMN-Modellierung oder auch unternehmensspezifischeStandards, wiebeispielsweise zur Servicegranularitätoder Dokumentation handeln. Je größerein SOA-Vorhaben ist, umso wichtigerwird die Einrichtung von GovernanceBoards, in dem Repräsentantender SOA-Teams vertreten sind. Inder Regel finden sich in einem solchenBoard die Rollen mit übergeordnetenVerantwortlichkeiten, wie Architekten,Domänenexperten oder Bibliothekare,wieder. Grundsätzlich wird zwischenzentralistischen, föderativen und hierarchischenModellen unterschieden.Beim zentralistischen Modell gibt esnur ein Board, in dem alle Entscheidungengebündelt werden. Dies erlaubt einesehr gute Kontrolle. Allerdings skaliertes nicht und kommt damit nur zu Beginneiner SOA-Transformation oder fürkleine SOA-Vorhaben in Frage.Das föderative Modell umfasst mehrere,gleichberechtigte Boards, die sichregelmäßig abstimmen und Entscheidungengemeinsam treffen. Das Modellskaliert besser als das zentralistischeModell, hat aber den Nachteil des zunehmendenKontrollverlustes bei steigenderKomplexität des SOA-Vorhabens.Es eignet sich besonders für mittelgroßeVorhaben, in denen es beispielsweisemehrere gleichberechtigte Abteilungengibt.Beim hierarchischen Modell erfolgtdie Entscheidungsfindung gemäß derhierarchischen Struktur. Hierbei gibt esmehrere Boards, bei denen die übergeordnetenBoards Vorgaben für die untergeordnetenentwickeln. Dieses Modellkommt beispielsweise bei internationalenOrganisationen zum Einsatz, wobeies für jede Region (zum Beispiel US undEMEA) ein eigenes Board gibt, das sichmit dem zentralen Board abstimmt. Eseignet sich vor allem für große, regionalverteilte SOA-Vorhaben.ErfolgsfaktorenDie Erfahrung zeigt, dass Verzögerungenoder Fehlschläge häufig darauf zurückzuführensind, dass die betroffenenPersonen nicht ausreichend einbezogenwerden. Dies gilt gleichermaßen für dieEntwicklungsteams als auch die Anwenderder Systeme. Dabei ist es leichtnachvollziehbar. Schließlich geht esbei einer SOA nicht selten darum, bestehendeGeschäftsprozesse ganz oderzumindest teilweise zu automatisieren.Das Prozesswissen ist oft zum großenTeil nur bei den Anwendern bekannt, diedie Prozesse einfach leben. Der Transferdes Prozesswissens in ein IT-Systemsetzt die unbedingte Mitarbeit dieserProzesskenner voraus. Bei den Entwicklungsteamsist es ähnlich. Ein Serverentwickler,der bisher weitgehende HoheitLinks & Literaturüber seinen technischen Bereich hatte,wird diese als Serviceentwickler wahrscheinlichverlieren, wenn er fortan dieVorgaben der Architekten beziehungsweiseder Governance Boards umsetzensoll. Wenn unklar ist, welche Rolle diesePersonen im Rahmen einer serviceorientiertenOrganisation haben, könnensie nur schwer zur Mitarbeit bewegt werden.Da die Einführung einer SOA mitpersonellen Umstellungen verbundenist, empfiehlt es sich, einen Change-Management-Prozess aufzusetzen, wieer beispielsweise bei einer Firmenübernahmezum Einsatz kommt. So wie eineReferenzarchitektur im Rahmen derSOA-Roadmap beschrieben wird, sollteebenfalls ein Referenzorganisationsplanmit den zu besetzenden Rollen erstelltwerden. Anhand dieses Plans könnenfrühzeitig Entwicklungsmöglichkeitenfür die Teammitglieder erläutert und mitden Beteiligten abgesprochen werden.Dies ermöglicht einen hohen Grad derKooperation und trägt somit entscheidendzum Erfolg bei.FazitEine SOA-Transformation beinhaltetweit mehr als den Einsatz bestimmterTechnologien. Dazu gehört vor allemdas richtige Vorgehen im Rahmen einesSOA-Programms, unter Einbeziehungpersoneller Veränderungen. Diesunterscheidet eine SOA grundsätzlichvon anderen Paradigmen in der Softwareentwicklung.Wenn diesen Aspektengenügend Aufmerksamkeit gewidmetwird, kann eine serviceorientierteArchitektur ihre Potenziale für ein Unternehmenentfalten.Wolfgang Pleus arbeitet als Technologieberater, Autor und Trainerim Bereich serviceorientierter Architekturen. Seit über 15 Jahrenunterstützt er internationale Unternehmen bei der Realisierungkomplexer Geschäftslösungen auf der Basis von J2EE und .NET.Er ist Mitglied des Accelsis SOA-Competence-Teams.[1] Wolfgang Pleus: SOA-Transformation, Teil 1, in:Java Magazin 07.2008, S. 95–100[2] Java Business Integration: jcp.org/en/jsr/detail?id=208[3] Enterprise Integration Patterns: www.enterpriseintegrationpatterns.com88 javamagazin 8|2008www.JAXenter.de