[Mono-list] Middleware for mono?

A Rafael D Teixeira rafaelteixeirabr@hotmail.com
Wed, 22 Jan 2003 00:58:24 -0200

>From: "Henrik Andersen" <peter900000@hotmail.com>
>In Windows middleware is a part of the operating system. Will it be 
>possible to use a software like mosix for linux in order to use more than 
>one pc for the middle tier in a 3 tier configuration? The problem is, that 
>this is not a part of the Net, but a part of Windows.

Well it depends on what architecture you build for your application.

You will have that dependence if you wrap your .net objects in COM objects 
and install them inside COM+ (previously MTS). Also if you use Transaction 
support in ASP.NET, I think it uses COM+ instead of the native .NET 
Transaction mechanism.

First you have to ask what of the middleware services your application 
really needs: Transaction support, Load balancing, "transparent" remoting...

Transaction Support: Short term - Use .NET native support, as we will need 
to implement it for mono, but I don't know if it really work with a DTC 
(distributed transaction coordinator).

Long term - We will have to find/write a DTC and make our ADO.NET providers 
and MonoQLE (my project for a MSMQ substitute and companion System.Messaging 
classes) interact with it. Hard part is implementing two-phase commit with 
big guys Oracle and DB2.

Load Balancing: Mid term - We are thinking of a Corba Channel in the 
Remoting infraestructure, what would make it possible to use corba brokers.

If you really need a speedy solution: use remoting, implement a custom 
channel that tunnels through a custom broker.

.NET remoting have the nice feature of being externally configurable, so 
changing channels and destinations is accomplished by just writing tags in 
the config file and restarting the application. This permit scaling out, up 
and in.

"Transparent" remoting - Well, really programming DCOM in VB, really is 
quite like programming inproc COM, but if you compare with Java RMI, .NET 
remoting is a lot simpler. I see the situation quite like a parallel with 
EJB where is almost mandatory a remoting facade for each bean inside the 

Well, still lots of things to do for all of this to work, but I think mono 
will be an stupendous plataform for "big" enterprise solutions, either 
development, deployment AND operation.

Help needed, any volunteers...


Rafael Teixeira
Brazilian Polymath
Mono, MonoQLE Hacker

The new MSN 8: smart spam protection and 2 months FREE*