[Mono-list] Re: System.EnterpriseServices

[Joshua Prismon]

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?