(D)COM(+)(-Server), OLE, .NET - So viele Begriffe, so wenig Ahnung

[Der schöne Günther]

Disclaimer: Man dürfte mittlerweile in aller Deutlichkeit gemerkt haben, dass ich vielleicht zu vielen Dingen etwas zu sagen, aber von nichts wirklich Ahnung habe. Ich war bislang mit Java und im 3D-Bereich unterwegs und nie wirklich nahe am Betriebssystem.

Von der reinen Windows-Welt und ihren Mitteln der IPC weiß ich daher (noch) nicht allzu viel und habe scheinbar auch eine Menge Spezialitäten der Microsoft-Welt in den letzten zehn Jahren verpasst.


Wie der Titel es schon verrät - Ich suche und suche, und finde nirgends eine wirkliche Antwort, was es mit COM, OLE und .NET überhaupt auf sich hat. Ich kann von niemandem erwarten, mir einfach so ein komplexes Themengebiet näherzubringen. Ich suche aktuelle Artikel und Bücher, in denen ich mit null Wissen ganz vorne anfangen und verstehen kann, worum es hier überhaupt geht.

Die einzigen Artikel über fünf Zeilen die ich gefunden und mir für dieses Wochenende vorgenommen habe sind

• http://www.informit.com/articles/pri....aspx?p=680832
• http://msdn.microsoft.com/de-de/library/ms973850.aspx

Aber auch die beiden sind schon ziemlich alt.

Wo fange ich nun am besten an?

[Bernhard Geyer]

Vergleichen wir es mal mit dem Was Java so bietet bzw. was evtl. Gegenstücke wären

(D)COM = Corba (bzw. heutzutage würde man oft eher WebServices oder REST mit JSON verwenden)
OLE = Custom Controls (Jedoch Programmiersprachenunabhängig)
.NET (Framework/Runtime) = Java Framework/Runtime

[p80286]

Auch wenn es stark verkürzt ist

Zitat:

Automatisierung [Bearbeiten]

Das Steuern von Anwendungen über COM-Schnittstellen wird als Automatisierung bezeichnet. Von dieser Anwendungsmöglichkeit wird häufig im Rahmen von OLE (Object Linking and Embedding) Gebrauch gemacht.

http://de.wikipedia.org/wiki/Component_Object_Model

Gruß
K-H

[Der schöne Günther]

Seit Windows 3.1! :freak:

Großer Gott, was ist da an mir vorübergegangen...


Auch wenn ich noch eine Menge Text vor mir habe, verstehe ich noch nicht wirklich, wie ".NET" da jetzt hineinkommt. Ganz grob glaube ich doch, dass dessen Heilsbotschaft ist, dass das Programm nicht nativ läuft sondern, ähnlich Java, als Bytecode für eine kleine VM vorliegt - Und die ganzen .NET-Editionen von Sprachen alle den gleichen Unterbau verwenden und die IPC so vereinfacht wird?

[p80286]

Die Heilsbotschaft ist eher, das .NET immer vollkommen kompatibel zum aktuellen Windows ist.
Wenn Du so willst, ist es eine vollständige API-Kapselung mit den Zugaben für COM OLE (MS-SQL)DB und und.....

Gruß
K-H

[Medium]

Richtig ist aber dennoch, dass .NET Java nicht unähnlich ist. Programmcode wird in die sog. "IL" (Intermediate Language) kompiliert (~Java Bytecode), und das ist, was in einer .NET-EXE (u.a.) steht. Auf dem Ziel-PC muss zur Ausführung das .NET-Framework installiert sein, welches die IL bei Ausführung in nativen Code über- und ausführt, sowie diverse Schnittstellen des Betriebssystems in geeigneter Form bereit hält. Der JVM also recht ähnlich. COM kommt hier insofern mit ins Spiel, als dass vieles im .NET Framework auf COM-Techniken basiert. Die beiden sind aber mitnichten verheiratet!

Was .NET so nett macht ist, dass es zum einen verspricht, die IL für die jeweilige Plattform optimiert zu kompilieren, auf der man es gerade ausführen will, vor allem aber auch die weitestgehend objekt-orientierte Kapselung der WinAPI. Und dazu noch ein (bzw. zwei) hübsche GUI Frameworks. (Winforms und WPF.) Zudem ist im .NET Framework einiges an Helfern und Dingen, die man so im Programmieralltag braucht bereits als fertige Lib enthalten, wofür man in vielen anderen Umgebungen erst 3rd-Party Code suchen müsste. Es ist alles in allem wohl vor allem ein deutlich weicheres Kissen als die nackte WinAPI, und zwar "ab Werk".

OLE ist ein Subsystem, dass es ermöglicht "Komponenten" Betriebssystemweit zu teilen. Quasi ein TButton, der sich via OLE in C, C++, C#, Delphi, etc. einsetzen ließe, und für alle Sprachen die selbe Codebasis und die selben Binaries hat. Windows regelt das Zusammenspiel zwischen deren Interface und der benutzenden Applikation. Ein Stichwort zu OLE wäre auch noch ActiveX, welches auf OLE basiert. (Die meisten OLE-Controls sind jedoch weit komplexer als ein Button, und teils gar ganze Programme in eigenen Prozessen, die via OLE programmgesteuert nutzbar werden - z.B. die Office Programme.)

[Phoenix]

Zitat:

Zitat von Medium (Beitrag 1214067)

Was .NET so nett macht ist, dass es zum einen verspricht, die IL für die jeweilige Plattform optimiert zu kompilieren, auf der man es gerade ausführen will, vor allem aber auch die weitestgehend objekt-orientierte Kapselung der WinAPI. Und dazu noch ein (bzw. zwei) hübsche GUI Frameworks. (Winforms und WPF.) Zudem ist im .NET Framework einiges an Helfern und Dingen, die man so im Programmieralltag braucht bereits als fertige Lib enthalten, wofür man in vielen anderen Umgebungen erst 3rd-Party Code suchen müsste. Es ist alles in allem wohl vor allem ein deutlich weicheres Kissen als die nackte WinAPI, und zwar "ab Werk".

Das trifft es ziemlich gut, lässt aber ein bisschen den 'Enterprise'-Teil von .NET aussen vor.
.NET bietet von Haus aus mit dem Entity Framework einen umfassenden OR-Mapper, hat für Kommunikation (insb. auch mit WebServices, aber auch alles andere) alles dabei (WCF), kann out of the Box aus verteilte Transaktionen, hat eine umfassende Konfigurations-API, umfassende Logging-API's, sehr gute Diagnostics-Schnittstellen um rauszufinden was alles in der Anwendung so abgeht etc.

Das macht .NET insbesondere für Backend-Infrastruktur geeignet (so wie auch Java gerne auf Servern eingesetzt wird). Und natürlich gibt es im Bereich Webentwicklung mit ASP.NET einen umfassenden Stack der mit Webforms und ASP.NET MVC auch zwei umfassende GUI-Konzepte mitbringt und mit Web API zur Bereitstellung von Webservices (neben WCF) auch gut gerüstet ist. Letztlich ist .NET an sich inzwischen so groß, das man als einziger Entwickler gar nicht mehr alles im Blick haben kann.

Gegenüber Java, wo gar nicht so viel direkt im JDK enthalten ist sondern man für einzelne Aufgaben immer wieder auf andere Produkte/Bibliotheken zurückgreifen muss, sehe ich hier aber einen riesen Vorteil: Die Java-Bibliotheken sind alle sehr... sagen wir mal heterogen. Die einen Funktionieren so, die anderen ganz anders. manche nutzen diesen DI-Container, andere einen anderen. Das macht das zusammenführen von verschiedenen Teillösungen zu einem Gesamtprodukt immer etwas schwierig, weil man viele Komponenten gar nicht so einfach verbinden kann ohne viel 'glue code' zu schreiben. Die Grundlegende Architektur von .NET und die ganzen Bibliotheken aus einer Hand sorgen dafür, das man sich nicht immer in neue Konzepte einarbeiten muss (das muss man einmal am anfang), aber dann funktionieren alle Bibliotheken irgendwie immer sehr ähnlich und lassen sich sehr schnell nutzen ohne viel 'verkleben' zu müssen. Das gefällt mir an dem ganzen .NET-Umfeld deutlich besser als bei Java.

[Der schöne Günther]

Vielen Dank für die Antworten, besonders das Konzept hinter .NET sehe ich jetzt um einiges klarer! Dass es sich mittlerweile wohl auch für Backend im großen Stil eignet wusste ich garnicht.

Auch hatte ich bislang den Eindruck, dass .NET und (D)COM auf Gedeih und Verderb miteinander verzettelt und im Endeffekt zwei Seiten der selben Münze sind. Wenn ich jetzt alles richtig verstanden habe, ist das ja an sich überhaupt nicht der Fall.

[mjustin]

Zitat:

Zitat von Phoenix (Beitrag 1214078)

Die Java-Bibliotheken sind alle sehr... sagen wir mal heterogen. Die einen Funktionieren so, die anderen ganz anders ... Die Grundlegende Architektur von .NET und die ganzen Bibliotheken aus einer Hand sorgen dafür, das man sich nicht immer in neue Konzepte einarbeiten muss (...) Das gefällt mir an dem ganzen .NET-Umfeld deutlich besser als bei Java.

Anstatt alles fix und fertig vom Hersteller zu erhalten, wird im Java Bereich die Standardisierung der APIs und Architekturen für Enterpriseentwicklung in den Vordergrund gestellt. Kleinere und größere Softwareunternehmen können dann diese Baupläne nutzen und ihre eigene Implementierung des Standards erstellen. Das kann sowohl als Open Source als auch in kommerzieller Form stattfinden.

Durch die aufeinander abgestimmten APIs lassen sich aus diesen dann größere Produkte entwickeln wie Web Application Container (Apache Tomcat) oder Enterprise Application Server (GlassFish, JBoss, WebSphere, WebLogic etc.). Als Entwickler profitiert man von diesen Standards, da man nur noch wenige zentrale Spezifikation (je nach Aufgabenschwerpunkt JDBC, JPA, JMS, JavaServer Faces ...) kennen muss. Man findet daher sehr gute Tutorials, und kann wegen der meist auch offiziell zertifizierten Implementierungen eine Anwendung die aus Kostengründen für einen Open Source Servlet Container A erstellt wurde, auf einem kommerziellen Application Server (WebSphere, JBoss EAP) problemlos installieren und laufen lassen.

Man hat also eine Basis-API, und die Hersteller liefern sich einen Wettlauf um weitere Features wie Performance, Wartungsfreundlichkeit, Schnittstellen etc. um sich zu behaupten. Ich weiss nicht ob es zu Microsoft und ihrem Application Server "IIS" kompatible Alternativen gibt, tippe aber auf nein ...