Tim Coleman Wrote: >I don't have much of an opinion on this one. I would say go for it. >When I created the namespace, it was mostly just to create some stubs >so that others could come along after. I like stubbing, as it's a nice >way to take a breather between heavy development. :-)
>I'm sure the mono community would really appreciate some assistance >in this area. Well, I was planning on waiting a little bit (finishing up a oft delayed remoting provider) before posting anything to the mono list, but I might as well get the discussion started. These are just ideas, and I am posting them not because I committed to these ideas, but because I want feedback. There are a few different hurdles that need to be overcome before we can implement System.EnterpriseServices. A few of them require overall policy direction; a few of them involve more specific functionality. System.EnterpriseServices has two different but related pieces of functionality. The first is integration with existing COM+ services. The second is an API extension to some often used services. The key component to System.EnterpriseServices is ServicedComponent. Thru serviced component the following component based services are available: - Transactions (local, distributed and BYOT) - JIT activation - Loosly coupled events - Object Pooling - Queued Components - Role Based Security - Synchronization to all of the above. - Activation in different places. - Simple distributed events(publish/subscribe) The trade offs for this functionality are as follows: - Generally slower then remoting (faster then Web Services). - Uses DCOM and RPC rather then interoperable protocols. System.EnterpriseServices is often thought of as just integration with COM+ services. IMHO, this is an incorrect approach to take. COM+ just happens to be the synchronization and communication system used for Microsoft's implementation. This makes sense because Microsoft already had these services written and a large pre-existing code base of outside applications. IF we are going to implement all of the functionality listed above, IMHO, it does not make sense to re-invent the entire wheel and write it in COM+ when we could write it to have the same syntax and semantics, be interoperable, and not get tripped up with all the COMisms that made Microsoft abandon COM for .NET in the first place. For the Mono implementation of System.EnterpriseServices we might want to focus more on System.EnterpriseServices on top of Remoting, SOAP or even REST like behavior. If we are careful to come up with a generic enough design, we should be able to "plug in" extra behavior and protocols (for example DCOM, XPCOM (is there such a thing as DXPCOM?), CORBA etc. If we don't mind trading performance for interoperability, then SOAP plus the WS standards might be the best way to go. I think that System.EnterpriseServices might be the proper place to integrate in GNOME's GOAD and CORBA stuff as well as KDE's DCOP. 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? Anyways, Discussion or Ideas? _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
