WCF Literaturhinweise

Der ganze Indigo-Hype ist an mir früher genauso vorbeigegangen wie es heute der Orcas-Hype tut. Ich habe einfach keine Zeit, mich mit Technologien zu beschäftigen, die so wenig real sind und noch so unbestimmt weit in der Zukunft liegen. Vielen von Ihnen wird es nicht anders gehen.

Jetzt aber ist Indigo real und heißt Windows Communication Foundation (WCF) und ist echt cool geworden. Und jetzt lohnt es sich auch, sich damit näher auseinanderzusetzen. Auch ich habe mich deshalb auf den Weg durch das WCF-Labyrinth gemacht. Wie bei Jules Vernes "Reise zum Mittelpunkt der Erde" stellt sich dabei allerdings die Frage: Wo einsteigen in die unterirdischen Gänge? Was ist der Snaeffellsjökull für die Reise durch WCF? Welche Gänge sind anschließend zielführend? Was gibt es überhaupt zu entdecken? WCF ist ja so groß, so groß.

Nachfolgend finden Sie quasi meine Expeditionsaufzeichnungen, d.h. die Literaturstationen, die ich auf meiner Reise durch WCF als hilfreich empfunden habe. Vielleicht helfen sie Ihnen ja auch beim Einstieg in das Thema. Google macht am Ende zwar recht glücklich bei der Wegfindung - aber braucht viel Zeit. Ich würde mich also freuen, wenn Ihnen diese Quellenliste Zeit sparte.

Aber Achtung: Meine kleine Landkarte für WCF erhebt keinen Anspruch auf Vollständigkeit. Sie ist subjektiv, d.h. geprägt von meinen persönlichen Interessensgebieten in Bezug auf WCF. So bekümmere ich mich z.B. nicht um Aspekte der plattformübergreifenden Kommunikation. Aber auch zu meinen Interessengebieten sind natürlich nicht alle Quellen zu finden, weil es erstens eine unüberschaubare Vielzahl gibt und zweitens nicht alle lesenswert sind.

Wenn Sie nun mit diesen Einschränkungen leben können oder - positiver ausgedrückt - meinen Fokus teilen, dann wünsche ich viel Spaß beim Lesen:

WCF Ressourcen

• Windows Communication Foundaton, MSDN
• Windows Communication Foundation, MSDN Library
• .NET 3.0 Community
• .NET 3.0 Download
• MSDN Magazine "Service Station" Kolumne
• Christian Weyers Blog "Smells like service spirit"

WCF Einführungen und Überblicke

Bücher

• Juval Löwy, Programming WCF Services, O'Reilly 2007
  Scheint mir derzeit die umfassendste Darstellung von WCF zu sein. Sehr detailreiche Darstellung, für einen ersten Einstieg im Grunde zuviel. In jedem Fall aber ein must-have als Nachschlagewerk. Gut gefallen hat mir der Versuch am Ende des Buches, "WCF Coding Standards" aufzustellen, d.h. knackige Dos and Donts zu formulieren.
  Die Kehrseite der Medaille ist, Juvals Darstellung ist zu einem großen Teil feature fucking. WCF wird weitestgehend ohne Anwendungszusammenhang dargestellt; der Leser wird mit dem Transfer in die Praxis, d.h. mit dem Abwägen der vielfältigen Optionen alleingelassen. Auch kann man geteilter Meinung darüber sein, ob Juval das Thema konzeptionell optimal angeht. Seine Beschreibungen lassen eine, hm, gewisse Verhaftung mit der guten alten COM+/Enterprise Services Welt vermuten. Die Andersartigkeit echt nachrichtenorientierter Kommunikation im Gegensatz zum RPC-orientierten Umgang mit verteilten Objekten wird nicht wirklich thematisiert.
  Insofern ist Juvals Buch vielleicht nicht das beste, aber zumindest derzeit das kleinste Übel. Ich habe es jedenfalls gern gelesen.
  
• Ralf Westphal, Christian Weyer, .NET 3.0 kompakt, Spektrum Akademischer Verlag 2007
  Mein eigenes Buch, das ich zusammen mit Christian geschrieben habe, empfehle ich nicht, weil es eben unser Buch ist, sondern weil es mir wirklich beim Einstieg in WCF geholfen hat. Ich hatte für meine ersten Gehversuche nach Beispielen gesucht, die kleinschrittig sind - und sie bei Christian gefunden. Darüber hinaus bietet das Buch aber natürlich noch mehr... ;-)

Andere Darstellungen in Buchform zu WCF habe ich auch durchgesehen (z.B. von MSPress, Apress, Wrox), war aber nicht überzeugt. Den Detaillierungsgrad von Juvals Buch erreichen sie nicht. Und sie gefallen mit vom Layout her auch nicht genauso gut wie Juvals. Oft ist die Schrift groß und die Informationsmenge pro Seite klein. Das macht auf mich dann den Eindruck, der Verlag hätte vor allem ein dickes Buch im Auge gehabt, um einen hohen Preis verlangen zu können, und nicht unbedingt ein inhaltsreiches.

Artikel

• Laurance Moroney, The Windows Communication Foundation: A Primer, DevX.com 10/2005
• Aaron Skonnard, Learn the ABCs of Programming Windows Communication Foundation, MSDN Magazine 2/2006
• Clemens Vasters, Introduction to Building Windows Communication Foundation Services, MSDN Online 2005
• Dennis van der Stelt, WCF Part 0: Introduction, Dennis´ Blog 10/2006
• Ralf Westphal, A truely simple example to get started with WCF, Ralf´s Sudelbücher 5/2007
• Christian Weyer, Windows Communication Foundation, dotnetpro 1/2006
• Christian Weyer & Ralf Westphal, dotnetpro.tv #16 - Windows Communication Foundation, dotnetpro 6/2006

WCF Details

• Juval Löwy, WCF Transaction Propagation, MSDN Magazine 5/2007
• Juval Löwy, What you Need to Know About One-Way-Calls, Callbacks, And Events, MSDN Magazine 10/2006
• Juval Löwy, Discover Mighty Instance Management Techniques For Developing WCF Apps, MSDN Magazine 6/2006
• Aaron Skonnard, WCF Addressing in Depth, MSDN Magazine 6/2007
• Aaron Skonnard, WCF Messaging Fundamentals, MSDN Magazine 4/2007
• Aaron Skonnard, Serialization in Windows Communication Foundation, MSDN Magazine 8/2006

BizTalk Connectivity Services [home]

• Clemens Vasters, TweetieBot - A BizTalk Services Experiment, Clemens Vasters´ Blog 5/2007
• Clemens Vasters, Some fun with the BizTalk Services ISB, Clemens Vasters´ Blog 5/2007
• Christian Weyer, Cannot get latest BizTalk Services SDK (May 2) working?, Christians Weyers Blog 5/2007
• Christian Weyer, When you think things are not possible: WCF duplex callbacks through NATs and firewalls - safe and secure, Christian Weyers Blog 4/2007

Themen im WCF Umfeld

• Juval Löwy, Volatile Resource Managed in .NET Bring Transactions to the Common Type, MSDN Magazine 12/2005
• Sahil Malik, System.Transactions: Implement Your Own Resource Manager, codeguru 11/2005

Auswahlhilfe beim persistence.day

Gestern hat die dotnetpro wieder den persistence.day (p.day) veranstaltet. Im letzten Jahr gab es ihn wegen der großen Nachfrage zweimal, in diesem Jahr zunächst einmal - diesmal in München. 140 Teilnehmer wollten sich einen Tag lang gezielt zum Thema Persistenztechnologien informieren. Der p.day bot dafür eine sehr schöne Möglichkeit, denn wohl auf keiner sonstigen Konferenz trifft man so geballt, Hersteller-Know-How an. Da ging es nicht um Marketing-Blabla, sondern es ging ans Eingemachte. Die O/R Mapper Genome, NDO, Persistor.Net und OpenAccess waren mit ihren Entwicklern vertreten wie auch die Hersteller der Datenbanken db4o und TurboDb. Insbesondere über Carl Rosenberger - Erfinder und Chefarchitekt von db4o - habe ich mich gefreut; ihn konnte ich noch wenige Wochen vor dem Event motivieren, einen Vortrag zu halten.

Und ich hatte die "ehrenvolle Aufgabe", den Event mit einer General Session zu eröffnen. Zuerst wollte ich darin typische Vertreter der Persistenztechnologieklassen vorstellen und den Unterschied der Programmiermodelle herausarbeiten. Dann aber... kam mir in der letzten Woche bei der wie immer gerade noch rechtzeitigen ;-) Vorbereitung des Vortrags eine viel bessere Idee: Warum nicht den Teilnehmern sozusagen eine Karte für den Persistenztechnologiedschungel geben? Ist es nicht das, was ein Event wie der p.day leisten soll? Konkrete Guidance und Strukturierungshilfe für ein komplexes Thema? Genau!

Deshalb habe ich - etwas ad hoc, aber immerhin - einen Frage- bzw. Selbsteinschätzungbogen entwickelt und vorgestellt. Der wurde durch die dotnetpro allen Teilnehmern mit ihrer Konferenztasche ausgehändigt. Mit ihm konnten sie angeleitet durch meine Erläuterungen im Vortrag ihren Anforderungen an eine Persistenztechnologie reflektieren und priorisieren - und dann die Aussteller ins Kreuzverhör nehmen. Teilnehmer wie auch Aussteller haben gesagt, das sei eine echte Hilfe gewesen.

"Danke für die vielen Denkanstöße.
Und danke für die Liste. Die ist sehr wertvoll!"
Tibor Odehnal, Teilnehmer am persistence.day

Das freut mich. (Noch besser wäre die Hilfe natürlich gewesen, wenn sie den Ausstellern vorher bekannt gewesen wäre. Dann hätten sie sich dazu schon Gedanken machen können. Naja... nächstes Mal  ;-)

Da nun mein Vortrag keinen Code gezeigt hat und recht untechnisch war, biete ich hier einen kleinen Trost:  Das Kapitel zum Thema LINQ aus dem Buch ".NET 3.0 kompakt", das ich zusammen mit Christian Weyer geschrieben habe.

Wer also Interesse an LINQ hat oder mal in unserem neuesten Büchlein probelesen will , der klicke hier.

Viel Spaß beim Lesen!

 

 

 

 

 

PS: So entspannt und zufrieden sahen übrigens einige Aussteller auf dem p.day aus :

v.l.nr.: Joachim Dürr von iAnywhere, dem Hersteller des Advantage Database Servers, Peter Pohmann von dataweb, dem Hersteller von TurboDb, und Peter Brunner von Vanatec, dem Hersteller des O/R Mappers OpenAccess

Contract-first Design Beispielcode und Tool-Hinweise zu User Group Vorträgen

Am 20.3. und 22.3. habe ich Vorträge zum Thema Contract-first Design vor den .NET User Groups in Ulm und München (Download des Beispielcodes) gehalten. Insgesamt lauschten knapp 80 Entwickler meinen Vorschlägen, wie Software ganz grundsätzlich mit Komponenten als binären Codebausteinen diesseits von SOA-Services und jenseits von Objekten strukturiert werden sollte.

Mit Komponenten habe ich da natürlich das gemeint, was ich in meiner Serie "Software als System" als hybrides Swolon im Schnittpunkt zwischen logischer und physischer Swolon-Hierarchie bezeichne. Auf den Weg von den Anforderungen zu den Komponenten oder das Big Picture von "Software als System" konnte ich allerdings nicht eingehen. Dafür war die Zeit zu knapp. Schon die theoretische Begründung und praktische Demonstration echter Komponentenorientierung hat ja 2-3 Stunden gebraucht - und alle UG Mitglieder haben tapfer ausgehalten.

Und hinterher gab es auch noch interessierte Diskussionen, auch wenn die Implikationen meiner Vorschläge einige recht still gemacht hatten. Echte Komponentenorientierung bedeutet nicht nur, Klassen mal wieder mit Interfaces zu versehen, sondern funktioniert nur auf der Basis eines veränderten Entwicklungsprozesses und einer klareren Codeorganisation, als in den meisten heutigen Projekten. Ich hoffe aber, ich konnte auch den Nutzen eines Umdenkens in Richtung echter Komponentenorientierung vermitteln. Wer mehr Produktivität, bessere Testbarkeit, mehr nutzbringende Dokumentation oder schlicht mehr Qualität und Seelenfrieden haben möchte... der kommt um einige Kurskorrekturen in der Softwareentwicklung leider nicht herum.

Zum Glück machen ein paar Tools den Einstieg aber leichter. Konsequente Komponententests brauchen zwar vor allem guten Willen, wenn der dann aber da ist, sind sie technisch recht einfach. VSTS enthält z.B. einen Unit Test Framework, der auch mit TFS integriert ist. Wer das Geld für VSTS allerdings nicht hat, muss nicht zurückstehen. NUnit ist die Mutter aller automatischen Tests und kostenlos. Allerdings ist NUnit nicht wirklich gut in VS2005 integriert. Macht aber nichts, denn NUnit-kompatible Werkzeuge wie Testrunner (s. folgende Abbildung) oder TestDriven lösen das Problem fast oder ganz kostenlos.

Klicken für Originalbild

Ich bin mit Testrunner schon länger sehr zufrieden. Der macht Unit Tests während der Entwicklung wirklich schmerzfrei und bietet darüber hinaus auch noch eine Codecoverage-Analyse und Profilinginformationen.

Aber Tests während der Entwicklung sind natürlich nicht alles. Echte Komponentenorientierung zerlegt eine Lösung in viele Assemblies, die in separaten VS2005 Projektmappen entwickelt werden. Die muss man den Überblick behalten und immer wieder integrieren. Ein erster natürlicher Integrationspunkt ist ein zentraler Build-Prozess, der die Komponenten periodisch unabhängig vom einzelnen Entwickler auf einem dedizierten Rechner nochmal übersetzt und testet und erst bei Fehlerfreiheit für andere zur Nutzung freigibt.

Dafür setze ich FinalBuilder ein (s. folgende Abbildung; bezieht sich allerdings nicht auf das Beispiel aus dem UG Vortrag). Ein wirklich cooles Tool, mit dem sich die Übersetzung von VS2005 Solutions, deren Test, das Deployment auf einen FTP-Server, der Umgang mit einer Versionsverwaltung uvm. automatisieren lässt. Seit ich FinalBuilder habe, schreibe ich keine Batch-Dateien mehr.

Klicken für Originalbild

Das Bild zeigt ein komponentenorientiertes Projekt aus einer Artikelserie in der dotnetpro. Rechts ist das Script zu sehen, mit dem ich alle zugehörigen VS2005 Projektmappen übersetze und teste, rechts liegt die lange Liste mit vorgefertigten Aktivitäten, aus denen ich solche Scripte zusammensetzen kann. Da bleibt kaum ein Wunsch unerfüllt. Interaktion mit virtuellen Maschinen, parallele Abarbeitung, Workflow, VSS-, SVN-, CVS-, TFS-Nutzung... alles drin.

Aber nicht nur ein umfassender Build-Prozess muss aufgesetzt werden, wenn echte Komponentenorientierung die beliebte allumfassende VS2005 Projektmappe in viele kleine zerschlägt. Es sind dann auch Integrationstestläufe womöglich außerhalb VS2005 nötig. Und der Debugger ist dann vielleicht auch nicht auf einem Staging-System zur Hand. Wer dann wissen will, was so läuft in seinem Programm, der braucht Einblick. Den kann Instrumentierung bieten (z.B. TraceSource einsetzen oder Performance Counter einrichten oder in ein Windows Log schreiben), aber ich finde es auch sehr nützlich, ohne vorgedachte Instrumentierung den Verlauf einer Software beobachten zu können. Derzeit gefällt mir dafür sehr gut SpeedTrace Pro (s. folgende Abbildung).

Klicken für Originalbild

Damit kann ich mich an ein Programm anhängen und mir den Verlauf der Arbeit protokollieren lassen. Das Ergebnis lässt sich filtern, zum Quellcode in Bezug setzen, ich kann sogar das Tracing erst bei einem bestimmten "Event" (Methodenaufruf) starten lassen.

Zuguterletzt gehört zur echten Komponentenorientierung dann noch ein Service Locator oder Microkernel. Mein eigener kleiner Microkernel steht zur freien Benutzung mit kurzen Erläuterungen online. Alternativen sind z.B. Spring.Net oder Windsor des Castle Projects. Die bieten mehr Leistung - für meinen persönlichen Geschmack allerdings oft zuviel. Ich persönlich kann mich auch nicht so recht mit dem Konzept der Inversion of Control (IoC) anfreunden, wenn es um das "Zusammennähen" von größeren Komponentengeflechten geht. Wenn es um Komponenten geht, die ich verkaufen will, oder die in Zusammenhängen eingesetzt werden sollen, in denen nicht sicher ein Microkernel vorhanden ist, dann ist IoC eine gute Sache, um Entkopplung aufrecht zu erhalten. Aber ansonsten ziehe ich innerhalb geschlossener Projekte einen Microkernel als generische Factory vor.

Ich würde mich freuen, wenn ich mit dem Beispielcode des Vortrags vor der UG München und der kleinen Werkzeugliste hier den Einstieg in die echt komponentenorientierte Softwareentwicklung ein etwas erleichtern könnte. Wer das Szenario der Beispielanwendung noch nicht kennt, der sei hier kurz eingeführt (s. folgende Abbildung):

Zwei kooperierende Komponenten sollen entwickelt werden. Die Calculator-Komponente kann Zahlenreihen zwischen zwei Grenzwerten berechnen und solche Zahlenreihen laden/speichern. Sie ist die zentrale Logik-Komponente des Szenarios und verkörpert nach außen die gesamte Funktionalität. Für die konkrete Speicherung ist dann allerdings die DataAccess-Komponente zuständig.

Beide Komponenten sind durch einen Kontrakt definiert. Die Spezifikation der Calculator-Komponente besteht aus dem Calculator- und dem DataAccess-Kontrakt, ersteren exportiert sie, letzteren importiert sie. Die Spezifikation der DataAccess-Komponente besteht aus dem DataAccess-Kontrakt, den sie exportiert, und der Beschreibung des Persistenzformats.

Klicken für Originalbild

Das ist natürlich ein supersimples Beispielszenario. Aber es ging bei der Demonstration nicht darum, komplizierte Funktionen zu implementieren, sondern den Prozess der Entwicklung echter Komponenten erlebbar zu machen. Theoretische Erklärungen am Flipchart sind eine Sache. Dann aber zu sehen, wie die Theorie in die Praxis umgesetzt wird, den Schritten wirklich zu folgen, das ist noch eine ganz andere Sache - und ein Vortrag das beste Medium, um das zu vermitteln. Ich hoffe, das hat geklappt. Freue mich über Feedback an: info (at) ralfw.de.

Maffay neben Westphal - Kaffeehauskonsultation in Ulm

So kann es kommen: Ahnungslos fahre ich nach Ulm zur Kaffeehauskonsultation - und finde neben mir Peter Maffay. Aber nur in der Zeitung :-) Oder anders: Allerdings in der Zeitung, denn bisher hatte ich nicht geahnt, dass kostenloses .NET Technologiecoaching für die Lokalpresse von Interesse wäre. So stand es jedoch am 20.3. in der Neuulmer Zeitung:

Verständlich wurde diese Nähe zu Peter Maffay dann jedoch, als Thomas Schissler erklärte, er habe anlässlich meines abendlichen Vortrags vor der UG Ulm eine Presseerklärung an die Zeitung geschickt. Und ich dachte schon, die Lokalpresse verfolgt mein Blog... ;-)

Ob der Artikel allerdings viel gebracht hat, weiß ich nicht. Die Kaffeehauskonsultation war auch ohne ihn 2 Wochen vor dem Termin schon "ausverkauft". Von 10h bis 17h gaben sich Entwickler die Klinke in die Hand und ich hatte Mühe, zwischendurch einen Happen zu essen. Aber passt schon. Hat wieder viel Spaß gemacht.

Links Thomas Schissler, rechts Andreas Gümbel, der sich mit mir darüber unterhalten wollte, wie er ein single-sign-on für mehrere Web-Applikation realisieren kann.

Auch der Vortrag am Abend in den Räumen von artiso fand vor einem vollen Haus statt.

Knapp 40 Entwickler waren gekommen, um sich einen Eindruck davon zu verschaffen, wie der Weg zur mehr Produktivität, besserer Testbarkeit, einfacherer Wartbarkeit und größerer Verständlichkeit ihrer Applikationen durch echte Komponentenorientierung aussehen könnte. Nach etwas mehr als 2,5 Stunden wussten sie es dann - hoffentlich :-) Denn solange habe ich doch für meinen Vortrag am Flipchart mit anschließender Demo in VS2005 gebraucht.

Die Kombination Kaffeehauskonsultation + UG-Vortrag - danke an INETA für´s Sponsoring - hat mir gut gefallen. Mache ich gern wieder.

Danke an Thomas Schissler für seine Initiatve! Das ist Nutzung der Angebote von Microsoft at its best.

Vom Guten im Schlechten - TurboDb besser dank "Passionsspiele"

In der dotnetpro 4/07 hatte ich unter dem Titel "Passionsspiele" - passend zum Ostermonat ;-) - von meinem Leidensweg bei der Portierung einer .NET 2.0 Anwendung nach Mono berichtet. dnpMelodie, ein (noch und zugegebenermaßen rudimentärer) Windows Media Player/iTunes Clone, wollte ich mal eben so auf Linux umstellen, weil das aufgrund der komponentenorientierten Architektur einfach schien. Leider ging das aber daneben, weil Mono derzeit noch zu wenig kompatibel zu .NET 2.0 ist und... ja, und auch die Datenbank, von der ich dachte, das sie hüben wie drüben laufen würde, eben das nicht tat.

Ich hatte mich für die Neuentwicklung der Datenzugriffskomponente, die zunächst auf die Jet Engine ausgelegt war, für TurboDb von DataWeb entschieden. TurboDb Managed ist eine rein in Managed Code geschriebene Datenbank und sah für mich daher so aus, als sei sie der ideale Kandidat. Wie sich dann allerdings herausstellte, war TurboDb Managed nicht 100% kompatibel zu Mono. Leider hatte ich das aber erst gemerkt, als ich die Datenzugriffskomponente schon neu entwickelt hatte. War dann schade, aber machte auch nicht soviel. Ich hab es dann mit db4o nochmal probiert und die DB-Engine lief dann auch unter Mono - nur meine Anwendung trotzdem noch nicht.

Aber egal. Denn um die Inkompatibilität von TurboDb mit Mono geht es mir hier nicht. Nerviger waren vorher nämlich einige Stolpersteine während des Umbaus auf TurboDb unter .NET. Da funktionierte die SQL ORDER-BY-Klausel nicht wie mit der Jet Engine und ein Feldname war plötzlich ein reserviertes Wort und die Escape-Zeichen für solche Fällen waren schlecht dokumentiert. Davon habe ich dem Artikel im Sinne eines Entwicklungsprotokolls dann auch berichtet.

Und nun hat mich der Hersteller von TurboDb kontaktiert, nochmal genauer erfragt, was mein Problem war... und hat die Probleme behoben. Hier ein Auszug aus der Email von DataWeb:

Hallo Herr Westphal,

vielen Dank für Ihre Hinweise.

Bei der Sortierung haben Sie einen Bug entdeckt. Er betrifft Strings der Länge 1 in ANSI-String-Feldern (also nicht Unicode) der Länge 256 und darüber. Die Ursache liegt im Kompatibilitätscode zu alten Versionen, wo diese Felder nur bis 255 Zeichen lang sein durften. Der Fehler wird noch diese Woche behoben.

TurboDB Managed unterstützt Bezeichner in doppelten Anführungszeichen, wie es der SQL-Standard vorsieht. Das ist auch dokumentiert (im Kapitel über Spaltennamen) wenn auch zugegebenermaßen etwas unscheinbar. Wir haben aber auf Ihre Bemerkungen hin auch die eckigen Klammern ergänzt, wie sie in der MS-Welt üblich sind. Außerdem gibt es jetzt ein AddWithValue für die Parameterkollektion.

...

Das nenne ich prompte Reaktion! Toll! Danke, Herr Holzinger!

Und was lernen wir daraus? Ein bisschen maulen in der Öffentlichkeit hilft. Die Hauptaufgabe von technischen Artikeln ist natürlich zu zeigen, was geht. Aber wenn etwas nicht geht, sollte das nicht einfach stillschweigend mit einem Workaround verborgen werden, sondern durchaus auch in einem Artikel zu Kenntnis der Leser wie auch des Herstellers gebracht werden. Und Hersteller - insbesondere kleinere wie DataWeb - können Pluspunkte sammeln, wenn sie solche Hinweise ernst nehmen und Reaktion zeigen. Sie können damit einen Vorteil gegenüber den Platzhirschen ausspielen: ihre Agilität. Es heißt ja schon lange nicht mehr "Der Große schlägt den Kleinen", sondern auch "Der Schnelle/Flexible den Langsamen/Starren".

Also: Wer eine embedded Datenbank geschrieben in Managed Code sucht, der sollte einen Blick auf TurboDb Managed werfen. Man ist dort kundenorientiert. Das finde ich geiler als Geiz :-)

Das Intuitive Datenmodell IV - Werte als Schnittpunkte

Das Intuitive Datenmodell (IDM) kennt nur ineinander geschachtelte Werte. Eine Intuitive Datenbank (IDB) ist damit ein großer Raum, in dem solche Werte gespeichert werden. Eine beschränkende Vorstrukturierung in Tabellen und Tabellenzeilen ist ihr fremd. Sie kennt nur ein Konzept: den schachtelbaren Wert.

Die Kommunikation mit einer IDB geschieht jedoch in "Happen", die ich einmal Dokument nenne. Jedes Dokument ist eine Ansammlung von Werten, die allerdings im Speichervorgang in das schon vorhandene Wertegeflecht eingewoben werden. Eine IDB nimmt ein Dokument also nicht wie eine RDB einfach in Form einer Kopie auf! In einer IDB existieren keine Daten mehr in Kopie. Eine IDB enthält Werte der "äußeren Welt" und insofern auch Kopien. Aber jeden Wert aus der äußeren Welt, der in einem oder vielen Dokumenten steckte, die einer IDB "dargeboten" wurden, enthält die IDB nur einmal.

Das Relationale Datenmodell (RDM) kennt natürlich im Grunde auch Datengeflechte. Sie werden durch die Beziehungen zwischen Datensätzen hergestellt. Dennoch hat für mich das Daten- bzw. Wertegeflecht des IDM noch eine andere Qualität. Im IDM können nämlich Daten nicht anders, als sich zu verflechten. Es passiert ganz automatisch. Im RDM müssen Sie das Geflecht sehr bewusst weben, indem Sie Beziehungen über Fremdschlüssel aufbauen. Im IDM hingegen "passieren" Beziehungen ganz von allein immer und notwendig überall dort, wo Dokumente dieselben Werte enthalten.

Da das IDM alle Werte nur einmal enthält - und das auf allen Strukturebenen von Dokumenten -, teilen sich Dokumente gleiche Werte automatisch. Gleiche Werte sind quasi die Schnittpunkte von Dokumenten. Hier zwei Dokumente, in denen derselbe Wert in unterschiedlicher Schachtelungstiefe vorkommt:

Aus Sicht des IDM schneiden sich diese Dokumente in dem Wert, der in beiden vorkommt. Sie überlappen in ihm, er gehört zu beiden Dokumenten gleichzeitig.

Einfacher ist dieses Schneiden von Dokumenten allerdings mit einem Baum darstellbar. Er führt zwar wieder Verbindungen zwischen Werten ein, aber die sollen nur Zugehörigkeit beschreiben. Sie definieren eine Enthalten-Beziehung wie die Zusammenfassung von Werten in den vorstehenden Bildern. Verwechseln Sie sie bitte nicht mit Referenzen im Objektorientierten Datenmodell  (ODM) oder Fremdschlüsseln des RDM.

Dokumente können eine beliebige Anzahl solcher Schnittpunkte haben. Enthält ein Dokument mehrfach denselben Wert, so schneidet es sich sogar mit sich selbst.

Für das Verständnis des IDM ist es zentral, den Effekt dieser Dokumentenschnitte zu verstehen. Sie führen dazu, dass sich in einer IDB nicht einfach eine Anzahl nebeneinanderliegender Dokumente anhäuft, sondern alle Dokumente zusammen ein großes Ganzes ergeben. Alle Dokumente sind miteinander verwoben, ohne dass dafür etwas Spezielles getan werden müsste.

Auch sehr Verschiedenes berührt sich dort, wo es Gleiches enthält. Das ist wie im richtigen Leben: Die vorstehende Grafik enthält einen Baum und lässt damit diesen Text mit einem Wald in Verbindung treten. So unterschiedliche Zusammenhänge wie Software und Natur berühren sich im Begriff Baum. Diese Berührung haben Sie und ich nicht geplant, sie entsteht einfach in Ihrem und meinem Kopf durch Verwendung desselben Begriffs hier wie dort.

Im richtigen Leben begrüßen wir solche spontanen Überschneidungen von ansonsten ganz Verschiedenem. Wir versuchen sogar, sie mit Kreativitätstechniken zu befördern. Wem solche Assoziationen leicht fallen, wird gewöhnlich beneidet. Sie sind ein Merkmal von Intuition, wenn sie denn irgendwann bewusst werden. Wannimmer wir ausrufen, "Ach, das erinnert mich an..." oder "Das ist genauso wie bei...", dann sprechen wir über einen solchen Schnittpunkt von Kontexten. Natürlich kann das umso häufiger passieren, je mehr "Weltwissen" wir haben, je aufmerksamer wir beobachten. Jeder Schnittpunkt ist dann ein Brückschlag und lässt uns etwas Neues erkennen.

Analogien sind in diesem Sinne bewusste Brückenschläge, um Zusammenhänge zwischen ansonsten Unverbundenem herzustellen, um Eigenschaften eines Kontexts mit denen eines anderen in Beziehung zu setzen.

Genauso ist es im IDM: Indem Dokumente sich automatisch in jedem übereinstimmenden Wert schneiden, werden immer wieder Verbindungen zwischen ansonsten Unverbundenem hergestellt. Es können und sollen sich Assoziationen ergeben, die quasi unplanbar sind. Dieser Effekt ist natürlich umso größer, je mehr Dokumente in eine IDB aufgenommen werden und je vielfältiger sie sind.

Anders als beim ODM/RDM ist für die Verbindung der Dokumente jedoch viel weniger Planungsaufwand zu treiben. Niemand muss sich hinsetzen und Verbindungen im Sinne von Container-Referenzen planen. Sie ergeben sich vielmehr einfach so im Verlauf der Aufnahme von immer mehr Dokumenten in einen IDM-Werteraum. (Die Diskussion, wie man die Assoziation von Dokumenten durch etwas Planung befördern kann, möchte ich auf einen zukünftigen Artikel vertagen.)

 
Bild anklicken zur Vergrößerung

Das Endresultat der Aufnahme von immer mehr Dokumenten in eine IDB ist ein großes Dokument, dem man nicht mehr ansehen kann, in welcher Reihenfolge seine Teile hinzugefügt wurden. Auch die ursprüngliche Granularität der darin eingegangenen Dokumente ist nicht mehr erkennbar. Aufgenommene Dokumente verlieren sozusagen ihre Identität. Sie werden einfach Teil eines größeren Ganzen; sie werden assimiliert wie Menschen von den Borg bei Star Trek.

Diese Assimilation ist kommutativ und idempotent:

• Sie kann in beliebiger Reihenfolge stattfinden und führt immer zum selben Ergebnis. Dokument A + Dokument B führt genauso zu "Gesamtdokument" C wie B + A.
• Dasselbe Dokument kann beliebig oft assimiliert werden: A + B = C, aber auch A + B+ B = C oder A + A + B = C.

Software als System X - Von der Struktur zur Kooperation

Die logische und die physische  Swolarchie beschreiben Software noch nicht als System. Sie definieren lediglich die Bestandteile aus zwei unterschiedlichen Blickwinkeln. Sie beschreiben, welche Bestandteile aus welchen anderen bestehen. Durch Aufspannen einer Modulhierarchie können Sie sich schrittweise der Problemlösung nähern. Sie verfeinern sie durch neue Hierarchieebenen, wo sie sie für noch zu kompliziert/undurchsichtig halten. Dabei geht es aber nur um grundsätzliche Verantwortlichkeiten im Sinne der Produktion von Anwendernutzen und noch nicht darum, wie der am Ende konkret entsteht. Für ein gegebenes Modul ist die Leitfrage: "Aus welchen Rollen/Submodulen könnte dieses Modul bestehen, die zusammen seine Leistung erbringen?"

Die Modularisierung einer Software dient nur der Ermittlung derjenigen Rollen, die zur Lösung des Gesamtproblems "irgendwie" nötig sind. Ziel ist eine Menge von Modulen, die als Komponenten implementiert werden können.

 
Click image to enlarge

Am Ende der Modularisierung wissen Sie also, was grundsätzlich zu tun ist. Es ist dann klar, welche Bauteile herzustellen sind, aus denen die Software dann zusammengesetzt werden kann. Wie das dann geschieht, beschreibt die physische Swolarchie. Die Modulhierarchie ist sozusagen der Herstellungsplan, die physische Swolarchie der Bauplan für Software.

Modellierung ist kein Selbstzweck. Sie dient vielmehr der Beantwortung von Fragen:

1. Wer tut am Ende was?
2. Wo tut wer etwas?
3. Wie tut wer etwas?

Warum und Wofür sind der Ausgangspunkt und durch die Anforderungen an die zu entwickelnde Softwarelösung gegeben.

Die Modulhierarchie ist die Antwort auf die erste Frage. Ihr Ergebnis ist eine Liste von Rollen oder Verantwortlichen, den Hybriden, die am Ende die "Fabrik Software" konstituieren. Die Modularisierung ermittelt diese Verantwortlichen aber nur, setzt sie quasi nur ungeordnet in einen Raum. Das kann auf jeder Ebene des Herstellungsplans geschehen (s. die Schnitte im obigen Bild).

Der Bauplan beantwortet die zweite Frage. Er legt fest, wo die Hybriden im späteren Softwaresystem zum Einsatz kommen, zu welchen Superkomponenten oder Prozessen sie zusammengesetzt werden müssen, um ein im Sinne der Anforderungen funktionsfähiges Ganzes zu ergeben.

Und wer beantwortet die dritte Frage? Es ist ein weiterer Plan nötig, der Kooperationsplan. Ein Kooperationplan beschreibt für einen Schnitt durch eine Ebene von logischer oder physischer Swolarchie die Verbindungen zwischen den Swolons. Er definiert, wie die Swolons miteinander kooperieren/kommunizieren, um zusammen Anwendernutzen hertzstellen.

Click image to enlarge

Die Beziehungen zwischen Swolons in einem Schnitt müssen dabei natürlich grundsätzlich denen in anderen entsprechen, die denselben Systemausschnitt beschreiben. Bei den Kooperationsplänen für Schnitt 1 und Schnitt 2 im vorstehenden Bild ist das der Fall. Die gestrichelten Pfeile zeigen das Mapping von logischen Swolons auf physische inkl. ihrer Verbindungen. Die Modellierung muss hier also ein Auge auf die Konsistenz der unterschiedlichen Pläne haben.

In UML werden Kooperationspläne als Kollaborationsdiagramme dargestellt. Ich möchte mich in dieser Serie jedoch nicht zu sehr an UML binden, um den allgemeinen Begriff der Swolons nicht mit Bedeutungen aufzuladen, die ihm angesichts seiner Jugend schaden könnten. UML wurde vor allem aus C++ und Java geboren und hat seine Wurzeln bei allem Willen zur Allgemeingültigkeit also in der Objektorientierung. Mein Ziel ist jedoch, über die Objektorientierung hinaus zu gehen, sozusagen auf sie zu steigen, um auf ein höheres Level bei der Softwareentwicklung zu kommen. Komplexe Software zu beschreiben darf nicht (zu früh) von Konzepten der Objektorientierung behindert werden.

Paket-, Komponenten-, Klassen- und Kollaborationsdiagramme haben alle ihren Wert. Wenn Sie sie zur Darstellungen von Swolarchien benutzen wollen, dann tun Sie das gern. "Software als System" steht dem nicht im Wege. Ob die Diagramme dann allerdings so hübsch aussehen, wie die Grafiken in dieser Postingreihe... das weiß ich nicht ;-)