Hartmut's Box

Ok Hartmut, aber nur in deutsch….

Mag ja sein, dass eine Definition von SO(A) hilfreich ist, aber doch nur als ‘Kommunikationshilfe’. Damit meine ich, dass jeder wei�, wovon man spricht. Und ja, SO(A) ist kein Produkt. SO(A) ist wie alles andere nur eines von vielen Werkzeugen/Gestaltungsm�glichkeiten die uns zur Verf�gung stehen (sollten) um dem eigentlichen Ziel der EDV, der effektiven Abwicklung des Business, ein St�ck n�her zu kommen. Ich bef�rchte, dass jetzt wieder all diese Orden-J�ger unterwegs sind, die denken, ihre Ziele erreicht zu haben, wenn sie auf ihre Architektur SO(A) schreiben k�nnen. Jetzt werden wieder komplette Architekturen auf SOA umgestellt, da werden Konzepte gemacht… Mag sein, dass es eine Reihe von F�llen gibt, in denen �an enterprise architecture that follows SO principles� Sinn macht. Von mir aus sogar sehr viele. Aber nochmal, nicht das ist das Ziel. SO(A) ist eine Option, die nur den Unternehmen nutzen bringen wird, die sie mit Augenmass im Rahmen eines Gesamtkonzeptes einsetzt.

Hi Ronald!

Ich stimme Dir zu. Die Geschichte mit gibt es eigentlich eine SOA oder einfach nur service-oriented Irgendwas geht mir offen gestanden ziemlich auf die Nerven. Ich wollte (vielleicht zu) subtil folgendes sagen: a) SOA ist eine SA, die auf SO Prinzipien beruht, b) SOA kann man nicht kaufen (ESB und andere omin�se Verwandlungen von Middleware Produkten), sondern lediglich machen. Auch Deine Argumente bzgl. SOA Abzeichen sind vollkommen richtig. Eigentlich will ich mit (meinem Verst�ndnis von) SO(A) nur das erreichen, was man schon immer mit guten Architekturen erreichen wollte. Diesmal sehe ich die Chancen gr��er, aufgrund von Standards und vor allem Akzeptanz auf breiter Front! Message-basierte Services erm�glichen es, lose gekoppelte Systeme zu realisieren, in denen �nderungen einzelner Teile wirklich unabh�ngig von anderen m�glich werden. Gerade zu diesem Thema wird es in n�chster Zeit einen (deutschsprachigen) Artikel geben. Etwas Geduld bitte :-). Obwohl SOA auf erste Sicht in Richtung B2B und “gro�e” Systeme ausgerichtet zu sein scheint, macht sie auch in anderen F�llen Sinn. Wie immer kommt es auf den konkreten Fall an …

Hi,

wenn uns schon die Kinder einen Strich durch die Rechnung mache, dann k�nnen wir ja mal hier versuchen, uns auszutauschen. Leider bin ich nicht ganz so optimistisch wie du. Das was man kaufen kann ist ein mehr oder weniger standardisiertes Protokoll um (recht umst�ndlich) Daten auszutauschen. Also muss man SOA machen (oder an den richtigen Stellen in seine Gesamtarchitektur integrieren (das ist noch mal ne Diskussion f�r sich). Was ich nicht bekomme ist eine semantische Beschreibung der Schnittstelle. Und da ist auch keine Hilfe beim Umgang mit verschiedenen Versionen der Schnittstelle. Und wie ist es mit der Hochver�gbarkeit, die ausgew�hlte Punkte in meinem Service-Netz wahrscheinlich brauchen werden. Ach ja, und wer macht den (tragf�higen) Entwurf der Schnittstelle eines Services. Und dann ist da noch so was wie ein �bergreifendes DependencyManagement (wann kann man alte Versionen der Schnittstelle wegwerfen, wie und an wen werden �nderungen mitgeteilt…). Und wer entscheidet eigentlich welche Erweiterungen an den verschiedenen Services vorgenommen werden. Und, und, und,… Und alle diese Dinge m�ssen auf die real existierenden Infrastrukturen (damit meine ich nicht die Technik sondern die Aufstellung der Abteilungen/Kostenstellen) abgebildet werden. Geh doch mal in Gedanken Deine bisherigen Kunden durch. Wer davon ist in der Lage die Aufgabe zu begreifen. Und wer kann sie dann auch noch durchziehen. Und nicht vergessen, das Ganze ist kein Selbstzweck. Der Support des Business muss weiter gehen (sogar besser werden denn: Stillstand ist R�ckschritt :-).

Und am Schluss noch eine Frage: Gibt es eigentlich schon brauchbare Entw�rfe/Patterns, wie man eine Schnittstelle eines Services entwirft und beschreibt. Ich habe da so ein paar krude Ideen aber vielleicht gibts ja was zu lesen….

Also, …, SOA ist f�r mich eine Klasse von Architekturen, die sich service-orientierten Prinzipien unterwirft. Wenn ich solche Prinzipien anwende, dann muss ich das m. E. schon ganzheitlich tun. Demnach kann eine SOA nicht Teil einer Gesamtarchitektur sein. Das ist nat�rlich die Idealsicht. Praktisch l�sst sich sowas nicht von heute auf morgen umsetzen. Man m�sste das schon Schritt f�r Schritt tun (Migration) aber immer die SOA als �bergeordnetes Ziel im Sinn behalten und nicht als Teil eines Ganzen. Das was man kaufen kann ist leider genau das, was SO(A) und die ganzen “standardisierten” WS-Specs nicht wollen. N�mlich eine Middleware L�sung mit propriet�rem Bus -> ESB (Enterprise Service Bus). Die benutzen das Hype Akronym ESB als Synonym f�r das (Hype) Akronym SOA. Wenn ich lose gekoppelt, Plattform- und Hersteller-unabh�ngig sein m�chte, dann passt propriet�r irgendwie gar nicht ins Konzept. Nun zu den Schnittstellen und den Service-Versionen. Viele Leute meinen, dass eine Registry (z.B. UDDI) zwingend ein Teil einer SOA sein muss. Ich bin mir da nicht so sicher, sprich, es ginge ggf. auch ohne. Aber genau so eine Registry in Verbindung mit einem “Service-Locator” erlaubt es, Services, die Deinen Bedingungen (Funktionalit�t, Poliy, Contract …) gerecht werden, zu finden bzw. darauf zuzugreifen. Wenn man dann noch einen netten Service Browser hat, der einen vern�nftigen Zugriff auf die Registry (am besten aus der IDE heraus) erlaubt, ist man schon weiter. Durch den Service Broker/Locator bekommt man auch Hochverf�gbarkeit. Services k�nnen offline gehen und durch Alternativen (tempor�r) ersetzt werden. Zur Versionierung hier nur eine erste grobe Idee. Ich w�rde einen �hnlichen Weg wie bei COM+ gehen. Services werden in den einzelnen Versionen parallel angeboten. Der Sender gibt dann an (z.B. via URL/URI), welche Version er denn gerne h�tte. Falls die Services message-basiert implementiert sind, k�nnen sie auch mit Dokumenten umgehen, die nicht mehr dem aktuellen Stand der Dinge entsprechen. Das ist z.B. bei minor changes, die nicht zu einem Versionswechsel (in der URI) f�hren, sinnvoll. Bei XML (De)Serialisierung der Dokumente funktioniert das nicht mehr. Dann ist die Struktur der Dokumente in der Implementation fixiert, was einer losen Kopplung nicht gerade entgegen kommt. Die organisatorischen Punkte waren schon immer gewaltige Aufgaben f�r Software-Architekten. Eine gute Antwort kann ich Dir zur Zeit nicht geben. Wird aber noch folgen. Die Beschreibung von Service(Schnittstellen) bzw. deren Entwurf (im besonderen die Granularit�t von Service-Operationen) sind ein ganz heisses Thema. Nein, ich kann Dir zur Zeit nichts brauchbares nennen. Das ist noch eine grosse Aufgabe f�r die n�chste Zeit, an der sich die Gem�ter zerreiben werden … :-) Wenn die Kinder wieder mitspielen sollten wir uns etwas Zeit nehmen, um dar�ber zu diskutieren!

Ok, ich hab was Zeit zum Nachdenken gebraucht. Also als erstes mal eine Frage. Wenn die Zukunft SOA oder A basierend auf SOP ist, was haben wir eigenlich jetz f�r eine Architektur. Wenn SOA eine Klasse von Architekturen ist, f�r welche Klasse von Problemen bzw. f�r welche Klasse von Anforderungen ist sie die ‘korrekte’ Architektur? Wenn ich lose gekoppelte Services habe, dann interessiert mich als Benutzer dieses Services vor allem die Semantik der Schnittstelle. Das meint, was tut dieser Service f�r mich. Das ist nicht aus der vorliegenden Definition (WSDL oder UDDI) ablesbar. Ich kann leider auch weit und breit noch keine Ansatz erkenne, der hier eine Richtung aufzeigt. So etwas w�rde aber auch f�r Deinen FailOver Vorschlag gebraucht. Wie soll denn der FailOver Manager erkennen, das der Service getVersion() der von allen meinen WebServices angeboten wird, NICHT durch einen anderen ersetzt werden kann. Und den ganzen Broker/Locator Rest hatten wir mit dem Versuch CORBA ja auch schon mal…. F�r mich sieht es immer noch so aus, das die Bereitstellung eines Services (Entwurf, Implementierung, und vor allen Dingen die Infrastruktur) einen nicht unerheblichen Aufwand darstellt. Mag sein, das wir in der Zukunft intelligente Tools haben, intelligenntes Servicepersonal etc. aber ich denke der Auwand liegt in einer Gr�ssenordnung der eine wohl�berlegte Entscheidung erfordert. Und das Ganze schreibt Dir einer, der seit ca. 1,5 Jahren WS baut und betreibt, die Architektur (mit)bestimmt etc.. Ob die pessimistische Grundhaltung nun aus der Erfahrung damit kommt oder etwas mit meinem fortschreitendem Alter zu tun hat….