>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? _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
