Technik
(von altgriechisch τε ́χνη [téchne], Fähigkeit, Kunstfertigkeit, Handwerk)
Alle Autoren, diejenigen dieses Buches fast ausnahmslos eingeschlossen, betonen immer wieder, dass es bei SOA vor allem um Aspekte wie Geschäftsorientierung, Methodik oder Organisation geht und nicht um Technologie. Aber Architektur hin, Methodik her – irgendwann einmal steht die konkrete Umsetzung einer Menge von Services vor der Tür. Spätestens zu diesem Zeitpunkt muss man sich Gedanken machen, auf welche technologische Plattform man setzt – man sollte sich nur davon verabschieden, jemals die »richtige« und »einzige« Technologie zu finden.
Bei der Umsetzung von serviceorientierten Architekturen wird heutzutage oft auf Standards aus dem Webservice-Umfeld gesetzt: SOAP, WSDL und (mit Einschränkungen) UDDI (Letzteres bei weitem nicht so häufig wie die vorhergehenden) sowie die vielfältige Welt der WS*-Spezifikationen. Diese Standards beschäftigen sich jedoch primär mit den Schnittstellen, nicht mit der Implementierung von Services. Die populärsten Plattformen dafür sind aktuell Java und .NET. Für viele der heilige Gral, für andere Teufelswerk ist der Enterprise Service Bus (ESB) als Kern einer SOA-Infrastruktur.
Zu den unterschiedlichen technologischen Aspekten von Schnitstellenstandards, Integrationsinfrastrukturen und Plattformen finden Sie in diesem Teil folgende Beiträge:
Im Kapitel 29 berichtet Udi Dahan über seine persönliche Entdeckung des ESB-Konzeptes und dessen positive Auswirkung auf das Projektklima und die Sicherheit seines Jobs. Auch wenn der Beitrag locker geschrieben ist, steht doch eine wichtige Erkenntnis im Vordergrund: dass es sich beim Austausch von Nachrichten um ein Konzept handelt, das auch auf Applikationsebene sichtbar wird und nicht nur um ein Implementierungsdetail.
Im Umfeld von Webservices tummeln sich mehr als 60 (Pseudo-)Standards und Spezifikationen, die unterschiedliche Aspekte adressieren. Thilo Frotschers Beitrag (Kapitel 30) beschreibt die für die Praxis relevanten, wichtigen und verbreiteten Standards (WS-ReliableMessaging, WS-Addressing, WS-Policy und Web Services Security/WSS). Insbesondere zeigt Frotscher, wie sie aufeinander aufbauen und so eine konsistente Gesamtarchitektur bilden.
Jürgen Dunkel und Arne Koschel beschreiben in Kapitel 31 zunächst, welche Aspekte eine Infrastruktur für SOA abdecken muss und wie eine Referenzarchitektur für einen solchen »Stack« aussehen kann. Danach beleuchten sie, welche Open-Source-Lösungen auf dem Markt existieren und wie diese verwendet werden können, um einen Open-Source-SOA-Stack aufzubauen.
Für Adam Bien ist Java EE, der Nachfolger von J2EE, eine ideale Plattform für SOA, und Java EE-Anwendungen, die den gängigen Entwurfsmustern folgen, entsprechen bereits den SOA-Prinzipien. Bien betrachtet in Kapitel 32 eine Reihe von Herausforderungen wie Kapselung, Performance, kompensierende und globale Transaktionen, Asynchronität und Entkopplung und zeigt, wie diesen in einer JavaEE-Architektur begegnet werden kann.
Michael Stal erklärt in Kapitel 33, was sich hinter den Standards Service Data Objects (SDO) und Service Component Architecture (SCA) verbirgt und wie diese SOA um den Gedanken von kombinierbaren, konfigurierbaren Komponenten ergänzen. Stal wird dabei konkret und zeigt den Implementierungscode und die Konfigurationsdateien – davor sollten Sie sich also nicht fürchten.
Die wichtigste moderne Entwicklungsplattform neben Java ist Microsoft .NET. In Kapitel 34 beschreibt Hartmut Wilms die Prinzipien, die in der Microsoft-Gemeinde als Basis für SOA gelten. Wilms zeigt die Möglichkeiten auf, die Microsoft mit der Windows Communication Foundation (WCF) zur Umsetzung von serviceorientierten Systemen zur Verfügung stellt. Ein weiteres Thema ist die Rolle von WCF in Bezug auf andere Microsoft-Plattform-Standards wie COM oder .NET Remoting. Auch Wilms zeigt Codebeispiele und erklärt en détail, wie die Entwicklung WCF-basierter Services erfolgt.
Auch Klaus Rohe beschreibt eine neue Technologie in der Windows-Plattform: Die Windows Workflow Foundation (WF). In Rohes Beitrag (Kapitel 35) können Sie lesen, wie sich WF sowohl für die Orchestrierung von Services als auch für deren Implementierung verwenden lässt.
Zusammenhang zu anderen Teilen
Die in diesem Teil vorgestellten, konkreten Technologien setzen die Konzepte aus dem Teil VI um – und halten sich dabei mehr oder weniger strikt an die dort getroffenen Festlegungen. Einen alternativen Ansatz, der ohne größere Frameworks und Bibliotheken auskommt, thematisieren Stefan Tilkov , Phillip Ghadir und Jan Algermissen in ihren jeweiligen Beiträgen zu REST (Kapitel 23, 24 und 48).
