What is the comparable technology of EJB (Enterprise Java Beans) in .net?
Answer
Definition of terms is important
When doing comparisons, the definition of terms is important. EJB is a component model. It defines persistence, transaction, remoting, activation and security capabilities (and maybe others) for components that operate within the container.
You can look at comparable technologies in .NET, if that is what you are after - the technical capabilities of the component model.
On the other hand some people use "EJB" as a term to loosely refer to J2EE (or Java EE?). In which case it refers not just to a component model, but to a set of related Java technologies usually associated to server-side applications, including a component model. This might even include toolsets, which of course are only tangentially related to the component model. If that is the comparison, then it is more aptly described as "J2EE vs. .NET".
Still other people might be using an even fuzzier definition for EJB to include things like web services capability, REST/XML communications, or other stuff that is strictly outside Java EE or EJB proper. In other words when they say "compare EJB to .NET" they really mean to compare "Server-side Java platforms to server-side .NET". The latter strikes me as a much more practical comparison to make, than comparing, say, component models.
When doing the comparisons, it's important to be clear about just what is being compared.
EJB - the component model
In EJB you define an object and mark it as a Session Bean or an Entity Bean. There's also the late addition of Message Driven Bean. Three flavors of component in EJB. The Session Bean gets activation - how it gets started and possibly "passivated" in times of high resource contention on the server/container. The SB also gets security and remoting services.
The basic idea is to define an object and then attach attributes to it, either through the deployment descriptor or through in-code attributes, the analog for which is called annotations in Java.
The closest thing to a EJB Session Bean is a .NET object. In any .NET application, you can mark an object with transaction attributes, just like a EJB SB. You can make it remotable, if you like, with .NET Remoting and more attributes. Outside of COM+, there is no passivation technology in .NET; .NET just ignores pooling as a generally interesting thing to do with in-memory objects, and as a result there's no approach to do activation/passivation in .NET as there is with EJB.
sidebar #1: that isn't quite true. In .NET, the Workflow capability provides a facility to have long-running activities that can and will be passivated and re-activated. But, Workflow is a distinct metaphor from "server side objects" or "services" which is the centerpoint of most server-side application architectures that use .NET.
sidebar #2: It used to be that the designers of server-side platforms thought everyone was gonna want to use object pooling in order to be more efficient. Now it turns out that the JVM and .NET CLR are fast enough at creating objects, and memory is plentiful enough, that in general, object pooling is not of practical use. It is no longer interesting for the general case, though it still pays good dividends for expensive objects like database connections.
As with EJB, in .NET you can attach security attributes to an object to allow it to run or not run based on the identity of the caller, or other "evidence".
Entity Beans are a different animal. While persistence and remoting can be combined, in most practical guidebooks, the recommendation is that an entity bean not expose a remote interface. Instead the recommendation calls for a session bean to call an entity bean. So let's just consider EB's as persistent objects.
In .NET there are a bunch of alternatives here. LINQ-to-SQL gives one option - with ORM and persistence services. The ADO.NET Entity Framework is maybe a more comparable technology. Of course all the other services in .NET - transactions security and remoting etc - also can be applied to objects that use ADO.NET Entity Framework or LINQ.
On the other hand, depending on where your emphasis is in the EJB umbrella, there may be better comparables. If you primarily use EJB for remoting - and with the advent of REST, SOAP and other lightweight protocols, almost no one does this anymore as far as I can tell - then a better comparable in .NET is WCF.
Finally, the comparable to EJB MDB are .NET Queued Components.
EJB Remoting
There are some common aspects to all these types of EJBs - like remote interfaces. Actually most architects recommend that you don't distribute your EJBs. In other words, they discourage people from using the remoting aspect that is so commonly discussed. Instead a servlet should invoke an EJB that is local, rather than invoking one on a remote machine. This is Fowler's First Law: Don't distribute your objects.
On the other hand, sometimes you must.
WCF is the communications framework within .NET, and is the aspect in .NET most comparable to EJB remoting. But they are not equivalent. WCF is a very general purpose framework for remote communications, supporting sync and async, multiple protocols, and extensible transport and channel model, while EJB remoting is fairly limited.
Is starting from EJB the right approach?
EJB doesn't say anything (as far as I know) about web services, or REST, or management or lightweight frameworks, or even HTML, or developer tools. Starting a comparison with "EJB vs blank" artificially constrains the discussion a little bit. It frames the discussion in a way that may not be optimal.
There's nothing in EJB to handle, for example, an HTML page metaphor. You get that in servlets or one of its cousins (portlets, etc), some of which are in J2EE proper. But strictly speaking, HTML output isn't covered in EJB.
Now, maybe you intend one of the more expansive definitions of EJB. To that end, J2EE has now added web services into the specification. But even so, I'm not sure how relevant it is to consider the spec, with the variety of add-on Java-based frameworks for SOAP web services and REST.
Likewise, if you want to consider UI capabilities like portlets, servlets, and AJAX and compare them to the .NET equivalents, then you've moved well beyond EJB and J2EE and into server-side Java in general.
It gets back to my earlier point - be clear and precise in your own mind about what you are interested in examining or comparing.
The EJB and J2EE specifications were ambitious - attempting to define the frameworks for server-side applications. But there was always a time lag between what developers were doing, what the spec was saying, and what the vendors were delivering. You know, maybe there was a 1-year lag between the finalization of a new version of the J2EE spec and the release of a compliant server from IBM.
Because of this it ended up being sort of artificial, after-the-fact. The spec was describing things that people were already doing. Things like Spring were coming out and J2EE wasn't saying anything about them. For the longest time J2EE had nothing to say about REST or Web services or AJAX. (Even now, does it say anything about AJAX? I don't know.)
In light of the distance between the theory of the spec and the reality of actual practice by developers, a better approach might be to identify the application requirements, and then compare the appropriateness of EJB and other related technologies to the apps you want to build.
In other words - suppose one of your requirements is that the app will be delivered via the browser, and it will have the responsiveness of AJAX. In that case you're going to have to consider jQuery, and that isn't anywhere covered in J2EE, or EJB. AJAX frameworks are available in various products (both Java and .NET). For example Visual Studio uses jQuery for the ASPNET AJAX stuff. But sticking to the specs sort of misses this stuff.
Bottom Line
The bottom line is, any app that you build with EJBs can be built in .NET, and vice versa.
I think a comparison like "EJB vs .NET" can be interested as an academic discussion, but if you want practical insight into what technology to use where, then you need to think a little differently.
You need to identify and prioritize requirements - like speed of development, cost of deployment, mechanism of deployment, tool support, deployment platform support, language support, performance, UI appearance, UI options, etc. Then weigh the options against that prioritized list.