Gernot Starke, Stefan Tilkov (Hrsg), dpunkt, 2007.

Fast 900 Seiten geballtes Wissen, um Ihre Meinungsbildung zum (kontroversen!) Thema "Serviceorientierte Architekturen" zu fördern.
Hierin finden Sie zu allen wesentlichen Themenbereichen fundierte und praxisnahe Beiträge (ok - dieser Satz enthält ein wenig Eigenwerbung).

James McGovern: Praxisfern, schlampig gemacht: Grausig!

Sich selbst loben die Autoren als Industry Thought Leader - tatsächlich mag das sogar stimmen, jedoch nervt spätestens bei der dritten Wiederholung dieser Phrase das Eigenlob doch beträchtlich. Aus meiner Sicht stellen die Autoren ohne wirklichen Zusammenhang aus dem SOA-Kontext willkürlich einige Aspekte vor. Warum beispielsweise die komponentenorientierte Software-Entwicklung (Kapitel 2) oder die Diskussion von Software-Qualitätsmerkmale (Anhanb B) breiten Raum einnehmen und Themen wie Service-Design völlig fehlen, bleibt offen. Und daß Kapitel 3 (Orchestration) den mindestens ebenso wichtigen Begriff der Choreography praktisch ignoriert, statt dessen aber willkürliche Syntaxemelente von BPEL in epischer Tiefe erläutert, finde ich unpassend. Schließlich missfällt, dass die im Untertitel (recommendations) versprochenen Ratschläge im Buch fast völlig fehlen.
Allerdings: Der Teil über SOA-Sicherheit fällt (positiv) aus diesem Rahmen ? eine wohlstrukturierte und inhaltlich brilliante Darstellung des Themas ?Sicherheit? ? allein dafür lohnt das Buch die Anschaffung für die Firmen-Bibliothek.
Obendrein stimmen diverse Querverweise im Buch nicht - finde ich schlampig.

Insgesamt: Finger davon lassen.

Thomas Erl, Prentice Hall, 2004: Höchstens passable Einführung - teils brauchbar, teils (sehr!) verworren!

Ein Wälzer, vollgepackt mit (meist technisch anmutenden) Informationen. Zu praktisch allen Aspekten von SOA, Web-Services und XML beschreibt Thomas Erl die aus seiner Sicht wesentlichen Aspekte. Dennoch bleibt am Ende der Lektüre die Frage: Was hat?s gebracht? Mir fehlen praxistauglichen Ratschläge und die Transparenz seiner (teilweise eigenwilligen) Argumentationen. Viel Platz wird meiner Meinung nach durch großflächige aber nichtssagende Diagramme vergeudet.

Insgesamt aus meiner Sicht zwiespältiges Werk, dass sich zur Vervollständigung einer SOA- oder Web-Service Bibliothek allein aufgrund der Breite der dargestellten Themen aber auf jeden Fall anbietet. Thomas Erl bleibt an vielen Stellen leider plakativ. Für das Top-Management ist das Buch zu dick, für IT'ler zu oberflächlich.

Ich würde das Buch wieder kaufen - aber eine echte Empfehlung ist es auch wieder nicht.. Und die drei Sterne sind in guter Laune vergeben :-)

Viel besser: Krafzig &Co. (Enterprise SOA)..

Dirk Krafzig, Karl Banke & Dirk Slama: [Krafzig+04]
Enterprise SOA: Service-Oriented Architecture Best Practices.
Prentice Hall, 2004.
Eine aus meiner (GSt) Sicht gute Einführung in das Thema - die Autoren schreiben aus praktischer Sicht, ohne jedoch in einzelne Technologien abzudriften. Sehr schön: Das Konzept der klassifizierten Services sowie die systematische Begriffsbildung rund um Services.

Erik Marks: Gruselig schlecht - wenig informativ, kaum lesbar.

Die Autoren erheben den Anspruch, den state-of-the-art in SOA planning darzustellen Dem werden sie in keiner Weise gerecht. Im Text finden sich immer wieder längere Listen von Fragen, zu denen das Buch leider keine Antworten gibt. Die Gliederung insgesamt ist recht logisch, die ersten beiden Kapitel (Introduction, General Model for Services) empfand ich als durchaus lesenswert. Das Buch ist komplett technikfrei, jedoch als Business-Buch auch wenig konkret.

Abzüge in der Wertung gibt es für reihenweise Textwiederholungen: Doppelt geschrieben wird der Text auch nicht besser, sondern ärgert den aufmerksamen Leser. Ebenso fand ich identische Abbildungen, beides vermutlich Resultat eines lieblosen Lektoratsprozesses.

Die Autoren führen im Laufe des Buches eine hübsche, aus meiner Sicht aber völlig nutzlose, Notation für SOA?s ein. Wenn es konkreter wird (an genau einer einzigen Stelle im Buch) müssen sie dann aber doch wieder die bewährte UML zu Rate ziehen ? und setzen diese noch ungeschickt ein. Fazit: Viele Aspekte haben die Autoren angesprochen, keinen davon wirklich abschließend klären können.

Fazit: Finger davon lassen.