[Mono-list] .Net App Server
Fri, 19 Jul 2002 02:05:44 +0200
MS has COM+ as App Server, and the System.EnterpriseServices namespace is
just a binding to COM+. So to implement EnterpriseServices we need to
"emulate" COM+ architecture and all the services it provides.
In fact, a "Mono" App Server would not need to use the
System.EnterpriseServices or COM+ architecture, it could be something new.
However, why not? It's already defined, it is not bad, and without the
limitations of COM it would be even better.
Mono will be very useful for building client applications and for light
webs, but without an Application Server it will be useless for building real
enterprise applications (distributed applications, with high scalability and
availability requirements). Something has to be done. My wish list for a
.NET application server would be:
a.. Support for standard component services: transactions, object pooling,
db connection pooling, just-in-time activation, etc.
b.. Support for Message Queuing.
c.. Eeeeeasy to manage, with a nice and colorful management console.
d.. Support for clustering / load balancing
e.. Fast and powerful component deployment system, with support for hot
deployment, distributed deployment and good component version management.
f.. Portable, of course.
A lot of work to do indeed, although I would enjoy working in such a
----- Original Message -----
From: "Miguel de Icaza" <email@example.com>
To: "Rogelio Robles" <firstname.lastname@example.org>
Cc: "Tom Reilly" <email@example.com>; "Dave Bettin"
Sent: Thursday, July 18, 2002 8:54 PM
Subject: RE: [Mono-list] .Net App Server
> > To build an application server you are missing a very
> > important piece which is a similar concept to Java's
> > J2EE spec and API: an Enterprise Java Beans (EJB)
> > container.
> > NET framework has all the building blocks for that,
> > but they didn't build it. Maybe it was too much.
> System.EnterpriseServices namespace:
> Mono-list maillist - Monofirstname.lastname@example.org