[Mono-list] Re: System.EnterpriseServices
Wed, 26 Feb 2003 16:42:50 -0700
>COM, DCOM, XPCOM, SOAP, CORBA, WS, REST, DCOP are communication
>and/or component model standards. All this has nothing to do with
>EnterpriseServices. Communication is covered by Remoting, and the CLR
>itself defines the component model. EnterpriseServices is only about
>providing services to .NET objects.
>In MS.NET, those services are provided by COM+. In Mono, we could
>those services from scratch, or just build bindings to existing
>that provide them.
That's actually exactly my point. I just wanted to know if I were going
to get crucified for suggesting that we not re-implement all of COM+
unless we have to ;-)
>IMHO, what would be really interesting is to have a C# implementation
>all those services. But this may be lot of work (it is like writting a
>featured app server), and it is not clear to me whether it should be
>of mono or not.
I do think that our implementation should be 100% (or as close to it as
possible) managed code. The System.EnterpriseServices IMHO _SHOULD_ be
apart of Mono because it makes developers more powerful and is a
(sometime overlooked) part of .NET.
> In addition, the other question is where the ServicedComponets are
> actually run. For ActivationOption.Library, the process can be run
> either in application process or in the SYSTEM process. If you run it
> ApplicationOption.Server, it will pick some other process (inetinfo
> example) to run in. Where would be a good place to save the server
Sorry. Flub on my part. Save==Run
>You should be able to save it wherever you like. There is no need for a
> repository of server objects (other than the GAC). Any component
> any process should be able to make use of the services provided by
So some sort of P2P or WS-Group protocol for discovery and routing?