Ich habe mich schon öfter gefragt, in welchen Kernpunkten sich Microsoft.NET von J2EE unterscheidet.

Nach einigem Research habe ich folgende Unterscheidungsmerkmale gefunden:
2 herausstechende Merkmale, die für .NET sprechen, sind wohl seine Mehrsprachigkeit, die in J2EE nicht vorhanden ist und
die native Unterstützung für XML, SOAP, UDDI und WSDL, die in J2EE in der gegenwärtigen Version leider fehlen.

weitere Untescheidungsmerkmale sind:

● Das .NET Framework kennt mehrere Sprachvarianten, die alle denselben ausführbaren Code erzeugen (C#,VB,J#), unter J2EE gibt es nur JAVA
● J2EE ist plattformunabhängig, .NET prinzipiell auch, jedoch fehlen noch die entsprechende Implementierungen für alle Plattformen
● J2EE ist vollständig standardisiert, .NET (bisher) nur teilweise.
● J2EE trennt klar zwischen Framework und Betriebssystem, .NET nicht.
● In J2EE ist mit den Enterprise Java Beans ein serverseitiges Komponentenmodell implementiert, dem .NET Framework fehlt dieser Ansatz
● Der Applikationserver in J2EE übernimmt Aufgaben die in.NET vom Betriebssystem ausgeführt werden
● Remoting muss in .NET explizit programmiert werden. Es unterscheidet sich von dem Remoting Model der Enterprise Java Beans mit  derm Ansatz der Location Transparency.
● Das Transaktionshandling wird in.NET vom Betriebssystem übernommen, in J2EE vom Application Server

In vielen Bereichen der SW-Entwicklung stösst man über sehr mächtige Open Source Libraries, die in JAVA implementiert sind.
Ein Beispiel ist die mächtige Volltextsuchengine Lucene. (weiter Infos unter Wikipedia)
Um diese Libraries in .NET nutzen zu können wurde eine virtuelle Maschine für JAVA in .NET entwickelt, die es erlaubt, von .NET aus JAVA-Klassen aufzurufen.
Das Tool nennt sich IKVM.NET.
Neben der Implementierung einer virtuellen Maschine wurden auch die Core Java Klassenbibliotheken in .NET implementiert.

Für Umsteiger aus JAVA in .NET eine erstklassige Hilfe, seine liebgewonnenen Funktionalitäten weiter verwenden zu können.

MASSIVE ART hat die Engine u.a. in Kombination mit Lucene, Apache FOP (PDF Rendering) und .NET im Einsatz.

Ein Problem, dass sich in unserer Entwicklungsabteilung ergeben hat, ist im Web vielfach diskutiert. Jedoch konnte  ich in keinem Forum eine Lösung finden.

Webservices ermöglichen uns auf elegante Weise definierte Schnittstellen mit anderen Applikationen aufzubauen. Innerhalb von .NET Anwendungen funktioniert das auch sehr gut. Mit ein paar Clicks erstellt oder konsumiert man einen .NET Wer-Service.

Leider ist das aber aus JAVA heraus nicht so einfach. Nach längerem Research habe ich jedoch eine Lösung parat. Das Geheimnis ist, dass man einen eigenen Soap Header über die Webservice Methoden setzt.

Ein Beispiel:
<SoapRpcMethod(Action:="http://www.massiveart.com/DoSomething",        RequestNamespace:="http://www.icubus-software.com/DosNamespace",        ResponseNamespace:="http://www.icubus-software.com/DosNamespace"), WebMethod(Description:="This is a sample description.",
MessageName:="myMessageName",
EnableSession:=True)>

Erst nach diesem Header, kann das Webservice auch aus Java aufgerufen werden.