SOANicolai Jossutis sprach dann über SOA Erfahrungen in einem konkreten Projekt. Zunächst sagte er, dass in diesem Projekt nicht etwa Web Services verwendet werden, was ja sonst oft fast synonym für SOA ist, sondern Tibco. Dadurch komment man zu einem zentralen Bus.
Im weiteren gab er konkrete Erfahrungen aus seinem Projekt. Er versucht zunächst, starke Typisierung bei den Aufrufen der Services durchzuhalten, um beim Compilieren schon passende Fehlermeldungen zu bekommen. Das führt aber auch zu starken Abhängigkeiten, weil man nicht einfach einen Parameter ergänzen kann, da dies dann die Typisierung bricht.
Versionierung und Granularität sind dann weitere Themen. Bei der Granularität gibt es offensichtliche Unterschiede zwischen einer Integration der gesamten Geschäftslogik der Firma und z.B. der Abtrennung einer GUI von der Geschäftslogik.
Generell sieht er das Problem, dass Services schwer änderbar sind, da sie von vielen Client genutzt werden. Dadurch kommt man in einen Konflikt mit den von ihm favorisierten agilen Vorgehensweisen. Da die Services nicht änderbar sind, kommt man automatisch in ein weniger agiles Modell.
Schließlich sieht er auch bei Performance ein Thema: Wenn man statt einem direkten Datenbank-Zugriff eine SOA Infrastruktur bemüht, ist man teilweise eine Größenordnung schlechter.
Ein Fazit: SAO macht es einfach, Dinge kompliziert zu machen. Vor allem werden Abhängigkeiten versteckt und dadurch kann man dann in eine schwer zu managende Situation kommen, weil man nicht weiss, was man ändern kann.
Er zog noch eine interessante Parallele zu OO: Auch die Einführung von SOA war scher und auch OO skaliert nicht - erst durch Komponenten kann man große Systeme bauen. Das ist bei Services möglicherweise ähnlich.
Ingesamt ein interessanter Vortrag, der gezeigt hat, dass SOA ohne Web Services geht und wie man es in der Praxis beispielsweise umsetzen kann und was man für Probleme dabei hat.