[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>
>
>Hi
>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
container.
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...
Cheers,
Rafael Teixeira
Brazilian Polymath
Mono, MonoQLE Hacker
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail