Se skäl 24 i beslutet om att inleda förfarandet.

Måste älska det här citatet... "Till skillnad från J2EE middleware, .Net gör inte mycket utöver att ansluta information till Windows-skrivbordet. Företag har gått längre än bara ansluta program men nu kräver också programvara som hanterar transaktioner med hög volym och alla typer av kunddata. De måste integrera komplexa affärsprocesser och centralt automatisera hanteringen av IT-miljöer. Dessa är alla områden där Microsoft fortsätter att falla kort. " Huh...Jag kom från en J2EE middleware miljö, är den här killen galen? I min erfarenhet, J2EE är MYCKET svårare att få integrera framgångsrikt med "andra" system (dvs, inte infödda använda JAVA) än .NET - oh, och inte få mig att försöka använda J2EE med CORBA. High Volume argumentet är ett som har funnits under så lång tid och har rapporterats mycket brett - jag har ännu inte sett en jämförelse av .NET kontra J2EE IRL - de flesta av dessa är rent anekdotal och påstås ".NET sophämtning är ineffektiv och inte skala" argument - aldrig sett bevis men som är lite misstänkt ... Det faktum att han är en AS/400 kille (och har därför nästan säkert aldrig händelsen öppnade VS.NET i sitt liv) säger förmodligen en hel del. Det är inte att jag är en .NET fanatiker, jag bara avskyr dessa typer av artikel som har lite grund i faktum ännu presenteras som absolut gospel.

UPPDATERING: Eric Gunnerson kommenterade att han ansåg att några av de kommentarer jag nämnde ovan baserades på en artikel i PC Magazine... Jag tror att det är denna... http://www.pcmag.com/artikel2/0,41494,1218682,00.asp som i sig är mycket intressant - denna kommentar var mycket talande:

"Den .NET vägen erbjuder färre alternativ i att bygga affärslogik och databaskomponenter. Microsoft har ingen officiell ritning för affärsobjekt jämförbara med Enterprise JavaBeans (EJB), men den rekommenderar bästa praxis på webben (www.microsoft.com / resurser / praxis). .NET utvecklare måste utforma sina egna komponentmodeller baserat på dessa metoder, medan en J2EE utvecklare bara behöver köra en guide för att få EjB."

Japp, Jag håller med, Microsoft har INTE gett stora arkitekturresurser - innan det finns några klagomål pekar MS Architecture webbplats - kolla in Sun är det blåser det ur vattnet! I J2EE hade du mycket tydliga mönster som du kunde följa - vill ha en webbapp, titta på MVC mönster - vill företag integration, titta på EjB, ståtlig eller statslös ... .NET har ASP.NET och det har Enterprise Frameworks - vad jag aldrig har känt i .NET är att dessa var "sammanfogade" - och nej, jag tror inte vid denna tidpunkt att Whidbey kommer att ta itu med det heller.

Samplesna på ASP.NET webbplats är verkligen intressant de är ganska lätta webbappar - var är länken till .NET Petshop eller Nile? Jag tror att detta är en baksmälla från ASP dagar när ASP utvecklare sågs som "Web utvecklare" och VB6 / VC6++ utvecklare var "Application Developers" - detta har förts vidare till .NET där ASP.NET utvecklare ses som separat från "Enterprise" utvecklare som använder Interop, Enterprise tjänster etc ...

Åsikter??