- was ein SOA-Framework bringen soll;
- warum die SOA-Suiten der etablierten Hersteller nicht immer die erste Wahl sind;
- wie man aus Open-Source-Komponenten ein SOA-Framework bauen kann.
Die Antwort auf die Herausorderungen einer hochflexiblen IT schleppen Strategen seit einiger Zeit in ihren Moderatorenkoffern in Form von Powerpoints mit sich herum: Service-orientierte Architekturen (SOA).
Sie bringen Transparenz in die IT-Landschaft, ermöglichen sozusagen eine Inventur, bieten Flexibilität und schützen Investitionen, indem sich bereits vorhandene, stabil laufende Systemteile wiederverwenden lassen. Die Analysten der Aberdeen Group gehen davon aus, dass allein die Top-2000-Unternehmen weltweit in den kommenden fünf Jahren etwa 53 Milliarden Dollar an IT-Ausgaben durch SOA sparen können. Der Grund: Ist eine SOA erst mal implementiert, purzeln die Entwicklungskosten.
Doch bis geerntet werden kann, ist ein gutes Stück Acker zu bestellen - das sagen die Analysten fairerweise auch. SOA braucht neben den elementaren Teilen wie Service-fähigen Anwendungen und einer neuen Denkweise im Unternehmen vor allem ein stabiles IT-Fundament: einen "Baukasten", dessen Elemente aufeinander aufsetzen und einander ergänzen. Sowohl in horizontaler als auch in vertikaler Richtung müssen die Komponenten miteinander interagieren: vom User-Frontend bis zur Datenbank, zwischen einzelnen Applikationen und innerhalb einer Anwendung. Das Denken in Services ist dabei außerordentlich hilfreich. Die Leistungen der Bausteine werden über ihre veröffentlichten Services definiert.
Die Basisinfrastruktur sorgt dafür, dass eine homogene Anwendung aus den Komponenten überhaupt entstehen kann. In einer IT-Landschaft ist Heterogenität jedoch unvermeidlich - man kann also nicht Homogenität fordern, damit SOA funktioniert. Basiskonzepte wie Log/Trace, Konfiguration, Monitoring und Administration sowie Nachrichtenaustausch müssen dazu einheitlich sein. Ferner stellt der Baukasten sicher, dass alle Lösungsbausteine miteinander interagieren können und eine gemeinsame Integrationsinfrastruktur (Messaging, Workflow, Adapter-Framework) verwenden. Zu den Aufgaben im Bereich Basisinfrastruktur gehören also die Bereiche Messaging, Workflow, Persistenz, Log/Trace, Konfiguration, Scheduling, Monitoring und Controlling, Frameworks für die Gestaltung von Benutzeroberflächen, Service Container und Application Server. Eine Benutzerverwaltung sowie Internationalisierung und Reporting-Funktionen sind ebenfalls Bestandteile.
