Remoting oder ServicedComponents

[Stefan Glock]

Hallo,

beim entwickeln einer verteilten Applikation stellt sich mir nach diversen Artikeln, Infos, DevDays usw. die Frage ob die Implementierung mit Remoting oder den ServicedComponents erfolgen soll. Was ist mit den ganzen Services von COM+ (1.0 und 1.5), gibt es diese auch unter Remoting oder nur mit ServicedComponents.

Macht es Sinn jetzt schon damit anzufangen und Remoting bzw. ServicedComponents zu den Layern einfach dann nachzurüsten wenn mehr Infos vorhanden sind.

Gerade die Singelton Implementierung von Remoting wäre eine gute Funktion für unsere Applikation.

Also über alle Infos und Anregungen dazu wäre ich sehr dankbar.

[Andreas Kosch]

Hallo,

die "alten" COM+ Sachen stehen unter .NET unter dem neuen Namen <i>.NET Enterprise Services</i> (alias <i>.NET Component Services</i>) zur Verfügung. Somit ist COM+ auch mit .NET immer dann noch topaktuell, wenn die eigene Anwendung auf die COM+ Services zurückgreifen will. COM+ spielt seine Vorteile nur dann aus, wenn DCOM für den Übertragungsweg genutzt wird. Falls das nicht geht und man auf RDS oder SOAP ausweichen will, gibt es Abstriche.

Mit <i>.NET Remoting</i> bietet Microsoft den Aufrufweg über TCP/IP und HTTP für .NET-Objekte an. In der Hilfe ist dabei der folgende Satz zu finden: "<i>Remoting: Accesses remote Objects. Serviced Components are also .NET Framework Remoting Components and can take full advantage of the features in .NET Remoting. This includes SOAP message communication.</i>&quot

[Stefan Glock]

Hallo,

also grundsätzlich möchte Ich schon auf einige COM+ Services zurückgreifen. Die Frage ist jetzt nur gibt es diese direkt auch
im .NET Framework bei Remoting oder nur via COM+. Also z.B. Transaktionen?

Da die APP "neu" entwickelt wird und mit Sicherheit 2 Jahre dauert
wäre es schon sehr wichtig für welche der beiden Technologien man sich jetzt entscheidet. Zumal COM+ "noch" nicht alt ist. Jedoch habe ich in der MSDN noch nicht genug wirkliche Infos zu Remoting gefunden :

[Jürgen Beck]

Hallo Stefan,

welche COM+ Services meinst Du denn ganz konkret? Du kannst ja ohne weiteres ja sowohl mit .net als auch mit VC++ bzw. VB6 COM+-Komponenten entwickeln und von .net aus ansteuern. Es gibt da halt nur die bekannten Einschränkungen bspw. in der Vererbung bzw. bei der Übergabe von Parametern bei der Instanziierung.
Wenn Du bspw. also ein vernünftiges Objektpooling und eine Transaktionsunterstützung brauchst, kommst Du ohne COM+ nicht aus. Jedoch lassen sich ohne weiteres COM+-Komponenten von .net aus genauso ansprechen und entwicklen wie aus der "alten Welt".

Jürge

[Stefan Glock]

Hallo,

speziell Transaktionen wären am wichtigsten. Objektpooling und Non-Blockable-Calls nicht ganz so. Demnach sollte ich also Komponenten die Transaktionen benötigen ableiten von ServicedComponents und andere Komponenten (Fetcher etc.) mit Remoting implementieren. Die Frage ist jetzt nur macht es Sinn beide Techniken in einem Projekt zu nutzen oder dann besser nur COM+? Oder aber man hofft darauf das Remoting (wenn es das nicht schon kann) irgendwann auch die wichtigsten Services unterstützt. Wie gesagt finde ich derzeit in der MSDN nirgends eine Information darüber ob bzw. wann Remoting diese Services unterstützt bzw. wie diese Implementiert werden sollten

[Andreas Kosch]

Hallo,

ich würde in jedem Fall das COM+ Objekt direkt in .NET schreiben. Die neuen Fähigkeiten machen sich hier sehr positiv bemerkbar, da die Konfiguration sowohl der COM+ Anwendung als auch des COM+ Objekts über die Attribute direkt im Sourcecode vorgenommen wird. Das folgende Beispiel demonstriert dies:
<pre>
Imports System
Imports System.Reflection
' InteropServices wird für das Attribut ClassInterface benötigt
Imports System.Runtime.InteropServices
Imports System.EnterpriseServices

<Assembly: ApplicationName("OSFirstCOMplusApp")>
<Assembly: ApplicationActivation(ActivationOption.Server)>
<Assembly: ApplicationAccessControl(Value:=False, Authentication:=AuthenticationOption.None)>
<Assembly: AssemblyKeyFile("D:\COM+\NET\OSFirstCOMplus\OSFirs tCOMplusStrongName.snk")>

<ConstructionEnabled([Default]:="Vorgabewert"), _
JustInTimeActivation(True), _
ClassInterface(ClassInterfaceType.AutoDual)> _
Public Class OSFirstCOMplusObject
Inherits ServicedComponent

Dim sCS As String

Public Function DoWork() As String
ContextUtil.SetComplete()
Return sCS & " (DoWork)"
End Function

Public Function DoWorkEx() As String
ContextUtil.SetComplete()
Return sCS & " (DoWorkEx)"
End Function

Public Overrides Sub Construct(ByVal constructString As String)
sCS = constructString
End Sub
End Class
</pre>
Die .NET Enterprise Services wird es auch in Zukunft geben, dass einzige was verschwindet ist das <i>Services Installation Utility</i> (REGSVCS.EXE) und der COM+ Catalog (Reg DB). Irgendwann wird COM+ nur mit .NET gehen.

Das .NET Remoting ist ein ganz anderer Bereich (aus meiner Sicht)

[Stefan Glock]

Hi,

ich hab jetzt noch was gefunden. Da ja die .NET Remoting Objekte eine Host Applikation brauchen, habe ich 3 Möglichkeiten:

1. Eigene Applikation oder Windows Service
2. Im IIAS hosten (nur HTTP Channel)
3. Mit COM+ hosten. (von ServiceComponent ableiten)

Wenn ich das so richtig verstehe, dann heisst das ja, das
ServicedComponents auch die Remoting möglichkeiten haben. Das wäre eigentlich das Optimum. Dann kann ich die RemoteObjekte im COM+ hosten und dort alle Services von COM nutzen. Auf der anderen Seite kann ich die Vorteile auch von Remoting nutzen. Singleton, Leasing, SOAP Übermittlung usw.

Ich werde mich mal weiter noch informieren darüber

[Stefan Glock]

Hallo,

ich hab jetzt in der Release vom VS.NET bei den Online Samples "Fitch & Mather" die Informationen gefunden. In dem Projekt kommt sowohl Remoting als auch ServicedComponents im Zusammenspiel vor. Eigentlich hätte man auch gleich drauf kommen können nachdem die Klasse ServicedComponenets ja auch vom MarshalByRefObj abgeleitet ist:
<br><br>
System.Object<br>
System.MarshalByRefObject<br>
System.ContextBoundObject<br>
System.EnterpriseServices.ServicedComponent<br>

Naja immerhin weiß ich jetzt das sich Remoting und Com+ nicht gegenseitig ausschließen sondern zusammen gehören. :

[Stefan Glock]

Also im Prinzip baue ich jetzt die Business-Layer und DB Zugriffe sofern ich COM+ Funktionen benutze auf ServicedComponents auf. Da ich derzeit nur .NET Clients an das System ranlasse, brauche ich keine Interfaces sondern kann die Klassen direkt in .NET Projekten nutzen. Als Schnittstelle von den Fassadenklassen zu den UserInterfaces werde ich dann wahlweise je nach Aufgabengebiet WebServices, Remoting oder aber COM Schnittstellen implementieren. Soviel zu dem momentanen Stand