SOA auf einen Blick

Das Vortragsprogramm hier auf der OOP ist sehr voll. Da finden sich kaum Pausen, in denen ich mal ein paar Notizen zu den Vorträgen ins Blog posten kann. Nachfolgend ein kurzer Bericht über das Montagstutorial SOA auf einen Blick von Michael Herr und Mary Rodrick von der SOP Group der Deutschen Post. Bei den nächsten Postings muss ich mich dringend kürzer fassen...

In ihrem ganztägigen Tutorial haben Michael Herr und Mary Rodrick von Ihren Erfahrungen bei Einführung und Einsatz von SOA bei der Deutschen Post World Net berichtet. SOA wird dort seit mittlerweilen sechs Jahren praktiziert. Entsprechend umfangreich war der Erfahrungsschatz der beiden. Allerdings merkt man auch sehr deutlich, das die Sicht auf die SOA-Welt durch die doch sehr komplexen Anforderungen eines global agierenden Unternehmen mit hunderttausenden von Mitarbeiten und tausenden von IT-Systemen geprägt ist. Einige Ansichten sind auch sehr extrem. Einige der wichtigsten Punkte (natürlich alles andere als vollständig):

• Die Einführung von SOA ist zu großen Teilen eine Frage der Fachlichkeit. Wichtig ist, einige wenige Kernprozesse auszuwählen. Basierend auf diesen Prozessen muss eine Modellierung und Analyse von fachlichen Domänen geschehen. Mit Domäne ist hier ein Funktionsblock (nicht ein Domänenmodell im Sinne eines Datenmodells!) zu verstehen, der Funktionalitäten bereit stellt, die von den Prozessen benutzt werden. Aus
  diesen Domänen können dann Servicekandidaten abgeleitet werden. Diese Kandidaten müssen dann u.a. auf geeignte Granularität, vor allem aber auf hinreichende Stabilität untersucht werden. Letzters kann man z.B. durch die Simulation von
  Prozessänderungen prüfen. Wichtige Konsequenzen sind:




• SOA kann man nicht kaufen.


• Der Entwurf einer SOA muss letztendlich Top-Down geschehen.




• Wichtig ist, dass eine Konsolidierung von Funktionsimplementierungen stattfinden muss. Es kann (logisch) immer nur einen Service Provider für einen Service geben. Redundante Implementierungen müssen abgelöst und durch eine Nutzung des "Highlanders" ersetzt werden. An dieser Stelle kommt Service Portfolio Management ins Spiel, und natürlich auch die Versionierung von Services, wenn sich die Anforderungen an der Service unterschiedlich entwickeln.


• Ein weiterer, ganz zentraler Aspekt von SOA sind Quality-of-Service-Vereinbarungen und Policies, die für eine
  Service-Nutzung gelten sollen. Hierzu gibt es zwar erste Realisierungsansätze hinsichtlich der Syntax (z.B. WS Policy) aber kaum semantische Definitionen. Was bedeutet z.B. eine geforderte maximale Antwortzeit? Wie kann man die fachliche Qualität einer Response messen, die man als Antwort auf einen Service-Request erhält?


• An vielen Stellen reichen die vorliegenden WS Standards noch nicht aus, um damit Real-World-SOA zu betreiben. Als Mediator bietet sich hier ein Enterprise Service Bus an, der z.B. WS-Extentions implementiert und etwa solche Themen wie Aushandeln und Einhalten von Policies sicherstellt. Als Standard scheint sich hier Java Buisness Integration (JBI) zu etablieren.