Enterprise App. Architecture: Wie seit ihr reingerutscht?
Hallo zusammen!
Bei meiner jetzigen Arbeitsstelle stehen voraussichtlich umfangreiche Neuentwicklungen an. Das bisherige Framework basiert auf VS & / COM+ und kommt langsam aber sicher in die Jahre.
Da wir bisher auf der Microsoft-Schiene gefahren sind, liegt die Einführung von .NET auf der Hand. Nun, ich habe in den letzten Monaten einiges über Domain Driven Developement, Test Driven Developement und Enterprise Appl. Architecture - Patterns gelesen. Je mehr ich darüber lese, desto länger scheint die Liste, was ich überhaupt zuerst lernen muss, bevor ich ein solches Grossprojekt überhaupt erfolgreich anpacken kann. Das hauptproblem: in unserem Team hat kaum jemand Erfahrung mit diesen Themen, ich kann diesbezüglich also von niemandem lernen hier und müsste alles selber erarbeiten.
Deshalb wollte ich euch fragen: wie wurdet ihr zu Enterprise-Profis? Wie seit ihr dazu gekommen? Wie würdet ihr meine Situation einschätzen?
Ich bin mir bewusst, dies könnte eine riesige, super Herausforderung sein. Schliesslich kriegt man nicht alle Tage die Chance, ein solches Projekt von Grund auf aufzuziehen. Auf der anderen Seite möchte ich mir auch nicht umbedingt die Finger verbrennen, oder frustriert aus Überforderung täglich meine 8 Stunden absitzen...
Grüsse
sl3dg3
Hallo sl3d3hamm3r,
vorweg: Die "Profis" kochen auch nur mit Wasser.
Vorgehensmodelle wie Test Driven Development usw. eignen sich nicht generell für alle Projekte. Selbst wenn andere damit augenscheinlich sehr erfolgreich sind, bedeutet das nicht, dass das eigene Projekt dadurch besser läuft. Die Arbeitsweise muss auch zum Team passen! Ein stur 1:1 umgesetztes Pattern aus dem Lehrbuch kann Projekt sogar zum scheitern bringen.
Du sagst, dass Ihr momentan mit COM+ arbeitet. Das ist doch bereits eine Enterprise-Technologie. COM+ ist der Applikationsserver von Windows. Wenn das Team viel Erfahrung mit COM+/DCOM hat, sollte der Schritt auf Technologieen wie z.B. WCF nicht allzu schwer sein. Zumal es da direkte Migrationspfade und Interop-Schnittstellen gibt um eine fließende Migration durchführen zu können. Die neuen Technologieen sind auch nur alter Wein in neuen Schläuchen.
Du hast gefragt, wie andere zu Enterprise-Profis geworden sind. Wenn ich mich jetzt mal als Profi bezeichnen darf, ist das bei mir in etwa so abgelaufen. Ich habe irgendwann mal ein Buch über Windows-DNA (so hieß das Enterprise-Gesamtkonzept von Microsoft vor .NET) gelesen. Da wurde aufgezeigt, wie man mit VB6 COM+-Komponenten schreiben kann und so die Geschäftslogik zentral auf einem Applikationsserver laufen lassen kann. Das hat mich sehr interessiert und mir haben die Ideeen schon damals sehr gefallen. Dann kam 2001 das .NET Framework 1.0 mit den Enterprise Services (.NET Kapselung von COM+) heraus. Also habe ich ein zweites Buch über Enterprise Services und Remoting gelesen und war noch mehr überzeugt, dass man damit bessere Geschäftsanwendungen bauen kann, als nur mit Fat-Client + SQL Server 2000. Also habe ich zu Hause kleine Test-Anwendungen mit Enterprise.Services geschrieben. Das hat gut funktioniert. Beim nächsten produktiven Projekt habe ich die Geschäftslogik und den Datenzugriff dann auch als ServicedComponents (so heißen mit .NET geschriebene COM+-Komponenten) geschreiben. Ist auch gut gelaufen. In der Praxis haben sich die doofen DCOM-Proxies aber als unflexibel und nervig erwiesen. Deshalb habe ich dann mit Remoting (dem kleinen Bruder der Enterprise Services) geliebäugelt. Remoting ist fast genauso schnell wie DCOM aber viel einfacher und leichtgewichtiger. Aber es unterstützte keine verteilten Transaktionen. Zum Glück ist irgendwann das .NET Framework 2.0 herausgekommen und mit ihm der neue Namensraum System.Transactions und die eingebaute Windows-Authentifizierung für Remoting. Also habe ich alle Enterprise Services Projekte auf Remoting mit Windows-Auth. umgestellt. Die verteilten Transaktionen konnte ich nun mit System.Transactions abwicklen. Für diese Migration brauchte ich bereits kein Buch mehr zu lesen. Nun gibt es WCF, was alles unter einen Hut bringen soll. Aber auch zwei Generationen weiter hat sich nicht viel geändert: Man schreibt irgendwelche Komponenten (die man neuerdings Dienste nennt) und lässt sie auf einem Server laufen. Dann baut man sich clientseitig Proxies um entfernte Methodenaufrufe auf diese Komponenten zu machen. Man spricht zwar neuerdings von Nachrichten und nicht mehr von RPC, aber am Ende ist es doch RPC, da am Ende immer eine Methode einer Kompoenente auf dem Server aufgerufen wird, um die Nachricht zu verarbeiten.
Enterprise-Architektur ist gar nicht so schwer. Plane einfach vom groben langsam zum feinen hin. Beginne nicht bei den Klassen (das wäre eine viel zu fein-granulare Ebene, um anzufangen), Dein Projekt aufzubauen, sondern überlege zuerst, wie viele Prozesse (im Sinne von EXE-Dateien) du brauchst und auf wie vielen Maschinen diese laufen sollen. Dann formst Du Komponenten und überlegst, welche Komponenten was machen und in welchen Prozessen Du sie aufhängst. Dann erst kommen die konkreten Schnittstellen und Klassen. Wenn Du beim Design immer im Hinterkopf behältst, dass ein entfernter Methodenaufruf 1000x langsamer ist als ein lokaler Methodenaufruf und Du deshalb sehr sparsam damit sein musst, dann kannst Du eigentlich nicht viel falsch machen. Trotzdem könnten ein zwei gute Bücher nicht schaden. Du solltest bei der Auswahl der Bücher allerdings darauf achten, dass es keine Hype-Blubb-Blubb Bücher voller Hello World-Beispiele sein, die zwar leicht zu verstehen, aber nicht praxisrelevant sind.
Ich habe z.B. folgende Bücher gelesen (sind allerdings schon etwas älter) und muss sagen, dass mich diese Bücher weitergebracht haben:
http://www.amazon.de/Skalierbare-Anwendungen-Microsoft-Windows-programmieren/dp/3860636251/ref=sr_1_1?ie=UTF8&s=books&qid=1249256764&sr=1-1
http://www.amazon.de/NET-Enterprise-Services-Clemens-Vasters/dp/3446221530
Ich habe kürzlich auch folgendes Buch gelesen und musste dieses der Hello World-Kategorie zuordnen (Also aus meiner Sicht leider nicht empfehlenswert):
http://www.amazon.de/WCF-Communication-Foundation-Anwendungsentwicklung-Kommunikationsplattform/dp/3827325943/ref=sr_1_2?ie=UTF8&s=books&qid=1249256901&sr=1-2
Bei der momentanen Technologie-Schwämme (WF 3.5 ist z.B. schon wieder tot, obwohl es noch gar nicht aus den Kinderschuhen raus war; Mit Linq2Sql sieht es fast genauso aus) ist es auch schwer gute praxisrelevante Bücher zu schreiben. Bevor jemand mit einer Technologie Erfahrung sammeln kann, ist sie schon wieder abgeschrieben.
Einfach nicht von den Buzz-Words und der Fülle an Methoden, Pattern und Vorgehensmodellen verwirren lassen. Von allen Erfolgs-Versprechungen mindestens 60% abziehen und über große Entscheidungen eine Nacht schlafen. Das hat bei mir bisher immer gut funktioniert.
Hallo Rainbird
Vielen Dank für Deine ehrliche Antwort.
Das stimmt, mit COM+ haben wir natürlich bereits mit einer Enterprise-Technologie zu tun. Und es gibt schon etliches Know-How über Multi-Tier Architekturen, das auch bestimmt mit neuen Technologien hilfreich sein wird. Daran wird sich wohl nicht viel ändern.
Allerdings setzen die meisten Programmierer hier auf ein bestehendes (eben COM+) Framework auf, und sind somit als Anwender dieses Frameworks eher auf Umsetzung von Geschäftsvorfällen beschäftigt. Das heisst, das fachliche Wissen ist bei Ihnen sehr gross, der Fokus liegt dann aber weniger auf IT.
Für die Anwendung des bestehenden Frameworks ist das absolut ok. Wenn es dann aber zur Gestaltung eines neuen Frameworks mit neueren Technologien kommt, fürchte ich eben dass das allgemeine Know-How der moderneren Hochsprachen halt einfach ein bisschen fehlt, wie OOP. Klar, man hat schnell ein Buch darüber gelesen, aber ob das reicht? ... aber viele andere kämpfen da wohl mit ähnlichen Problemen.
Richtig, vor lauter Patterns sollte man den Wald vor lauter Bäumen nicht aus den Augen verlieren. Die Gefahr liegt in einer Überanwendung, das sehe ich auch so. Dennoch, gerade der Modell-getriebene Ansatz hat mich bis jetzt ziemlich überzeugt, vor allem wenn es darum geht, komplexe Geschäftsvorfälle sauber zu kapseln. Ich glaube, da lohnt sich dann der ganze Overhead von einem ORM. Nur fehlt mir halt gerade hier jegliche Erfahrung, und man steht dann ein bisschen wie ein Ochse vor dem Berg.
In Sachen Literatur orientiere ich mich eher an den "Klassikern", ich versuche auch möglichst alles was gerade hip ist zu vermeiden. Die Gefahr, dass morgen wieder alles anders ist, ist einfach zu gross.
Inspiriert hat mich zum Beispiel Martin Fowler:
PoEAA
Desweiteren möchte ich gerne noch dieses Buch (Eric Evans) verschlingen bei Gelegenheit:
Domain Driven Design
Soweit ich das nun ein bisschen verfolgt und darüber gelesen habe, kann die Stärke von OOP gerade beim Domain Driven Design in Verbindung mit irgeindeinem ORM ausgespielt werden... Aber vielleicht gibt es auch gute Gründe (die ich noch nicht kenne), diese Methodik eben nicht einzusetzen.
Grüsse
sl3dg3
Hallo sl3dg3hamm3r,
OR-Mapping funktioniert nach meinen Erfahrungen schlecht bis gar nicht in Verbindung mit verteilten Anwendungen. Zu diesem Thema ist vielleicht folgender Blog-Eintrag interessant: http://yellow-rainbird.de/blogs/rainbird/archive/2009/01/09/habe-sehnsucht-nach-dem-rowstate.aspx
OOP kann sogar schädlich für ein großes verteiltes Projekt sein!
Hallo Rainbird
Dein Blog-Eintrag klingt in der Tat eher negativ was dies anbelangt. Nun, ich kann aus mangelnder Erfahrung weder dafür noch dagegen argumentieren. Allerdings hat gerade Fowler in diese Richtung keine negativen Äusserungen gemacht, was OOP und Enterprise anbelangt - aber eben, es gibt wohl viele Geschmacksrichtungen... und ich steh immer noch wie ein Ochse vor dem Berg 😉
Grüsse
sl3dg3
Hallo sl3dg3hamm3r,
vielleicht hilft Dir ein konkretes Beispiel weiter: .NET Applikationsserver
Das wäre eine Möglichkeit, wie man mit .NET verteilte Geschäftsanwendungen schreiben kann. Das Modell ist praxiserprobt. Vielleicht findest Du da ein Stückchen Inspiration.
Hallo sl3dg3hamm3r,
gerade zu dem Thema mit dem fehlenden RowState von OR-Mappern, sind diese beiden Blogeinträge von Ralf Westphal auch sehr interessant:
http://object-relational-mapping.blogspot.com/2007/03/how-automatic-persistence-magic-is_25.html
http://ralfw.blogspot.com/2009/07/blinder-fleck-change-tracking.html
Gruß
Christoph
EDIT: Sorry, der erste Link war nicht der, den ich verlinken wollte. Habs korrigiert.
Danke Euch für die Links! ... auf den .NET Applikationsserver bin ich bereits über Deinen Blog gestossen, Rainbird 😉 werde mir dies gerne anschauen, ich hoffe ich werde das Konzept dahinter verstehen.
Naja, vielleicht befinde ich mich allgemein ein bisschen auf dem Irrweg in der Meinung, dass vor 10 - 15 Jahren alles viel schwieriger zu entwickeln war, und heute mit den mächtigen Frameworks wie .NET oder J2EE alles viieeel "eleganter" und "aufgeräumter" daher kommen sollte.
Aber das Gebiet war, ist und bleibt wohl eine tägliche Herausforderung, vor allem bei Neuentwicklungen. 🙂 Das schwierigste sind wohl grundsätzliche Entscheidungen, welche Methodik nun am ehesten zum Erfolg führen wird. Dies ist ganz besonders dann schwierig, wenn man damit noch nie damit gearbeitet hat. Man kann zwar viel darüber lesen, aber die Entscheidung nimmt es einem nicht ab.
Grüsse
sl3dg3