J2EE vs .NET

Discussions

General J2EE: J2EE vs .NET

  1. J2EE vs .NET (1 messages)

    I am really impressed with the level of informed debate over on this thread. However given the date of the discussion (before .NET was released), I wonder if it would be relevant to ask the question again, considering .NET is now more mature?

    Our company is currently considering questions similar to those in the original thread, so I'm looking for input to help us.

    We currently have older apps running under the VB6/COM/MTS model, and are considering our upgrade paths.

    I've done a bit of research, and am a competent Java and C# developer, but have not done any J2EE n-tier or .NET web-services type work, so I'm open to suggestion. Specifically I keep reading that J2EE offers benefits in state-management and persistence. How does this translate to real-world benefits to the programmer on the ground?

    I'm reasonably confident that I understand the platform implications, from MS licensing, and also under J2EE, with free (JBoss), intermediate (Orion), and big-iron (Websphere), options, but am open to comments on that front also.

    If it helps, our environment is financial services, and our high-level requirement is basically a distributed environment allowing querying and maintaining of client accounts. E.g. online balance enquiries, local maintenance apps running against semi-remote databases, etc.

    Threaded Messages (1)

  2. J2EE vs .NET[ Go to top ]

    One thing to be aware of is how you'll deal with remoting. If you're working in a distributed environment (specifically, you're splitting functionality among application servers), then that's a huge consideration. J2EE provides excellent support for this via EJBs. Despite the backlash, session EJBs are still excellent for dealing with remoting issues. A hell of a lot simpler than CORBA. If you're dealing strictly with remote databases, then it's not as much of an issue, but if you will have multiple application servers, then it is and I'd give J2EE the nod.

    .NET support for remoting is a lot better than previous remoting in the MS world. The problem is that they're basically dumping it all when Longhorn comes out. They're working on a new remoting model that replaces the 1.0 and 1.1 .NET remoting. My guess is you won't see it until 2005, and then it may have issues. I'm working for a client using .NET and this is becoming an issue because we have a heavy need for remoting (hardware instrumentation) and are basically going to be left without support.

    On that issue, I'd give J2EE the nod. I'll leave others to fill in the blanks on the rest of the issues.