[Mono-list] Re: System.EnterpriseServices

[Lluis Sanchez]

Hi,

> 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.
>

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.

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.

> 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?

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.

>
> Anyways, Discussion or Ideas?
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>