Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

What is the middle tier in .NET?


I'm new to .NET, coming from a C++ and Java background.  I'm struggling to understand .NET enterprise architecture.  I can't seem to find an explanation in terms that I'm familiar with.

Does .NET have something similar to the J2EE application server for distributed business objects in the middle tier?  This would be a server that runs native .NET objects that are accessed remotely by a .NET client or ASP.NET page.  This server handles state management, object pooling, clustering, failover, etc.   

I assume the communications protocol would be SOAP.

...or is this completely the wrong way to think of how distributed applications are architected in .NET?

I've asked this question before to others, and got pointed to COM+, but I thought COM was the technology that .NET was supposed to be replacing.



Rick Harris
Wednesday, October 16, 2002

COM+ isn't COM, and .NET doesn't replace COM+. The entire System.EnterpriseServices namespace is the .NET view of COM+. Clemens Vasters ( is one of the folks who's dug into this area of .NET.

Mike Gunderloy
Wednesday, October 16, 2002

Unlike the J2EE platform, the .NET container application space is not open to competition. There is really only one vendor, Microsoft (this is not an indictment, only a statement). This is what Windows .NET Server is all about. As such, there is no reference platform or specification like there is with Java.

Building on the COM+ model, there are versions of .NET Server that are intended to provide object brokering, resource pooling, load balancing and fail over, as well as other application services like messaging and security. Basically most of the things we have under J2EE but provided under a single product line rather than as specifications that several vendors conform to and optionally extend.

Unfortunately, .NET seems to be less mature than J2EE when it comes to architectural patterns for enterprise class development. It will be interesting to see what, if anything, Microsoft provides for component based design using .NET and the .NET Servers.

Samuel Ford
Wednesday, October 16, 2002

You can read this to start with Enterprise Services:

A deeper explanation of subject is here:

In my opinion, there are lot of useful services, but little developers' expirience with them.
Good luck.

Mikhail Andronov
Thursday, October 17, 2002

Since I did extensive amounts of J2EE work, I can offer my take on this subject...

Windows Server IS the App server whereas in J2EE, the app server is a running program on top of the OS.

So, Windows/.net provides the connection pooling, logging, management, security, etc. IIS is one component of the app server. As is MSMQ.

The major difference is that .net does not provide anything similar to Entity Beans that I have seen. (To me, that is a good thing)

Session Beans can be duplicated by using either Web Services (SOAP) or remoting (kinda like RMI). This used in conjunction with System.EnterpriseServices (COM+ services) gets you the same results.

From Microsoft about Serviced Components:
"Just-in-time (JIT) activation, synchronization, object pooling, transaction processing, and shared property management are examples of well-known COM+ services that are available for you to use. There are also newer COM+ services, such as loosely coupled events, Queued Components (QC), and role-based security, that you can use to write flexible, Web-based applications."

Thursday, October 17, 2002

Do you not like entity beans? Personally I'd prefer the application server handle the details of mapping data to objects rather than have to build it myself:

I expect MS will eventually implement a good deal of enterprise functionality similiar to J2ee app servers in their IIS, COM+, SQL server, and MSMQ packages.

Ian Stallings
Thursday, October 17, 2002

The problem with entity beans is that O/R mapping has little to do with a lot of the other crud in the entity bean spec such as remoting. You can see this now as Sun is trying to back away from this by enabling local interfaces with entity beans. IMHO, they would have been better off specifying the O/R mapping domain seperately from the remoting aspect of EJB.

Friday, October 18, 2002

O/R mapping is great IF I'm worried about supporting more then one database. The problem is that otherwise, it doesn't buy me much. Unless the database is simple, I find that I need to go in and write my own queries anyway.

For example, the new J2EE spec 1.4, which isn't final yet, just NOW adds support in the EJB query lanuage for count, sum, min max, avg and order by!!

I'm just not sure what it buys me. For a simple app, it's overkill. For a complicated, massive system I'm worried it would only slow me down/get in my way.

My other concern is that you end up creating lightweight container objects anyway to send the data back to the client especially if the client (JSP's) are on another tier.

Monday, October 21, 2002

The "middle tier" technology in .NET is Enterprise Services, formerly called COM+.

The application server for .NET is indeed Windows 2000 Server or Windows .NET Server as Microsoft understands the OS as such as their solution platform offering. That application server platform can be enhanced with products like Application Center 2000, which add component-level load balancing, monitoring tools and software replication for clusters. This is like buying the respective components for your XYZ J2EE app server.

Regarding some comments here:

The core of J2EE, the EJB model, is essentially a clone of the model of the predecessor to COM+: Microsoft Transaction Server. MTS, along with MSMQ, ASP and ADO was on the market well before any of the J2EE specs ever saw light of day. So much for "more mature patterns".

As far as O/R mappings go: Objects are about representing single data entities. Relational databases are about efficiently accessing large sets of data and not necessarily about efficient access to single records.

O/R mappings that act on a primary-key/single object-level are typically way too simplistic and are "abuse" of the RDBMS model. Last time I looked, entity beans unfortunately did that and hence usually are a very bad idea to use in systems where any degree of database normalization plays a role (read: everywhere except in sample code)

Clemens Vasters
Sunday, October 27, 2002

*  Recent Topics

*  Fog Creek Home