Welcome to MSDN Blogs Sign in | Join | Help

Value of the Microsoft platform when compared to J2EE

From time to time, I get the odd ball query of, “tell me why .NET is better than J2EE.”  There’s no singular answer to that question.  One of the things I am emphatically passionate about is the wholeness and completeness of our [Microsoft] platform and its ability for developers, architects and users to get things done better, faster and cheaper than our competition.  What follows below is an excerpt from an e-mail I recently sent in answering the question, “What does .NET bring to the table that is different or better than J2EE?”

We’ve no good single body of work that answers the question the below. Things to consider include:

  • Windows Server as the application platform is far cheaper to acquire than any commercial J2EE implementation; furthermore, many of the customers I find run J2EE servers on top of Windows Server and don’t seem to pay it a second thought that they already own a complete application platform that provides more feature/function than any single J2EE server implementation and out performs that J2EE server implementation
  • Most J2EE implementations are not taking advantage of much more than J2SE functionality delivered via JSPs; again, they’re paying top dollar for something they get out of the box with Windows Server and they’re not using the bulk of what they’re paying extra for any way
  • Hands down, developers who use Visual Studio and the .NET Framework always come to the same conclusion: they are more productive programming with .NET and you’d have to pry the tools from their cold, dead hands
  • Performance, performance, performance … do more with less = less computing hardware to run your production applications = less cost to the organization; also consider the desktop development concerns: I’ve had customers who are unable to load J2EE-based development tools on their desktop because of lack of horsepower (memory, CPU, etc.), yet Visual Studio loads right up without any problem. Translation? Works with what you have

Consider the reach that .NET has … there’s virtually nothing on the face of the planet that we cannot get to with .NET, be it directly or via server products like BizTalk Server 2006.

Consider the value we add to desktop and mobile programming models:

  • Single skill set and the same framework/object model used when building Web applications, Windows desktop applications, Smartphone applications, PocketPC applications
    • Why is this important? Because the same skill set and the same toolset you use to build any one of the above is the same as for building any of the others above

Consider the amazing value-add we are including in the platform moving forward:

  • Windows Communication Foundation – single, unified distributed computing programming model that uses 100% industry standards on the wire to ensure the broadest range of interoperability possible
  • Windows Workflow Foundation – put flow-based, state-based or rules-based workflow directly into your application; use for model-view-controller design patterns, activity sequences, event handlers and more
  • Windows Presentation Foundation – allows you to build amazing desktop applications that take advantage of things like speech, inking, page-style presentation with flow control, etc.

Want justification for moving over to a pure Microsoft model for web-site development and such? Consider this:

  • Microsoft provides SSO out of the box; no need to buy and maintain a separate solution for SSO though every Java customer I’ve talked to has purchased a third-party SSO solution
  • Microsoft provides a federated identity management system built upon SAML for cross-organization authentication and authorization
  • Microsoft supports the operating system, the application platform and the development tools … all under ONE support contract

Consider all the work we do in our server platform and tools:

  • Integrated innovation means our tools are designed to work together, unlike clunky bolt-ons from the J2EE crowd and the “JSR specification of the day.”
  • BizTalk Server 2006 – design and develop your orchestration and integration directly inside Visual Studio
  • Speech Server – extend ASP.NET applications with IVR and call control capabilities directly inside Visual Studio
  • Content Management Server – develop content-managed Web applications that end users can content manage directly within Visual Studio
  • SharePoint Portal Server – develop Web parts for data integration and intra portal communication directly within Visual Studio

Consider Office as the most widely adopted client platform on the face of the planet:

  • Leverage tools like Excel and Word as your presentation tier – taking advantage of all the richness they provide – while building applications within Visual Studio … using the same skill sets that you do to develop Windows, Web and mobile device applications
  • Access enterprise data directly from within Office and present it to users for real-time decision making via Task Panes, access to data via Web services (using Windows Communication Foundation, of course)

One of the last things asked for in the original query was support for JSR-168.  Let me first clarify that, just like JMS, JSR-168 is a Java API.   We don’t do Java APIs (well, there is J# but that’s a discussion for another day.)  So, we [Microsoft] don’t do JSR-168 and we don’t do JMS.  It’s like me asking someone who builds Java applications, “How do you build WinFX applications in Java?  But I do want to point out another huge value-add that you get with .NET Framework 2.0 and specifically, ASP.NET 2.0:

ASP.NET 2.0 provides a complete framework for building portal applications, complete with personalization, dynamic page creation from a gallery of Web parts (i.e., “portlets”) and the ability for those Web parts to communicate seamlessly with each other.  And once again, you get this with the platform!  Take Windows Server 2003 and Visual Web Developer 2005 Express (the latter available for no charge at http://msdn.microsoft.com/vstudio/express/vwd/) and go build what you’re likely to spend thousands and thousands of dollars for in the J2EE world for the same functionality.

Of course, if you truly feel the need to spend capital, consider SharePoint Portal Server as the hosting environment for your Web parts and take advantage of the best collaboration platform (Office and SharePoint) you can buy on the planet.  Go ahead.  I dare you.

Published Friday, January 27, 2006 11:13 AM by kevinha

Comments

# re: Value of the Microsoft platform when compared to J2EE

Friday, January 27, 2006 12:48 PM by David White
JSR168 is a portlet spec for taking portlets from one Java environment to another. My argument is how does JSR168 work if I am using PHP, CGI, or something else not Java? Answer is it doesn't. Talk about lock in. If you are concerned about protecting investment across technology decision, have an investment in J2EE portal based technologies, you want to know about WSRP. With that you can use something like NetUnity to build WSRP compliant components in .Net. Hey, I thought MS was a closed envirnonment?!?!

The fact of the matter is the vendor lock in argument for J2EE sounds like the old arguments for cross platform ANSI C, it is least common denominator.

PS - You MS evangelists guys never change your colors do you?

# re: Value of the Microsoft platform when compared to J2EE

Thursday, June 29, 2006 6:53 AM by jharney
Hi there,
I am always appreciative of .NET, COM/DCOM,DNA,OLE,RPC,DDE. I have to admit and still admire your distributed platform and development tooling.

Right now I face an integration challenge.

I am working with a customer in LA who is having issues with a
.NET web services client. They use the NetworkCredentials object
and perform a SOAP HTTP 1.1 POST with Basic Auth.

In a WebSphere 5.1x deployment it is working, But in a WebSphere 6.x
deployment it is not.

I have isolated a potential suspect to HTTP 1.0 vs HTTP 1.1 protocol
versions. The customer has a .NET client that does an SSL tunnel through a
DMZ via a Microsoft ISA 2000 proxy and then further to an internal WAS 6.0.2 app server.

We have tested 2 scenarios: one without the proxy which works going through both firewalls
and one with the proxy between the firewalls.

What happens is when the POST goes through the ISA 2000 proxy
via SSL tunnel direct to the WebSphere server, we get a 401
back from WebSphere. Apparently when the BA header is set at
the .NET client it gets lost when forwarded to the WebSphere
server. When I look through the logs I see a HTTP protocol version
of HTTP 1.0.

With SSL tunnel we are merely being routed to the appserver.
The proxy is a SSL passthrough.

What happens when we go direct SOAP post to the WebSphere
server without the ISA 2000 proxy we succeed and the HTTP
protocol version is set at HTTP 1.1.

Is there any remedy to have the ISA 2000 SSL tunnel forward the
HTTP 1.1 POST as HTTP 1.1 and handle the HTTP 1.1 protocol
interactions correctly (eg: handle EXPECT:100-continue)?

Are we missing something at the .NET client or the proxy in regard to HTTP 1.1?

Thx for your consideration,
J G Harney
jharney@us.ibm.com
Anonymous comments are disabled
 
Page view tracker