[Mono-list] Re: System.EnterpriseServices
Thu, 27 Feb 2003 19:06:59 +0100
> 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.
"apart" or "a part" ? :-)
> > 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
> > 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?
No need for that. I'm working on a design in which there is an
EnterpriseServices manager running as an OS service, and there is an
EnterpriseServices runtime that runs in the application's domain. The
runtime connects to the manager to get the configuration information needed
to setup the adequate services in the local domain. The manager is a central
repository for configuration info, it hosts components that need to be
accessed, and monitors status of running applications. Just wat COM+ does.