Scribd
Upload
62 views3 pages

Feature J2Ee

This document compares the J2EE and .NET platforms across various categories such as supported programming languages, web development technologies, database access methods, and deployment platforms. It outlines key similarities and differences between the two platforms and provides arguments for and against choosing each platform. The document concludes by stating that both platforms allow building web services today but that J2EE has more proven and standardized technologies while .NET has advantages in tools and simpler programming models.

Uploaded by

lifeoffame
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
62 views3 pages

Feature J2Ee

This document compares the J2EE and .NET platforms across various categories such as supported programming languages, web development technologies, database access methods, and deployment platforms. It outlines key similarities and differences between the two platforms and provides arguments for and against choosing each platform. The document concludes by stating that both platforms allow building web services today but that J2EE has more proven and standardized technologies while .NET has advantages in tools and simpler programming models.

Uploaded by

lifeoffame
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 3

Feature

J2EE

.NET

Standard

Product

Middleware Vendors

30+

Microsoft

Interpreter

JRE

CLR

Dynamic Web Pages

JSP

ASP.NET

Middle-Tier
Components

EJB

.NET Managed Components

Database access

JDBC SQL/J

ADO.NET

SOAP, WSDL,
UDDI

Yes

Yes

Implicit middleware
(load-balancing, etc)

Yes

Yes

Type of technology

Microsoft.NET

J2EE

Key differentiators
C# and Java both derive from C and C++. Most significant features
(e.g., garbage collection, hierarchical namespaces) are present in
both. C# borrows some of the component concepts from JavaBeans
(properties/attributes, events, etc.), adds some of its own (like
metadata tags), but incorporates these features into the syntax
differently.

C# programming
language

Java programming
language

Java runs on any platform with a Java VM. C# only runs in


Windows for the foreseeable future.
C# is implicitly tied into the IL common language runtime (see
below), and is run as just-in-time (JIT) compiled bytecodes or
compiled entirely into native code. Java code runs as Java Virtual
Machine (VT) bytecodes that are either interpreted in the VM or JIT
compiled, or can be compiled entirely into native code.

.NET common
components (aka the
".NET Framework
SDK")

Active Server Pages+


(ASP+)

Java core API

High-level .NET components will include support for distributed


access using XML and SOAP (see ADO+ below).

Java ServerPages
(JSP)

ASP+ will use Visual Basic, C#, and possibly other languages for
code snippets. All get compiled into native code through the
common language runtime (as opposed to being interpreted each
time, like ASPs). JSPs use Java code (snippets, or JavaBean
references), compiled into Java bytecodes (either on-demand or
batch-compiled, depending on the JSP implementation).

.NET common language runtime allows code in multiple languages


to use a shared set of components, on Windows. Underlies nearly all
of .NET framework (common components, ASP+, etc.).
IL Common Language
Runtime

Java Virtual
Machine and
CORBA IDL and
ORB

Java's Virtual Machine spec allows Java bytecodes to run on any


platform with a compliant JVM.
CORBA allows code in multiple languages to use a shared set of
objects, on any platform with an ORB available. Not nearly as
tightly integrated into J2EE framework.

Similar web components (e.g., based on JSP) not available in Java


standard platform, some proprietary components available through
Java IDEs, etc.
Win Forms and Web
Forms

Java Swing

ADO+ and SOAPbased Web Services

JDBC, EJB, JMS


and Java XML
Libraries (XML4J,
JAXP)

Win Forms and Web Forms RAD development supported through


the MS Visual Studio IDE - no other IDE support announced at this
writing. Swing support available in many Java IDEs and tools.

ADO+ is built on the premise of XML data interchange (between


remote data objects and layers of multi-tier apps) on top of HTTP
(AKA, SOAP). .NET's web services in general assume SOAP
messaging models. EJB, JDBC, etc. leave the data interchange
protocol at the developer's discretion, and operate on top of either
HTTP, RMI/JRMP or IIOP.

Arguments supporting both platforms


Regardless of which platform you pick, new developers will need to be trained (Java
training for J2EE, OO training for .NET)
You can build web services today using both platforms
Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or
Windows/Win32 hardware for .NET.
Both platforms offer a single-vendor solution.
The scalability of both solutions are theoretically unlimited.
Arguments for .NET and against J2EE

.NET has Microsoft's A-team marketing it


.NET released their web services story before J2EE did, and thus has some mind-share
.NET has a better story for shared context today than J2EE
.NET has an awesome tool story with Visual Studio.NET
.NET has a simpler programming model, enabling rank-and-file developers to be productive
without shooting themselves in the foot
.NET gives you language neutrality when developing new eBusiness applications, whereas
J2EE makes you treat other languages as separate applications
.NET benefits from being strongly interweaved with the underlying operating system
Arguments for J2EE and against .NET
J2EE is being marketed by an entire industry
J2EE is a proven platform, with a few new web services APIs. .NET is a rewrite and
introduces risk as with any first-generation technology
Only J2EE lets you deploy web services today

Existing J2EE code will translate into a J2EE web services system without major rewrites.
Not true for Windows DNA code ported to .NET.
.NET web services are not interoperable with current industry standards. Their BizTalk
framework has proprietary SOAP extensions and does not support ebXML.
J2EE is a more advanced programming model, appropriate for well-trained developers who
want to build more advanced object models and take advantage of performance features
J2EE lets you take advantage of existing hardware you may have
J2EE gives you platform neutrality, including Windows. You also get good (but not free)
portability. This isolates you from heterogeneous deployment environments.
J2EE has a better legacy integration story through the Java Connector Architecture (JCA)
J2EE lets you use any operating system you prefer, such as Windows, UNIX, or mainframe.
Developers can use the environment they are most productive in.
J2EE lets you use Java, which is better than C# due to market-share and maturity. According
to Gartner, there are 2.5 million Java developers. IDC predicts this will grow to 4 million by
2003. 78% universities teach Java, and 50% of universities require Java.
We would not want to use any language other than C# or Java for development of new
mission-critical solutions, such as a hacked object-oriented version of C, VB, or COBOL.
We are finding most ISVs and consulting companies going with J2EE because they cannot
control their customers' target platforms. We believe this application availability will result
in J2EE beginning to dominate more and more as time goes on.

You might also like