Die thinktecture-Gespräche: Indigo
Navigation:
Seite 1 -
Seite 2 -
Seite 3
Feedback:
Sagen Sie uns, wie Ihnen unsere thinktecture-Gespräche gefallen!
RW
Ja, so sehe ich es auch: Wir als Technologievermittler
sollten nicht immer zeigen, was geht, sondern was sinnvoll ist. Wir haben auch
eine Filterfunktion - und manches sollte da halt auch mal hängenbleiben, so
z.B. die RPC-Notation für Indigo-Dienste. Einfach nicht zeigen. Fertig.
Ich bin immer dafür, dass die Dinge möglichst so aussehen,
wie sie sind. Wenn Kommunikation essenziell nachrichtenorientiert ist, dann
sollten die dafür nötigen Mittel im Code das widerspiegeln. Aus dem Grund
wünsche ich mir ja auch eine spezielle Notation für Schnittstellen. Eine DSL,
in der Dienste nur Operationen definieren können und Datenstrukturen nur Daten
enthalten. Heute werden dafür GPLs benutzt, mit denen ich Diensten syntaktisch
korrekt auch Daten geben kann und Daten Methoden. Das führt zu
Missverständnissen. IDLs (Interface Description Languages) wie noch zu Zeiten
von COM und heute noch bei CORBA sind irgendwie in Ungnade gefallen - wie ich
finde zu unrecht. Man hat das Kind mit dem Bade ausgeschüttet.
Eine Indigo Message ist also die Manifestation einer
SOAP-Nachricht als Objekt. Sehr interessant. Bei .NET Remoting gibt es ja auch
Message-Interfaces (und dahinter stehende Klassen), aber die sind proprietär.
Das Programmiermodell ist nur durchaus unterhalb der RPC-Schicht ähnlich. Mit
Indigo basieren die Nachrichten auf einem Standard. Gut so.
Da du aber sagst, dass eine Indigo Message bei ihrer Reise
zwischen Client und Service nicht notwendig nach XML serialisiert werden muss,
stehen Message und SOAP XML in einem Verhältnis zueinander wie XML DOM und XML.
Hier ein Objektmodell, dort eine nach XML serialisierte Form. So wie es für XML
ein Infoset gibt, gibt es also für SOAP auch ein "SOAP Infoset", d.h.
eine abstrakte Definition einer Hierarchie von "Entitäten"?
Wird denn mein eigener Nachrichtentyp, z.B.
ReservationRequest, intern erst in ein Message-Objekte gewandelt und dann erst
"auf die Leitung gelegt"? Hm... muss ja eigentlich, denn die
generischen Schichten von Indigo wollen ja eine einheitliche Sicht haben, um
ihre WS-* Header reinzuhängen und was nicht sonst noch alles tun zu können. Das
bedeutet für mich dann auch, dass Indigo ein ähnliches Erweiterungskonzept wie
.NET Remoting haben muss: Es wird eine Pipeline von Interceptoren geben, die
beim Client und Service in einem Indigo-"Kanal" hängen, oder? Jeder
Interceptor kann dann eine WS-*-Leitung erbringen oder etwas von mir selbst
definiertes tun. Microsoft hat mit .NET Remoting also erstmal/schonmal geübt
:-)
Im nächsten Schritt würde das für mich aber auch bedeuten,
es gibt eigentlich kein Hindernis, Indigo auch zwischen AppDomains einzusetzen.
Ich muss nur einen eigenen "Kanal" und (De)Serialisierer entwickeln,
der ähnlich effizient arbeitet. Das Programmiermodell der nachrichtenorientierten
Kommunikation macht ja auch Sinn zwischen AppDomains, denn per stackbasierte
Aufrufe funktionieren auch dort nicht.
CW
Bruder, Du schweifst ab ;) Aber über die Sache mit den
Schnittstellen und DSLs können wir uns gerne mal gesondert unterhalten. Wie Du
weißt habe ich da meine ganz eigene Sicht und Ideen dazu :)
So, ja. Indigo ist extrem erweiterbar. Man kann
sprichwörtlich alles ersetzen oder überall in der Indigo-Architektur Sachen dazu
bauen, ganz leger gesprochen.
Aber mit der Cross AppDomain-Kommunikation via Indigo ist es
leider nicht ganz so einfach wie man erst vermuten mag. Wir haben uns
über die IPC Story für V1 unterhalten. Sie ist recht einfach:
Remoting für Cross AppDomain, Intra Process. Ansonsten
Indigo. Es gibt eine Reihe an mitgelieferten Channels. TCP, HTTP, MSMQ, Named
Pipes,PeerNet. Die Idee ist nun, einen Indigo Custom Channel für
Intra-Prozesskommunikation zu bauen und den CrossAppDomainChannel von Remoting zu
verwenden. Dieser ist freilich nicht direkt zugänglich, da internal. Aber es
sollte genügen, einfach ein remotable Objekt über eine AppDomain-Grenze
bereit zu stellen - also implizite Nutzung des CrossAppDomainChannel. Ziel ist,
dass Entwickler *eine* Plattform und *ein* Programmiermodell verwenden, um
jegliche Art von "Anwendungskommunikation" zu implementieren.
Man müsste jedoch den Indigo Formatter verwenden und dann
wäre die Performance um einiges schlechter als die von .NET Remoting
Cross Appdomain. Der Grund warum der Remoting Formatter ausfällt ist, dass
dieser einfach transparent MarshalByRefObjects (die *irgendwo* in den
Parametern versteckt sein können ... also auch irgendwo "tief" unten)
als Remote-Komponenten überträgt. Es wäre dann aber der Backchannel .NET Remoting
und nicht Indigo.
Führt also eher zu massiver Verwirrung ...
RW
Hey, hey, wo bin ich denn abgeschweift? Weil ich über die
Interna von Indigo nachgedacht habe, dass alle Nachrichten am Ende wohl in ein
Message-Objekt ungesetzt werden, dass die Grundarchitektur von Indigo wohl so
wie bei .NET Remoting aussieht? Oder die Spekulation über ein "Indigo
Infoset"? Ich empfinde das nicht als Abschweifen, sondern als konstruktiv
im Sinne eines Versuchs einer Synthese (als Gegensatz zur Analyse) von etwas,
dessen "Innereien" ich nicht wirklich kenne. Ich hätte mir da von dir
auch Bestätigung oder Korrektur gewünscht, wenn du darüber etwas weißt. Ich
möchte ja mehr über Indigo erfahren, die Prinzipien verstehen.
Den Gedanken einer DSL für die Schnittstellendefinition
können wir natürlich ein andermal vertiefen.
Mit der "IPC Story" meinst du Microsofts Story.
Microsoft sagt, "Wir haben doch eine funktionierende intra-AppDomain
Technologie, warum dann gleich Indigo auch noch dafür passend machen?" Ok,
das kann ich verstehen. Und ich fände es sogar akzeptabel, wenn das so bliebe.
Klare Abgrenzungen/Profile finde ich am wichtigsten, nicht unbedingt
Simplizität - auch wenn die schön ist.
Und so wäre es natürlich auch schön, wenn Indigo schon
demnächst nicht nur grundsätzlich, sondern auch effizient zwischen AppDomains
funktionieren würde. Dann wäre das Programmiermodell für alle entfernten
Operationen einheitlich. Das wäre schon cool. Wow! Gehen tut das natürlich
heute auch schon. Ich kann ja, wenn ich will, Indigo zwischen AppDomains
innerhalb desselben Prozesses einsetzen. (Denn wenn wir genau sind, dann
kommunizieren ja auf .NET immer AppDomains miteinander und nicht Prozesse.) Wem
also Einheitlichkeit wichtig ist und nicht maximale Performance, der kann sie
schon heute haben und wartet dann vielleicht ein bisschen, bis jemand einen
speziellen cross-AppDomain Indigo-Channel usw. gebastelt hat. Ob das dann er
.NET Remoting Channel ist oder nicht, ist ja egal.
Wer Effizienz will, für den sieht Kommunikation morgen also
so aus:
-Intra-AppDomain: stackbasiert
-Intra-Applikation, cross-AppDomain: .NET Remoting
-Inter-Applikation: Indigo
Wer Einheitlichkeit bzw. Einfachheit haben will, der geht so
vor:
-Intra-AppDomain: stackbasiert
-Intra-Applikation, cross-AppDomain: Indigo
-Inter-Applikation: Indigo
Das wäre dann Einheitlichkeit im Programmiermodell
(nachrichtenorientiert), Einheitlichkeit im Denken (nachrichtenorientiert),
Einheitlichkeit in der Technologie (Indigo) für die gesamte entfernte
Kommunikation.
Ich jedenfalls würde immer - wenn es irgend geht - zum Weg
der Einheitlichkeit raten. (Intra-Applikation cross-AppDomain Kommunikation ist
ja auch nicht so häufig. Wenn Software heute verteilt wird, dann meist gleich
auf mehrere Prozesse.)
Für mich stellt sich in dem Zusammenhang auch gleich die
Frage: Was ist das Essenzielle an Indigo? Was ist wirklich, wirklich wichtig?
Bei .NET Remoting hat sich das erst nach 1-2 Jahren herauskristallisiert. Zur
Erklärung von .NET Remoting ist es in 90% aller Fälle nicht nötig, ein Wort
über RealProxy oder Kontextattribute zu verlieren. Das Zeugs gibt es - aber
keiner braucht es (bzw. fast niemand). Gut dass es das alles gibt - aber es ist
letztlich für 90% aller Entwickler irrelevant.
Und wie lautet die 90%-Botschaft für Indigo? Das, was man
heute darüber hört, ist sie noch nicht. Zuviele technische Details.
CW
Bei den DSLs bist Du ein wenig abgeschweift. Aber das klären
wir später.
Ich denke bisher habe ich alle Deine Fragen beantwortet
oder? Oder welche Fragen zu den Innereien sind offen? Immer raus damit. :)
OK, back to topic:
Deine Analyse zu Effizienz und Einfachheit passt! Am Ende des Tages muss man dann bei der Optimierung einer
Applikation schauen, ob man nicht der Effizienz den Vorrang ggü. Der
Einfachheit gibt. Klar.
Hier ist meine Variante der 90%-Botschaft von Indigo - wobei
ich selbst ständig auf der Suche bin, diese Botschaft zu verbessern:
Die Zukunft der erfolgreichen Kommunikation liegt in der
Entkopplung. Entkopplung erreicht man durch ein nachrichtenorientiertes
Denken und Handeln. Indigo ist *die* Plattform - als Laufzeitumgebung
und als Programmiermodell - um Nachrichtenorientierung wahr und
greifbar werden zu lassen. Alles andere ist Implementierungsdetail. Das kann
man dann in den anderen 10% betrachten.
RW
Mit deinem Credo, die Zukunft der erfolgreichen
Kommunikation liege in der Entkopplung, stimme ich komplett überein. Da wir
hier über Indigo sprechen, möchte ich es aber noch erweitern und formulieren:
Die Zukunft der Softwareentwicklung liegt in der rigorosen Identifikation von
Komponenten (jeder Granularität) und deren angemessener Entkopplung. Bei Indigo
geht es ja quasi natürlicherweise immer um die Kommunikation von
"Komponenten". Es sind die zu verbindenden Prozesse (lassen wir
AppDomains mal außen vor). Und Prozesse (bzw. die dahinter stehenden Lösungen)
existieren entweder schon oder ich muss mindestens einen pro neuer Lösung
schaffen. Jeder Prozess bildet per definitionem eine klar identifizierbare
Einheit und ist damit ganz natürlich eine Komponente bzw. ein
Komponentenkandidat. Entwickler können sich nicht wehren, Prozesse zu
erschaffen. Und darauf beziehst du dich erstmal und sagst zurecht: "Leute,
überlegt euch gut, wie die Schnittstellen eurer Prozesse aussehen und wieviel
kommunizierende Prozesse übereinander wissen müssen! Entkopplung ist eine
Tugend!"
Ich dagegen komme von der prozessinternen Architektur her.
Und da sehe ich zunächst einmal eine große Not, innerprozessliche Komponenten
zu schaffen. Die ergeben sich nämlich nicht einfach so ganz natürlich. Da haben
Entwickler immer wieder eine Wahl - und entscheiden sich oft gegen eine echte
Komponentenorientierung. Software in Klassen/Typen aufzuteilen, ist zu wenig.
Und Software aus mehreren eigenen Assemblies zusammenzusetzen, ist auch noch
zuwenig (wenn auch schon ein Schritt voran ;-)
Zum echten komponentenorientierten Denken gehört der Wille
zur Entkopplung der Komponenten.
Die erste Frage lautet: Was sind geeignete Komponenten für
eine Software?
Die zweite Frage lautet: Wie sieht eine angemessene
Schnittstelle aus? (Und damit geht das Nachdenken über Entkopplung einher.)
Für mich ist das dann auch nicht nur eine Frage der
Softwarearchitektur, sondern des Softwareentwicklungsprozesses. Eine
Architektur braucht auch immer einen geeigneten Prozess, um sie zu
verwirklichen. Konkret heißt das: Wer zwar komponentenorientiert entwirft,
diese Entkopplung der Software dann aber nicht im Team lebt, der erreicht das
Ziel nicht.
Zum Abschluss noch eine konkrete Frage zu den Innereien von
Indigo:
Wenn ich zwischen Client C und Service S einen Indigo-Contract
definiere und in dem Contract taucht Klasse D auf, um Daten zu transportieren,
dann ist das zunächst einmal eine hübsche Definition, mit der ich Code auf der
Client- und Serviceseite schreiben kann.
Für mich ist die Klasse D jedoch wirklich nur eine Klassen
für den Datentransport. Würden C und S nicht über Indigo kommunizieren, sondern
innerhalb desselben Prozesses leben, bräuchte ich D nicht. Dann würde ich
nämlich Objekte der Klasse O direkt als Referenz z.B. aus S an C rausreichen.
Aus Sicht der Problemdomäne, für die die Kombination C+S eine Lösung darstellt,
ist also nur O nötig. Wenn dann aus nicht-funktionalen Anforderungen heraus
(z.B. Skalierbarkeit) entschieden wird, C und S zu verteilen, dann brauche ich
zusätzliche Technik (Infrastruktur), dann kommt Indigo ins Spiel. Und nur für
diese Technik ist dann D nötig. Auf Seiten von S habe ich ein O-Objekt, muss es
aber in eine D-Instanz umkopieren, dann verschickt Indigo es serialisiert an
die Client-Seite, dort wird daraus wieder eine D-Instanz - die wieder in ein
O-Objekt gewandelt werden muss. S und C denken also in O-Objekten, die
Kommunikation ist nur an D interessiert.
Wenn du dem zustimmst, dann hier endlich meine Frage: Bietet
Indigo eine Hilfe, um O-Objekte in D-Instanzen zu transformieren (und
umgekehrt)? Ich halte das für ein Problem, dass letztlich an jeder
Indigo-Schnittstelle auftritt. Meine Geschäftslogik interessiert sich nicht für
die Details der Kommunikation zwischen Komponenten, sie ist insofern
technikfrei. In meiner Geschäftslogik kommt nichts von ADO.NET vor, nichts von
WinForms und nichts von Indigo. D ist jedoch ein Indigo-abhängiges Detail.
Hilft mir Indigo, die Kommunikationsadapter, die ich schreiben will, um meine
Geschäftslogik technikfrei zu halten, übersichtlich zu halten und nicht
Unmengen an Transformationscode schreiben zu müssen?
Bin gespannt auf deine Antwort!
CW
Oh wie ich diesen Satz liebe: Entkopplung ist eine Tugend -
prima! Jaaa!
Viele Entwickler wurschteln heutzutage einfach viel zu viel
vor sich. Getreu dem Motto: naja, schaun mer mal ob ich das hinbekomme, wird
schon gehen, schön machen wir es danach. Nur: es macht keiner mehr
"schön". Das Gewurschtel bleibt; das Geschwulst wächst und nach einiger
Zeit jammern die Entwickler, deren Chefs (und im Extremfall auch noch der
Kunde), dass alles ja sooo komplex und kompliziert ist. Hier muss sich etwas
ändern, absolut.
Und die *Denkweise*, die wir hier sozusagen zunächst
implizit propagieren muss explizit werden - es muss aktiv nach außen getragen
werden, dass so, wie wir die Anwendungs- und Komponentenkommunikation in
einer Vielzahl von Projekten bisher gemacht haben, nicht mehr funktionieren
wird und kann. Indigo - und ich wiederhole mich hier gerne - wird diesen
Umstand auch nicht von heute auf morgen auf der Welt wischen, nein! Indigo wird
ein tolles Werkzeug werden, welches aber dennoch richtig angewendet
werden muss.
Es ist also mehr, als ein API und eine Plattform zu lernen
und zu verinnerlichen. Die ganze Sache fängt weit vor dem Code, vor
VS, vor dem Keyboard und der Maus an: nämlich im Kopf. Und das ist
meines Erachtens die schwierigste Hürde, die wir nehmen müssen.
Dabei reden wir heute eigentlich wieder über Dinge, die
damals zu COM-Zeiten schon gepredigt wurden, aber durch "unglückliche"
Tools und Evangelisierungsmaßnahmen leider gescheitert sind:
Schnittstellen, Schnittstellen, Schnittstellen!!!
Nun aber zu Deiner konkreten Frage wenn es um den Tausch von
Daten und Metadaten in einem mit indigo implementierten Szenario geht.
Wie Du schön feststellst, ist D nicht wirklich eine typische
Klasse im klassischen OO-Sinne, sondern vielmehr was Martin Fowler als
Data Transfer Object (DTO) bezeichnet (http://www.martinfowler.com/eaaCatalog/dataTransferObject.html,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesDTO.asp).
Nun stehen wir aber vor exakt dem von Dir beschriebenen
Problem, der manuellen Umkopiererei. Und die Lösung heißt - mal wieder -
Schnittstellen und Patterns. Die interne Implementierung eines Services,
also bspw. das was wir gemeinhin als Geschäftslogik bezeichnen, implementiert
eine interne Schnittstelle. Der Service selbst, in diesem Falle mit
Indigo umgesetzt, implementiert die öffentliche Schnittstelle, in der D
definiert ist. Jetzt ist es quasi "Zufall", dass diese öffentliche
Schnittstelle gerade mit Indigo implementiert wird, sie könnte aber ebenso gut mit
ASMX, Enterprise Services oder-was-weiss-ich implementiert werden. Dieses
Problem und die Lösung sind völlig unabhängig von Indigo.
Um nun die Umsetzung von interner nach externer
Schnittstelle und wieder zurück hinzubekommen bedient man sich des Adapter Patterns.
Ja, dies ist händischer Aufwand, der unter Umständen immer wieder neu
geschrieben werden muss je nach Projekt und Szenario. Also brauchen wir
Automatismen und Tools, die uns hier helfen!
Nein, Microsoft selbst wird in Visual Studio keinerlei
Unterstützung für derartige Szenarien einbauen. Aber es gibt eine Hoffnung:
wir von thinktecture, also vor allem ich, arbeiten mit Microsoft
EMEA und Microsoft Corp. an einer Erweiterung für Visual Studio 2005, die sich
eben genau diesem Problem annimmt. Wir sind gerade in der
Spezifikationsphase, eine frühe Version wird auf der PDC in LA gezeigt. Aber ich kann
dir versichern, dass all das, was Du und ich hier über Schnittstellen und
Patterns und die damit verbundenen Probleme diskutiert haben, mit diesem Tool
adressiert werden soll. Unabhängig von Indigo. Ja, Indigo und AMSX und
ES werden als Technologien unterstützt werden in diesem Tool.
Es bleibt spannend.
Es gibt also viel zu tun, Ralf. Packen wir es an!
Navigation:
Seite 1 -
Seite 2 -
Seite 3
Feedback:
Sagen Sie uns, wie Ihnen unsere thinktecture-Gespräche gefallen!
Architecture Briefings