[Mono-list] Re: System.EnterpriseServices

[Joshua Prismon]

>COM, DCOM, XPCOM, SOAP, CORBA, WS, REST, DCOP are communication
protocols
>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
implement
>those services from scratch, or just build bindings to existing
software
>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
of
>all those services. But this may be lot of work (it is like writting a
full
>featured app server), and it is not clear to me whether it should be
part
>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
in
> ApplicationOption.Server, it will pick some other process (inetinfo
for
> example) to run in. Where would be a good place to save the server
> component?

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
running in
> any process should be able to make use of the services provided by
> EnterpriseServices.

So some sort of P2P or WS-Group protocol for discovery and routing?