JavaSpektrum August/September 2005 [antikvár]

Am Anfang war das Feuer w Am 7. Februar 1904 schaute die nord-^ amerikanische Stadt Baltimore einem gemächlichen Sonntagnachmittag entgegen. Alles schien seinen gewohnt ruhigen Gang zu gehen bis gegen 10:48 eine Feuermeldung aus dem Hurst Building eintraf. Zunächst blieb der Brandherd auf dieses Haus beschränkt. Nach einer Explosion allerdings griff das Feuer auch auf benachbarte Gebäude über. Zur Unterstützung der städtischen Feuerwehr trafen schon bald weitere Feuer-wehrbrigaden aus Washington D.C. ein. Leider waren deren Hilfsmöglichkeiten beschränkt, ließen sich doch ihre Feuerwehrschläuche nicht mit den vorhandenen lokalen Wasseranschlüssen verbinden. Damals existierten in den USA über 600 verschiedene Varianten für derartige Anschlüsse. Dem verheerenden Feuer fielen schlussendlich 70 Wohnblöcke auf einem Gebiet von etwa 140 Acres zum Opfer, alles in cillem etwa 1526 Gebäude. Nette Hintergrundinformation, sagen Sie sich jetzt vielleicht, aber was hat das allgemein mit Informatik und speziell mit service-orientierten Architekturen zu hm? Betrachten wir dazu die Moral von der Geschieht': Ohne Standard geht es nicht! Wann immer heterogene Systeme - zum Beispiel verschiedene Feuerwehrfahrzeuge und Hydranten - unabhängig von ihren zugrunde liegenden Implementierungsdetails zur Kooperation fähig sein müssen, bedarf es festgelegter Schnittstellenstandards - also zum Beispiel definierter Anschlüsse zwischen Feuerwehrschläuchen und Hydranten. Unterliegt das Zusammenspiel der angeschlossenen Systeme und ihre Zusammensetzving in der Regel starker Dynamik, ist die Nutzung von Schnittstellen mit loser Kopplung essentiell. Für Ingenieure aus anderen Fachgebieten erweist sich diese Fokussierung auf normierte Schnittstellen durchaus als alter Wein in neuen Schläuchen. Denken Sie etwa an den Erweiterungsbus in Ihrem PC, an USB-Schnittstellen oder - für alle Heimwerker unter uns - an die weit verbreitete Killerapplikation „Schraube Dübel". Historisch Interessierte seien auch an die Anfänge der industriellen Elektrifizierung erinnert. Stromnetze dienten zunächst rein zur innerstädtischen Beleuchtung. Um Lampen problemlos anschließen zu können, führten die Unternehmen standardisierte Glühbirnenfassungen ein. Erst im Laufe der Zeit „missbrauchten" weitere Erfinder diese Schnittstellen, um neuartige Geräte wie etwa Waschmaschinen anzuschließen. Die ersten Netzstecker bestanden also aus schlichten Glühbirnenfassungen. ˇ Entsprechend dem Bridge-Muster erfolgt eine strikte Trennung von (standardisierten) nach außen sichtbaren Schnittstellen und der Implementierung. Alle kontraktspezifischen Eigenschaften sowie die Schnittstelle selbst lassen sich mittels einer Schnittstellendefinitionssprache schema-basiert beschreiben. Clients und Funktionalität können dadurch über Schnittstellen kooperieren, ohne sich um Implementierungsdetails des Kommunikationspartners kümmern zu müssen. ˇ Jedwede Kommunikation erfolgt ausschließlich asynchron über (gerouteten) Nachrichtenaustausch. Das schließt die Einführung einer Transparenz- beziehungsweise Abstraktionsschicht mit synchroner, methodenorientierter Kommunikation freilich nicht aus, wie sie das Broker-Muster beschreibt. ˇ In den Nachrichtenpaketen erfolgt der Versand von strukturierten Dokumenten. Die Kodierung kann textuell oder binär erfolgen. Wichtig ist in diesem Zusammenhang, dass sich die Kommunikationspartner über Syntax und Semantik der übertragenen Dokumente einigen. Deren Festlegung kann individuell erfolgen oder auf einem einheitlichen Standard basieren. ˇ Process is King: Die bisherigen Leitsätze lassen sich auch problemlos mit Technologien wie CORBA, FTP, TCP, E-Mail oder Message-orientierter Middleware realisieren. Eines der Alleinstellungsmerkmale service-orientier-ter Architekturen ist die Einführung einer prozessorientierten Schicht oberhalb des bisherigen, eher middleware-zentrischen Ansatzes. Internationale Postuntemehmen wie die Deutsche Post stellen übrigens ebenfalls ein aus dem wirklichen Leben gegriffenes Beispiel für den SOA-Ansatz dar. Zwar sind die Schnittstellen relativ simpel - denken Sie an Postkästen und Briefeinwürfe. Alle Kommunikation erfolgt nachrichtenorientiert und asynchron über Briefe und Pakete unter Zuhilfenahme von Briefträgern, Postfahrzeugen und Sortieranlagen als Transportmedium. Die Struktur der Postsendungen, etwa Angabe von Adressat und Absender, obliegt festgelegten syntaktischen und semantischen Regeln. Prozesse lassen sich ebenfalls realisieren. Etwa in Form von Rundschreiben, Einschreiben mit Rückschein oder fach-domänenspezifischen Prozessen wie der Bestellung im Versandhandel. Denken Sie ruhig einmal genauer über das Post-Beispiel nach. Sie können unschwer weitere Aspekte wie Dienstgüten hinzufügen. Wie Sie leicht erkennen können, stellt SOA durchaus kein lebensfremdes Paradigma für IT-Experten dar, sondern hat sogar im echten Leben praktischen Nutzen. Die Verletzung der SOA-Prinzipien impliziert auch in Nicht-IT-Szenarien negative Auswirkungen, wie das Feuer 1904 in Baltimore beweist. Damit schließt sich also wieder der Kreis. Es gäbe noch einiges zum Thema zu sagen, aber das soll zukünftigen Editoriais vorbehalten bleiben:-; In diesem Sine viel Spaß mit der vorliegenden Ausgabe Ihr Michael Stal