Ich würde gerne einmal eine provokante Frage in unsere Community stellen:
Ist Web 2.0 die bessere Service Orientierte Architektur?
Ja ich weiß, diese Frage ist wieder mehr für unsere technikaffinen Mitglieder. Sorry. Der Hintergrund meiner Frage bezieht sich auf die andauernde Diskussion über Service Orientierung in Unternehmen, wo im gleichen Atemzug auch Stichworte wie Business Prozess Management, Enterprise Service Bus etc genannt werden. Dinge die im Web 2.0 nicht wirklich vorkommen. Umgekehrt schafft Web 2.0 Lösungen in einer Komplexität und Variabilität umzusetzen, die jede IT eines Großunternehmen blass aussehen lassen.
Wenn ich damit eine Diskussion anfachen kann, würde ich mich wirklich freuen. Sind die Ansätze zu ESB und BPM wirklich so konkurrenzlos wie viele Hersteller und Analysten uns glauben machen wollen? Was würde passieren wenn wir unser Intranet zu einem Web 2.0 machen? Ich könnte dem etwas abgewinnen, mit einer Kreditkarte der Abteilung mir neue Server im RZ innerhalb von 10 Minuten live zu schalten 
Folgende Punkte sind mir dazu eingefallen was im Web 2.0 alle funktioniert oder auch nicht verwendet wird:
- Orts & Zugriffstransparenz wird im Web 2.0 durch das http-Protokoll und URLs realisiert. Ich weiß nicht wo das Services läuft und ich adressiere alle Services auf dieselbe Art und Weise
- Singel Sign On wird im Web 2.0 immer öfter über OpenID realisiert. Fast alle großen Web 2.0 Community Services sind auch OpenID Provider (Google, WordPress, etc.) = keine direkten technischen Abhängigkeiten, sondern der Browser des Benutzers ist das Bindeglied. Das schafft heute eigentlich kein Großkonzern mit dieser Durchgängigkeit.
- Services bieten offene APIs an um die Kommunikation mit anderen Services zu ermöglichen = hohe Wiederverwendbarkeit. Ein gutes Beispiel ist hier Tweetdeck welches Informationen aus Twitter und Facebook aggregiert und z.B. BitLy verwendet um URLs automatisch zu kürzen.
- Es gibt keine zentrale Middleware, sondern nur ein einheitliches Transportmedium (http) mit genormten Datenaustauschformaten (HTML, XML)
- Ein technisches Service im Web 2.0 verwendet typischer Weise zur Beschreibung seiner Schnittstellen Spezifikationen wie z.B. WSDL, SOAP, RSS, Atom die den Datenaustausch anhand von XML Daten normieren
- Es gibt kein Transaktionskonzept im Web 2.0. Das ist weniger bedeutsam, da sowieso mit den jeweiligen Services direkt ohne Vermittler gesprochen wird und es zu keinen Requestketten kommt wie bei einer Middleware
- Speicher ist Spott billig, endlos verfügbar und dass noch dazu 24×7 mit einer Bandbreite die ihresgleichen sucht (z.B. Amazon S3)
- Es ist volkommen irrelevant, welche Technologie Web 2.0 Services intern benutzen und bieten dadurch Platz für unglaubliche Heterogenität und Plattform Vielfalt
- Es gibt keinen allgemeinen Workflow, sondern nur Workflows innerhalb von Services, z.B. Alfresco oder Projektplanung
- Adapter gibt es keine, da alle mit standardisierten Protokollen über http kommunizieren
- Performance ist kein Problem im Web 2.0. Es gibt kein Unternehmen der Welt, dass höhere interne Datendurchsätze bewältigen können muss als auch nur eines der großen Web 2.0 Services wie z.B. Facebook, Twitter, Google & Co etc.
- Die Verwendung von JavaScript im Browser zur Integration von Dritt-Services ist verbreiteter Standard, z.B. Google Maps, Facebook „I like it“ Button oder einblenden von Twitter feeds in Webseiten à Es wird weniger zwischen Services integriert, als mehr über den Browser des Benutzers
Wenn ich mir herkömmliche Strategien in Unternehmens ansehe, dann erkenne ich hier eine klare Diskrepanz. Gehen wir in Unternehmen den falschen Weg?
1. Als Chief IT Architect plädiere ich für eine stärkere Trennung von ARCHITEKTUR bzw. ARCHITEKTURSTILEN und dem sehr heterogenen Sammelbegriff “Web 2.0″. Der Begriff “Service” ist so allgemein, dass ja in der IT schon fast alles ein “Service” sein kann – oder auch nicht.
Und nicht jede x-beliebige Beschreibung von IT-Systemen ist schon eine Architektur.
2. Auf der technischen Ebene laufen die Bullets im Blog auf einen Vergleich zwischen RESTful “Services” und einer (vollen, echten) “SOA” hinaus.
3. Web 2.0 ist deswegen SICHER KEINE SOA, weil es keine von der Komponente, die das Service implementiert, unabhängige MASCHINENLESBARE DEFINITION eines Services gibt, mit der ich eine andere Software Komponente dazu zwingen kann, das Service auch zu “konsumieren”.
4. Web 2.0 – vor allem über die Browser/JavaScript Integration – ist LEDIGLICH DAS BEKANNTE KOMMPONENTENORIENTIERTE Programmieren. Hatten wir schon in den 1990er Jahren.
5. Das es kein Transaktionskonzept im Web 2.0 gibt ist NICHT RICHTIG. Bestellungen etc. sind durchaus transaktional (sogar rechtlich-juristisch).
6. Die SOA Architektur-Graphik ist – soweit ich mich erinneren – von der OPEN GROUP “ausgeliehen”. Sie ist auch GENAUER als der Blog und unterscheidet – richtigerweise – einen PROCESS LAYER (für Humanprozess) und einen SERVICE LAYER, wo machine-2-machine Kopplung ohne Userinteraktionen statt findet. Ein Bullet im Blog unterstellt, dass es keinen Workflow im Web 2.0 gäbe. Das ist wohl richtig für Web 2.0, aber FALSCH für eine SOA, die einem Unternehmen etwas bringen soll.
7. Die Unternehmen, die auf “klassische” SOA mit ESB und BPMS setzen, gehen KEINEN FALSCHEN Weg, weil sie EXISTIERENDE Applikationen integrieren müssen und nicht, wie die typische Web 2.0 Applikationen, auf der GRÜNEN WIESE etwas Neues hinstellen können. Natürlich würde man heute ein Provisionssystem, ein Kreditantragsmanagement-System oder ein Ticket-System (siehe aber Punkt
von vorneherein service-orientierte programmieren mit den im Blog angesprochenen Schnitttstellen. Aber wer kann sich das heute leisten – auch von der Zeit her?
8. Der ÖBB Personenverkehr macht das im Übrigen heute schon so, dass er seine neue Ticket-Applikation, ticket4all, gleich service-orientiert neu baut.
-cfs