| Seite 1: | OOP 2008: Entwicklertipps für den SOA-Einstieg |
| Seite 2: | Repository nicht vorrangig |
| Seite 3: | Defizite der Web-Services |
| Seite 4: | Absage an SOA plus EDA |
| Seite 5: | Zwei Beispiele |
Bezüglich der Zukunft von SOA erteilten die Diskussionsteilnehmer der Gartner-Formel "SOA plus EDA (Event Driven Architecture) gleich SOA 2.0 oder Advanced SOA" eine klare Absage. EDA sei ein altbekanntes, eigenständiges Architekturkonzept, das unabhängig von SOA existiere, so dass man allenfalls ein optimales Zusammenspiel anstreben könne. Doch auch das berge Gefahren: Regelbasierende Systeme erzeugen Ereignisse, bei denen man in lose gekoppelter Umgebung schnell die Kontrolle darüber verliert, was ein Event auslöst und wie das Gesamtsystem darauf reagiert. An solchen Problemen seien seinerzeit schon die Expertensysteme gescheitert. Eine Forderung an die Hersteller, die mit Complex-Event-Processing-Fähigkeiten werben, ist deshalb die Bereitstellung geeigneter Tracking-Mechanismen, die auch in komplexen Servicelandschaften funktionieren. Doch das ist noch Zukunftsmusik. Oracle-Vertreter Clemens Utschig-Utschig gab in der Diskussion zu, dass EDA heute noch weitgehend branchenspezifisch etwa im Bankenumfeld oder in der Flugsicherung hart implementiert wird. Dort allerdings würde sich EDA auch in einer Servicelandschaft gut dazu eignen, um Was-wäre-wenn-Szenarien aufzusetzen.
Wenig halten die Experten auch von der im Zusammenhang mit SOA inzwischen häufiger ins Spiel gebrachten Service Component Architecture (SCA). Hier handelt es sich um ein Assemblierungsmodell für Komponenten, und zwar unabhängig davon, wie die Funktionen innerhalb der einzelnen Bausteine implementiert wurden. Die Kritik an diesem Vorgehen: SCA fungiere quasi als Mediator zwischen unterschiedlich aufgesetzten Services, und das widerspreche dem Standardisierungsgedanken. Standards seien aber das eigentlich Neue an Themen wie SOA oder EDA. Deshalb müssten Anwender den Mut aufbringen, sich trotz der jeweiligen Unzulänglichkeiten auf eine Norm festzulegen, seien es zum Beispiel Web-Services, Rest oder Corba. Erst dann, wenn man sich auf einen Standard geeinigt hat, sollte man mit der Produktauswahl beginnen.
Wer eine SOA-Einführung plant, sollte die Gelegenheit nutzen, gleichzeitig ein Kennzahlensystem aufzusetzen, zumal gerade bei Management-getriebenen Projekten früher oder später die Frage nach dem Erfolg und der Wirtschaftlichkeit der Architektur kommt. Einen Weg dorthin beschrieb auf der OOP Thorsten Janning von der Kegon AG in Wiesbaden. Der für SOA relevante Bereich, aus dem sich die benötigten Zahlen generieren lassen, ist demnach das Anforderungs-Management, der Software-Entwicklungsprozess, die Systemwartung sowie das Release- und Qualitäts-Management. Um objektiv messbare Zahlen zu erhalten, empfiehlt Janning ein Vorgehen nach der von der Nasa Anfang der 80er Jahre entwickelten GQM-Methode (Goal, Question, Metrik). Das heißt, es findet eine Zieldefinition statt, aus der man dann die Fragen ableitet, mit welchen Kennzahlen (Metriken) ein Ziel quantifiziert und qualifiziert werden kann.
