Die thinktecture-Gespräche: Indigo
Navigation:
Seite 1 -
Seite 2 -
Seite 3
Feedback:
Sagen Sie uns, wie Ihnen unsere thinktecture-Gespräche gefallen!
Ralf Westphal (RW)
Hallo, Christian!
Auf der TechEd habe ich zum ersten Mal einen näheren Blick
auf Indigo geworfen. Es ist doch irgendwie etwas anderes, ob ich hier und da
mal einen Artikel lese oder mir ein Mensch auf der Bühne etwas demonstriert ;-)
Bisher hatte ich zu Indigo eher keine Meinung bzw. war eher
skeptisch, dass Indigo viel mehr sein würde, als eine weitere Evolutionsstufe
der Microsoftschen Kommunikationstechnologien wie .NET Remoting oder COM+ oder
Web Services. Mit der TechEd hat sich mein Bild aber gewandelt. Ich bin jetzt
der Meinung, dass Indigo ein wesentlicher Schritt nach vorne ist. Ich würde
sogar fast von einem Quantensprung sprechen, einem Fortschritt, der dem von VB1
für die Windowsprogrammierung und von VB3 für die Datenbankprogrammierung
entspricht. Kurz: Ich bin begeistert - auch wenn ich von den Details von Indigo
noch nicht viel weiß.
Indigo ist cool! Sehr cool!
Aber Indigo ist auch erklärungsbedürftig.
Insofern meine Frage an dich: Kannst du mir ein Fragen
beantworten?
Meine ersten beiden wären:
-Welchen Wert hat .NET Remoting, sobald es Indigo gibt?
Ersetzt Indigo .NET Remoting?
-Was wird aus COM+, d.h. dem Application Server von Windows?
Wird er überflüssig, weil ich ja ganz einfach aus jeder Consolen-Anwendung
einen Indigo-Host machen kann?
Soviel fürs Erste. Bin gespannt auf erhellende Worte von
dir.
Ralf
Christian Weyer (CW)
Na, das freut mich aber, dass dir das gefällt :) Ja,
Indigo ist sehr cool, keine Frage.
RW: “-Welchen Wert hat .NET Remoting, sobald es Indigo gibt?
Ersetzt Indigo .NET Remoting?“
CW: Ja und nein. .NET Remoting ist primär dafür
gedacht, Kommunikation zwischen AppDomains und zwischen Prozessen auf einer
Maschine zu erledigen.
Allerdings lässt sich Remoting auch in einem begrenzten
Szenario verwenden, um verteilte Applikationen zu erstellen, die über
Maschinengrenzen hinweg kommunizieren. Genau dieser letzte Punkt ist nun aber
freilich die primäre Zielsetzung von Indigo. Im Gegensatz zu Remoting baut Indigo aber nicht auf das
Konzept der verteilten Objekte, sondern vielmehr auf die Services-Idee.
Es sind also zwei grundlegende Herangehensweisen, die sich eine ganze
Zeit lang ergänzen werden. Vor allem für die Kommunikation innerhalb eines Prozesses
zwischen zwei AppDomains wird man noch einige Zeit Remoting verwenden
müssen, da Indigo v1 hier keine Lösung bietet.
RW: „-Was wird aus COM+, d.h. dem Application Server von
Windows? Wird er überflüssig, weil ich ja ganz einfach aus jeder
Consolen-Anwendung einen Indigo-Host machen kann?“
CW: Wieder ja und nein :) Gewisse Features con COM+
werden mit Indigo überflüssig. Als Beispiele kann man automatische und
deklarative Transaktionsunterstützung heran ziehen. Indigo ist aber kein
klasssicher Application Server, sondern vielmehr eine Plattform, die
gewisse Funktionalitäten anbietet, aber keine Vorgaben macht, wo die
Services, welche diese Features nutzen, ablaufen müssen. Doch dieser Umstand bedeutet nicht, dass nun jeder
Entwickler seine Indigo Services in einer Konsolenanwendung oder einer anderen
custom Application hosten soll. Um eine robuste, zuverlässige, skalierbare,
sichere und verwaltbare Anwendungsarchitektur mit Indigo hinzubekommen,
benötigt man ein universelles Hosting Model. So wie es bei COM+/ES und bei IIS/ASP.NET
der Fall ist. Und genauso wie man Remoting eigentlich auch
verwenden sollte. Für Indigo (und auch andere Teile von Windows und WinFX)
wird es daher den WAS geben. Der Windows Activation Service stellt viele der
oben genannten Qualitäten zur Verfügung und ist nicht an eine Technologie
zur Kommunikation mit der Anwendung oder dem Service gebunden. TCP, UDP, Named
Pipes, HTTP oder Queuing - Services können über all diese Protokolle
mittels Nachrichten aktiviert werden.
RW
Hi, Christian!
Da hast du dich ja schön mit "Ja und
Nein"-Antworten auf der Affäre gezogen :-) Um´s für mich klarer zu
kriegen, versuche ich mal eine Zusammenfassung:
-.NET Remoting hat auch mit Indigo seine Berechtigung für
die RPC-Kommunikation zwischen AppDomains bzw. Prozessen auf der selben
Maschine, weil Indigo keine RPC-Kommunikation in dieser (einfachen, intuitiven)
Weise bietet.
-COM+ hat auch mit Indigo noch seine Berechtigung, weil es
als Host Dienste bietet, die Indigo nicht bietet. Indigo ist eine
Kommunikationstechnologie, COM+ ist ein Host. Allerdings hat COM+ als Host
bisher auch Kommunikationsarten bzw. -kanäle angeboten. Das bedeutet umgekehrt:
COM+ wird obsolet für kommunikationsorientierte Features wie asynchrone
Kommunikation, für andere Features behält es seinen Wert. Nur weil ich
asynchron kommunizieren will, muss ich nicht mehr Queued Components einsetzen.
Nur weil ich durch Transaktionen sicherstellen will, dass mein Empfänger seine
Arbeit ganz oder gar nicht erledigt, muss ich keine transaktionale Serviced
Component in COM+ aufhängen.
Die COM+ Features, die aber nichts mit Kommunikation,
sondern mit Hosting zu tun haben, mach auch in Indigo-Zeiten noch Sinn:
Rollenbasierte Sicherheit, Object Pooling, Loosely Coupled Events.
Wie sieht es aber aus mit Just in Time Activation? Kann ein
Indigo-Service zustandsbehaftet sein, d.h. über einen Operationenaufruf hinaus
existieren?
Und umgekehrt: Macht es Sinn über einen Indigo-Service als
COM+-Applikation oder in einer COM+-Applikation nachzudenken? Oder kann ich
mich nur zwischen Indigo und COM+ entscheiden, wobei es bei den
Kommunikationsfeatures einen gewissen Overlap gibt?
Der Windows Activation Service (WAS) kling ja spannend.
Kannst du dazu noch ein paar Worte verlieren. Was muss ich mir darunter
vorstellen? Eine EXE-Datei, d.h. einen Service, in den ich mich einhängen kann,
wenn ich z.B. eine bestimmte Schnittstelle implementiere? Oder umgekehrt eine
Komponente, die ich in meiner Console.EXE instanzieren kann?
So, jetzt zum Abschluss nochmal kurz zu .NET Remoting bzw.
RPC: .NET Remoting und COM+ und die "normalen" Web Services sind ja
alle RPC-Technologien, d.h. ich rufen Objekte in einem anderen Prozess auf. Im
Client sehe ich eine Methode mit möglicherweise vielen Parametern und bekomme
vielleicht einen Resultatswert zurück. Das ist zumindest sehr bequem vom
Programmiermodell her. Die "Entfernung" des Serverobjektes zum Client
ist transparent.
Und jetzt sagst du, genau das würde Indigo (noch) nicht
bieten. Korrekt?
Aber was bietet denn Indigo dann, wenn ich meinen Service so
nicht aufrufen kann?
Und wenn Indigo schon kein bequemes RPC bietet, dann hat das
sicher seinen Grund. Ok. Aber warum sollte ich dann überhaupt noch etwas
anderes machen, als Indigo bietet. Ist dann von RPC nicht per se eher
abzuraten?
Du siehst, trotz (oder wegen) meiner Begeisterung sind noch
viele Fragen offen :-)
-Ralf
CW
Ich möchte noch kurz auf Deine Zusammenfassungen eingehen:
Ja, Indigo ist so absolut kontra-RPC. Hinzu kommt eben das
technische Detail, dass die die Kommunikation über AppDomain-Grenzen
hinweg in optimierter Art und Weise nur mit Remoting möglich ist
(Stichwort: CrossAppDomainChannel).
Und COM+'s LCE haben durchaus mit Kommunikation zu tun, IMO.
Indigo Services können über entsprechende Konfiguration
durch Verwendung von Attributen auch zustandsbehaftet sein, ja.
Du musst dich nicht zwischen COM+ oder Indigo entscheiden.
Beide können schiedlich friedlich koexistieren. Auf der einen Seite gibt
es Integrationsmechanismen, über die Indigo Clients
COM+-Anwendungen und COM/COM+-Anwendungen Indigo Services aufrufen können - ohne
etwas am Code ändern zu müssen oder speziellen Code schreiben zu müssen.
Auf der anderen Seite kann es freilich von einem
Architekturstandpunkt her Sinn machen, einen Indigo Service zu schreiben, der dann
sozusagen als Facade in eine existierende COM+-Applikation hinein zeigt.
Ja, WAS ist hoffentlich das, was man sich immer gewünscht
hat. WAS ist ein NT Service, der im System läuft. Um ihn zu
nutzen, musst du einfach nur die richtigen Konfigurationsdateien schreiben,
fertig. Die Details hierzu sind noch nicht spruchreif, da das Ganze erst
mit Longhorn kommen wird.
Jaja, die Geschichte mit dem RPC. RPC ist eine
"natürliche" Erweiterung eines lokalen Programmiermodells, welche zugegebenermaßen
sehr verführerisch und sexy ist, weil einfach. Einfach zu
verstehen (man muss nämlich nichts denken) und einfach anzuwenden.
Doch RPCs sind gleichermaßen eng gekoppelt wie lokale
Aufrufe auf Objekte oder Komponenten. Mit RPC ignoriert man regelrecht
essentielle Faktoren wie Latenz, mögliche Fehler und Concurrency, die fehlende
Kontrolle über andere Systeme und nicht zuletzt das Nichtvorhandensein einen
"gemeinsamen Speicherbereiches".
Das haben übrigens schon Waldo & Co. (Technologie-Päpste
aus der Java-Welt) in einem exzellenten Paper aus dem Jahre 1994 festgestellt:
http://research.sun.com/techrep/1994/abstract-29.html
Und dennoch tun wir es, einfach so... :(
Unser Freund
Gregor Hohpe sagt immer:
“As applications become more interconnected, asynchronous
messaging is likely to be the next big architectural trend. Similar to
the shift from procedural to object-oriented programming, we need patterns
and best practices to help us master the new paradigm.”
Ich meine, dies sagt schon viel und kann auch als eine der
Motivationen hinter Indigo gesehen werden. Patterns und Guidance ist gut.
Dieses gemischt mit einer dazu passenden Plattform: voila.
RW
Das ist ja eine sehr deutliche Aussage: "Indigo ist
[...] absolut kontra-RPC"
Macht das Indigo unattraktiv für viele Entwickler? .NET
Remoting und COM+ sind so schön einfach.
Und so ganz verstehe ich es auch noch nicht, dass Indigo so
kontra RPC ist, denn auch in Indigo kann ich ja einen Service Contract (also
die Operationen eines entfernten Dienstes) in Form von Methoden (eines Interface)
mit "normaler" Signatur definieren, oder?
Indigo wird also (zunächst) kein spezielles Binding für
cross-AppDomain Kommunikation anbieten? Wenn ich Indigo in so einem Szenario
einsetzen will, dann muss ich auch dort TCP/IP als Medium benutzen?
Aber schon mal interessant zu hören, dass ein Indigo-Service
zustandsbehaftet sein kann. Wenn ich mir dafür einen Proxy bauen lasse, dann
zeigt der immer auf dieselbe Instanz im Server. Wie ist da die Lebensdauer der
Serviceinstanz geregelt?
Gut zu hören, dass ich mit Indigo auf COM+ Anwendungen
zugreifen kann - und umgekehrt. Beides bleibt aber verschieden. Auch bei der
von dir beschriebenen Indigo-Fassade vor einer COM+ Applikation. Indigo würde
dann ja nur so eingesetzt wie vielleicht heute mancher Web Service.
Indigo "in" einer COM+ Anwendung gibt es dann aber
eben nicht... Ok. Verstanden.
WAS hört sich wirklich interessant an. Klingt nach
Verallgemeinerung dessen, was heute COM+ dllhost.exe und IIS/ASP.NET oder eine
Console.EXE bieten: In ihnen kann ich Code "aufhängen" (hosten
lassen), der dann über den einen oder anderen Kommunikationskanal aufgerufen
werden kann. Gut, wenn es dafür in Zukunft nur noch einen Host gibt - der dann
aber hoffentlich auch vernünftig zu administrieren ist. Das Deployment gerade
von COM+ Applikation hat deren Verbreitung ja nicht gerade gefördert. Hast du
einen Link, wo man mehr zu WAS erfahren kann?
Deine Klage bzgl. RPC kann ich sehr gut verstehen. RPC ist
verführerisch :-) Ich muss vom Programmiermodell her nichts dazu lernen und
kann trotzdem, quasi magisch, auf entfernte Software zugreifen, als sei sie
lokal. (Entfernt heißt hier "in einem anderen Speicherbereich". Das
kann ein anderer Rechner sein, es reicht aber auch nur eine andere AppDomain.)
In Wirklichkeit kaschiert RPC aber nur, dass unten drunter
die Kommunikation fundamental (!) anders ist: nicht mehr Stack-basiert, sondern
Stream-basiert. Gregor Hohpe hat einige Unterschiede dieser Kommunikationsarten
in einem Blogposting herausgearbeitet (http://www.eaipatterns.com/ramblings/31_techededa.html)
-Die Koordination/Zusammenarbeit von Client (Aufrufer) und
Server (Aufgerufenem) funktionieren anders.
-Was nach dem Anstoß einer Operation im Server passiert,
wird anders geregelt.
-Client und Server haben einen anderen Kontext.
Dazu kommen Latenzzeiten für die Übermittlung von Daten
zwischen Client und Server, möglicher Ausfall von Übertragungsweg oder
notwendiger Infrastruktur (Hardware/Software), Sicherheitsaspekte usw.
RPC ist einfach so, so sehr prinzipiell anders als ein
lokaler Methodenaufruf, dass ich heute fast nicht mehr verstehe, warum
RPC-Kommunikation überhaupt in so hohem Ansehen steht. (Naja, die Antwort
lautet wohl: Bequemlichkeit und Verständlichkeit.)
Ein weiterer Grund dafür, dass RPC nicht als etwas
kategorial anderes angesehen wird/wurde, liegt meiner Meinung nach in einer
fehlenden Systematik der Softwareentwicklungsmodelle. Wenn über Software
geredet wird, dann scheinen die Artefakte, um die es geht, oft auf einer
einzigen bzw. der einzigen Abstraktionsstufe (oder Technologiestufe) zu liegen.
Bei OOP spricht man über Methoden und Klassen und meint, Software würde daraus
gebaut. Bei SOA spricht man über Services und hat Methoden und Klassen nicht im
Blick. Komponentenorientierte Entwicklung dreht sich um Zusammenfassungen von
Klassen - aber interessiert sich eigentlich nur für einen Prozess.
So reden die Vertreter von OOP, CBD (Component Based Design)
und SOA munter aneinander vorbei. Missverständnisse sind unvermeidlich.
Wie könnte es besser laufen? Ich glaube, es würde besser
laufen, wenn allen klar wäre, dass die Artefakte, über die sie sprechen, Teile
eines Kontinuums wären. Sie stehen nicht isoliert in der Gegend herum, sondern
hängen zusammen. Methoden, Klassen, Komponenten und Services usw. bilden
vielmehr eine Hierarchie. Vereinfacht könnte sie so aussehen:
Service
Applikation
Komponente
Klasse
Methode
D.h. Services bestehen aus Applikationen (Prozesse),
Applikationen bestehen aus Komponenten, Komponenten bestehen aus Klassen,
Klassen bestehen aus Methoden.
Innerhalb der Hierarchie findet Kommunikation auf allen
Ebenen statt: Methoden rufen Methoden auf. Klassen benutzen andere Klassen,
Komponenten andere Komponenten. Applikationen rufen andere Applikationen und
Services andere Services.
Und jetzt noch ein Schritt: In dieser Hierarchie gibt es nur
zwei Ebenen, auf denen sozusagen physikalisch wirklich kommuniziert wird:
-Methoden rufen andere Methoden per Stack auf
-Applikationen kommunizieren mit anderen Applikationen per
Stream (d.h. nachrichtenorientiert)
Methoden kommunizieren immer nur direkt miteinander
innerhalb (!) einer Applikation, d.h. einem Prozess bzw. Speicherbereich.
Applikationen kommunizieren über Speicherbereichsgrenzen
hinweg.
Damit sage ich nichts Neues. Neu ist jedoch die Übersicht,
die die Hierarchie der Artefakte hier bietet. Neu ist das Kontinuum, in dem
sich nun OOP, CBD und SOA verorten können.
OOP und CBD befassen sich mit Artefakten und Kommunikation
innerhalb (!) von Applikationen.
SOA befasst sich mit Artefakten und Kommunikation ab (!) der
Applikationsebene in der Hierarchie.
Mit einer so klaren Zuordnung der Artefakte und Denkmodelle
sollte klar sein, dass SOA und das bisherige OOP sich mit ganz
unterschiedlichen Dingen befassen. Und das bedeutet, dass die OOP-Fraktion
nicht versuchen sollte, ihre Denkweise in die SOA-Welt zu übertragen. Schön
wäre es vielleicht... Aber da die Kommunikationsweise bei Übergang von
Komponente zu Applikation prinzipiell wechselt, wäre es kontraproduktiv bzw.
naiv, diesen Bruch nicht zur Kenntnis nehmen und kaschieren zu wollen.
Dadurch, dass die Kommunikation zwischen Applikationen so
explizit ist - d.h. viele Optionen an Medien bietet, viel Infrastruktur
erfordert, nicht in quasi Nullzeit erfolgt -, gibt es einfach viele Schrauben,
an denen gedreht werden kann und "Rädchen im Getriebe", die ausfallen
bzw. von unterschiedlicher Qualität sein können.
Da Indigo eine SOA-Technologie ist, weil sie die
Kommunikation zwischen Applikationen zum Thema hat, finde ich selbst es also
nicht schlimm, wenn sie kein RPC unterstützt. Ich würde sogar sagen: .NET
Remoting und COM+ und Web Services (im Jahr 2000) so einfach bzw.
RPC-orientiert zu gestalten, war ein Fehler, der zu vielen Missverständnissen
geführt hat und noch führt.
Puh... soviel mal als Statement von mir heute :-)
Navigation:
Seite 1 -
Seite 2 -
Seite 3
Feedback:
Sagen Sie uns, wie Ihnen unsere thinktecture-Gespräche gefallen!
Architecture Briefings