Kategorien
SOA als Hilfe bei alten Projekten
Ich habe gestern mit einem Kollegen ein wenig über SOA (Serviceorientierte Architektur) philosophiert. War ein interessantes Gespräch und hat mich auch auf eine Frage gebracht, auf die ich bis jetzt noch keine Antwort habe. Deswegen versuche ich meinen Ansatz einfach zu beschreiben und hoffe, damit eine Diskussionsgrundlage zu schaffen.
Verwende ich SOA, lagere ich Funktionalitäten in unabhängige Services aus. Das ist so der Kernpunkt um den es mir gerade geht. Nehmen wir also an, wir haben ein altes – wirklich altes – Projekt und wollen neue Teile implementieren. Jetzt möchte man aber nicht die veraltete Architektur umbauen, da es zu viel Arbeit werden würde. Ein gerne gebrachtes Argument ist auch, dass man wenn alles umbauen muss und nicht nur die derzeit betroffenen Bestandteile, da man sonst einen Misch-Masch aus altem und neuen Code baut und dort niemand jemals durchblicken wird. Zwei verschiedene Ansätze etwas zu lösen sollte es nicht geben. Kann ich gut verstehen die Argumentation, auch wenn ich ein wenig anders denke. Chefs aber anscheinend nicht immer.
Wie wäre es also, wenn ich die neuen Features in einen Service packe. Dieser ist komplett unabhängig von meinem alten Code und könnte aus diesem Grund eine neue moderne und saubere Architektur aufweisen, ohne dass ich irgendwas zu refaktorn haben müsste. Wichtig ist dabei, dass die beiden Systeme klar getrennt sind, denn nur so kann ich argumentieren, dass nicht zwei verschiedene Technologiewelten in einem Projekt aufeinander prallen. Dabei geht es natürlich nur um Businesslogik. Dass gerenderte HTML Seiten zurückkommen wäre eine bescheidene Idee.Natürlich hat man auch alle anderen Vor- und Nachteile von SOA (die ich bald mal erklären werde).
Irgendwie finde ich die Idee ganz spannend. Ich habe es aber mit noch keinem diskutiert, weiß also nicht, ob ich an irgendeiner Stelle nicht etwas kritisches übersehen habe. Deswegen seid ihr jetzt gefragt. Was haltet ihr von dem Ansatz? Kann es so klappen oder sollte man lieber das alte System aufbohren?
Wichtig ist bei aller Überlegung: SOA ist ein Paradigma, keine Technologie!
Kern der Überlegung muss also sein abgeschlossene! Funktionalität zu kapseln und auszulagern.
Dann prallen im Projekt auch keine Technologiewelten aufeinander, da die neue Architektur alte Funktionalität über inhärente Technologie nutzt und mit der Alten somit nicht mehr in Berührung kommt.
Gerade sehr alte Websites kann man damit schneller mit neuen Features anreichern und vielleicht auch langsam einen Umstieg einläuten. Ist immer noch besser, als die Holzhammermethode, für die weder Zeit noch Geld vorhanden ist. Von daher *thumbsUp* von mir.
Also ich stand vor dem gleichen Problem.. Die Anforderungen an die Erweiterungen eines Systems hatten sich so stark von der Grundarchitektur entfernt, dass das Aufbohren des alten Codes eine Unmenge Arbeit gewesen wäre. Komplett neu wäre jedoch auch nicht besser gewesen. Daher enschied ich mich, die neuen Teile auszulagern und entsprechend auch eine neue Architektur aufzubauen.
Alle alten Module funktionieren weiterhin und die neuen lassen sich sehr einfach implementieren. Ich bin mit der Lösung sehr zufrieden!
Je nachdem, wie die Services umgesetzt werden (SOA läuft ja in der Regel über HTTP), sollte man bedenken, dass HTTP einen gewissen Overhead hat, zumal vielleicht nicht alle Server in einem Unternehmen mit GBit-Netzwerk angebunden sind bzw. im selben Rechenzentrum stehen. Selbst habe ich nur Erfahrung mit der Ebay-API, die die Ladezeit zum Teil um fast eine Sekunde erhöht. Mag aber auch sein, dass das auch an Ebay bzw. den Anfragen daran liegt, also doch Prozessorzeit der Bottleneck ist. Man könnte das mit Parallelisierung abfangen, aber damit müsste man den maroden Code auch wieder umbauen, wodurch man wenig gewonnen hätte.
Ok, du wolltest Problemfälle haben.
1. Die Datenbank.
Dein neuer Service benutzt Doctrine und liefert die geforderten Features aus.
Jetzt wird die DB angepasst -> du hast 2 Anwendungen zu pflegen und deployen.
2. die KnowHow Brücke
Das betreuende Team muss zu deinen 2 „Projekten“ passen.
Ich halte den Ansatz aber für unbedingt überlegenswert und habe auch einen aktuellen Fall in meinen Projekten. Freue mich auf die weiteren Tipps.
Ich habe einen ähnlichen Fall gerade in meiner Abschlussarbeit. Ich stand vor dem Problem das ich 2 Systeme mit Fehlzeitdaten unserer Mitarbeiter füllen musste, diese aber unterschiedliche Import-Files benötigen. Meine einfache Lösung war, 2 Webservices zu programmieren die diese Daten entgegen nehmen und zu den individuellen Import-Files zusammenbasteln. Jetzt füllt jeder Mitarbeiter einfach eine Art Webformular aus um seinen Urlaub oder seine Krankheit zu melden und schon werden die Files angelegt und in die Systeme importiert. Ging schnell und einfach und jeder ist zufrieden 😉
Eine wirklich schöne Sachen um schnell Daten hin und her zu schießen.
Grüße
Sven
@jensk: Die Frage ob es besser ist viele in der Komplexität geringe Applikationen zu warten oder wenige in der Komplexität hohe ist aber eigentlich beantwortet: vermeide Komplexität!
Grundsätzlich ist es ja bei SOA das Ziel Funktionalität in unabhängige Teilfunktionalität zu zerlegen. Und natürlich muss ich dann ggf. 20 Services warten statt einer Applikation.
@nick3331: wir reden hier ja über die Kapselung von Software, um sie möglichst autark verwenden zu können. Es ist also eine Designentscheidung und keine Technologieentscheidung.
Ich glaube nicht, dass der HTTP Overhead irgendwas entscheidet. Aber zweifelsfrei ist auch heute Assembler immer noch am schnellsten…
Wie Martin @1 schon sagte, SOA ist ein (fast immer nicht genau verstandenes oder erklärbares) Paradigma. Daher würde ich zuerst mal nach einfacheren Lösungsmöglichkeiten suchen.
Wenn es dir nur darum geht, salopp gesagt, alten Code mit neuem zu vermischen oder alten schrittweise in neuen umzubauen, gibt es auch pragmatischere Ansätze anstelle einer neue Ebene der Komplexität.
Spontan fällt mir der Ansatz des vor allem aus DDD bekannten Anticorruption Layers ein. Ist aber nicht darauf fixiert, im Prinzip ist es reine OO, paradigmenfrei.
(Lesebeispiel:
http://ibuilthiscage.com/2008/09/21/anatomy-of-an-anti-corruption-layer-part-1/)
Auf jeden Fall ein ideales Instrument um verschiedene Systeme zu verbinden, „fremde“ Services zu nutzen oder eben um das schrittweises Refactoring größerer Systeme zu bewerkstelligen. Und alles bleibt weiterhin „im Haus“, sprich deinem eigentlichen Domain Model.
Steht dieser Layer mal, ist er ein ganz natürlicher Teil deiner Applikation und kein Fremdkörper (wie SOA…).
Du kannst den alten Teil dann später durch dein Refactoring oder eine andere Legacy-Applikation ersetzen.
OK, wenn man mal Probleme mit einzelnen Technologien außen vor lässt (wofür die Diskussion wohl auch eigentlich gedacht war – sorry wg. Off-Topic), finde ich SOA im Prinzip schon eine gute Sache. Man ist gezwungen Interfaces zur Verfügung zu stellen, kommt gar nicht in die Verlegenheit den schlechten Code durch global-Aufrufe genauso schlecht fortzuführen, denn er ist ja selbst nicht besser. Außerdem vermeidet man projektübergreifend Redundanz. Man muss nicht immer alle Bibliotheken mit einfügen, sondern kann diese Aufgaben Services überlassen, die diese vermutlich sowieso im Cache haben, weil sie nichts anderes machen.
Natürlich darf man es nicht übertreiben. Man kann nicht alle Klassen durch Services substituieren nur „weil da ja mal was kommen könnte, wo man es nochmal brauchen könnte“ – Stichwort: Premature Optimization – man erinnert sich ;).
Sowas nutzt man wo es Sinn macht. Nur weil man „Angst hat“, etwas an den alten Code anzuflantschen und SOA gerade hipp ist, macht es noch lange keinen Sinn, redundanten Code zu erschaffen. Du wirst es nämlich kaum hinbekommen, eine saubere SOA Architektur neben die bestehende Applikation zu setzen ohne dabei doppelte Configs, doppelte Datenbanklayer und und und zu erzeugen.
Es gibt sicher Anwendungsfälle wo es Sinn macht, aber zum Beispiel die erwähnte Situation von Sven klingt nicht nach einem logischen Anwendungsfall von SOA. Eine global verfügbare API braucht man nun mal oft nicht, vorallem nicht wenn man nur eine Internet/Intranet Anwendung baut. Dan kann man immer noch einen Layer drüberziehen, wenn er irgendwann mal benötigt wird.
Aber doch nicht nur, weil man „Architektur verliebt“ ist und gerne die perfekte Lösung zaubert.
Diese Methode habe ich auch vor kurzem eingesetzt. Aus meiner Sicht eine gute Taktik um das veraltete System zu erweitern, ohne viel von dem bisherigen Code berühren bzw. mit der alten C-Qualität weiter arbeiten zu müssen – jedenfalls wenn es die Anforderung zulässt.
Es ist bei mir jedoch so gewesen, dass ich geringe Anpassungen im alten Code vornehmen musste und auf Dauer gesehen, vermute ich, dass es komplizierter wird das ganze Projekt zu verwalten – da es nun in unterschiedlichen Ansätzen realisiert ist. Es ist sicherlich auch entscheidend, in wie weit die neue Funktionalität vom bisherigen System abhängig ist und welche Lebenserwartung für die Funktionalität besteht.
Mit ein bisschen Glück kann man jedoch über diesen Weg langsam das alte System in eine neue Qualität überführen, hoffe ich derzeit jedenfalls noch ;o)