Why J2EE? What is the advantage of J2EE over other web development tools?

Why J2EE? What is the advantage of J2EE over other web development tools?

J2EE over PHP

1.       1.  In memory session handing.
2.      Threading (Java makes this pretty easy).
3.      The ability to add third party libraries to an application without having to compile them into the server or otherwise configure the server to use them.
4.      Strong typing.
5.      A compiler (starts out as a hassle but becomes a real friend when working on large projects).
6.      Javadoc
7.      try/catch blocks (last time I worked with PHP, you could only work with one bad statement using the @ operator.)
8.      The Ubiquity of PHP/Mysql do make them the perfect choice for a really small, low budget projects (2 or 3 page apps that don't need to be maintained for long periods of time) but for anything more, JEE, for me, is much easier to work with and maintain.
9.      PHP is like the Swiss Army knife of web development tools. Small, fast, built specifically for the web, has most everything you need built in, and always there when you need it. I wouldn't want to build a house with a Swiss Army knife though.

J2EE v/s ASP

Both J2EE and the .NET Framework run on top of a runtime engine. The runtime interprets and compiles the code and provides critical services such as memory management. The goals of the two runtimes differ significantly due to the differences in design philosophy.

The Java runtime was engineered for portability between operating systems. Although this is advantageous in situations where portability is required, it limits the performance of the application, because the code can be optimized only for execution and not for a specific operating system or application server. Third-party products are often introduced to provide OS specific optimizations, often at the cost of portability.

The Common Language Runtime (CLR), on the other hand, was engineered for two purposes: optimized performance on the Windows operating system and multiple programming language support. The CLR supports any number of different programming languages through a common type system, and helps isolate an application from changes in the operating system.

Overview of the Platforms

There are many similarities, and several major differences, between the .NET and Struts/J2EE development and execution environments. Figure 1 illustrates how the two environments relate to one another.

Figure 1. ASP.NET and J2EE (with Struts) platform stacks

In the next sections, we will examine the key similarities and differences in each area.

Language and IDE

The key difference in the language and development environment stack is a philosophical one. With J2EE, you are limited to a single language (Java), but may choose from a wide variety of development environments. Each IDE offers a different level of support for the language and Web toolkits. You can, for example, work in a simple text editor with keyword color coding, or a full environment that supports debugging. Naturally, the level of integration between the IDE and the other components (OS, Application Server, and so on) is highly vendor-dependent.

In ASP.NET, you have many choices for development language, but one primary choice for development environment. Although you can develop ASP.NET in a text editor, using the lightweight Web Matrix product, or another third-party editor, the primary development environment is Microsoft Visual Studio® .NET. Visual Studio .NET is a very sophisticated IDE that provides not only for the development of console, wireless, Web, Web service and windows applications, but also serves as the IDE for other Microsoft products, such as Biztalk® Server 2004, Office 2003, and Content Management Server. This makes Visual Studio .NET a highly leveraged environment, ensuring continuous improvement and evolution in the long term. Third-party tool developers can also leverage the IDE and create tools that run within Visual Studio .NET. For example Crystal Reports and Rational XDE have incorporated modules in Visual Studio .NET to accelerate .NET development specifically related to those products. This level of integration makes Visual Studio .NET a very powerful development tool.

Application Servers and Operating Systems

Both J2EE and the .NET Framework rely on one or more servers to host the Web application and provide essential services. These servers, and the runtimes themselves, also rely on the base operating system.

The J2EE framework was designed for platform independence. As such, many vendors have built J2EE application servers that run on a variety of operating systems. Although platform independence is valuable, it also adds significant overhead and complexity. The abstraction layer required to support multiple operating systems (OS) forces restrictions on how many OS features may be accessed. Each vendor may provide a different level of integration, and the performance may vary wildly depending on which application server you choose and which operating system you run it on. Finally, mixing vendors often results in support complexity, as each vendor's upgrade/patch cycle must be monitored, and changes by any vendor must be checked against all of the other products. Although platform independence is a benefit, it does have associated costs.

Unlike J2EE, in which the Application Server is completely independent from the OS, the .NET Application Server is the Microsoft Windows® Operating System (and the services provided by Windows). The .NET Framework was designed to integrate closely with IIS and COM+ to provide reliable application hosting services and native support for Web services standards like XML, SOAP, UDDI and WSDL. This integration provides a significant performance boost to .NET applications, but requires platform monogamy. The level of integration is much tighter than with any J2EE server, and results in more features and faster performance.

Runtimes

Both J2EE and the .NET Framework run on top of a runtime engine. The runtime interprets and compiles the code and provides critical services such as memory management. The goals of the two runtimes differ significantly due to the differences in design philosophy.

The Java runtime was engineered for portability between operating systems. Although this is advantageous in situations where portability is required, it limits the performance of the application, because the code can be optimized only for execution and not for a specific operating system or application server. Third-party products are often introduced to provide OS specific optimizations, often at the cost of portability.

The Common Language Runtime (CLR), on the other hand, was engineered for two purposes: optimized performance on the Windows operating system and multiple programming language support. The CLR supports any number of different programming languages through a common type system, and helps isolate an application from changes in the operating system.

Class Libraries

Struts draws heavily upon both the J2EE and J2SE class libraries, which have approximately 135 packages, divided along a variety of base package groups (java, javax and org). The Struts framework broadens the library set slightly to incorporate functionality through new base classes inherent to the workings of Struts. Although the J2EE and J2SE libraries are fully functional, the continual expansion of the library (the J2EE library has more than doubled since version 1.2) has added complexity and obfuscated functionality that should otherwise be intuitive. For example, deciding when to use org.xml or java.xml for XML access, or when to use java.rmi, javax.rmi ororg.omg.stub.java.rmi for remote method functionality is not always obvious. Although some of the libraries are separated based on versions for compatibility, the ordering does not make much sense and is not intuitive to newcomers.

The .NET Framework provides a rich and extensive base class library (BCL). Classes are organized by functionality namespaces, which are logical groupings that are similar to packages. For example, System.Web.UI contains all of the classes for the user interfaces for the Web. The System.Web.UI.Page class contains the methods and properties needed for an ASP.NET page. The .NET Framework (1.1) BCL contains just over 200 core (System.*)namespaces.

Versioning

One of the major differences between the Java platform and the .NET Framework is that .NET has an inherent and rigidly-enforced versioning scheme that applies to both the .NET Framework and to any application built on the Framework. In Java, the framework version is noted in the documentation and only partially enforced through special "deprecation" tags. Quite often, new Java packages will be created to allow for backward compatibility. Some additional versioning can be employed at the application level, using XML tags in the Web deployment descriptor. However, the versioning system is not rigidly enforced and side-by-side deployment is difficult to control.

In .NET, versioning is much less of a problem because of the way the .NET Framework handles version identification. Because each assembly in the BCL is tagged with a strong name that includes the version number, different versions can run side by side without conflicting. In other words, a new version of .NET does not need to include new namespaces to modify existing classes. Both versions of an assembly can be loaded on the computer, and the CLR will automatically bind an application to the version of the library that it was compiled against. If you want to redirect an application to a newer version, you can use either graphical or command-line tools to configure the redirect. The same system is employed at the application level. That is, any assembly can be signed with a strong name and take advantage of the versioning enforced by the CLR.

Web components

Both J2EE and the .NET Framework offer a rich variety of Web application technologies. In J2EE, you have the choice of Servlets, JavaServer Pages and tag libraries. Many tag library sets have been created to perform browser detection and generate browser specific output. However, browser detection is not currently built into the J2EE framework. The JavaServer Faces specification may provide this functionality in the future.

On the .NET side, Web applications are built using ASP.NET. ASP.NET pages contain Web controls, which are often graphical "drag and drop" components that encapsulate functions such as text boxes, buttons and other form elements. Web controls offer a rich set of functionality, including browser detection and auto-output generation. A developer can also extend any of the existing Web controls, or write a new one, to perform any custom functionality.

Data access

Both the J2EE Framework and the .NET Framework contain data access libraries. Although the core features of each library allow similar direct database access (for example, submit a command and receive results), the extended features and fundamental paradigms are very different.

The core Java JDBC library supports a very traditional approach to database access. The user submits a statement (usually a query or stored procedure call) and may receive results in the form of a result set with a live connection to the database. The database calls and results depend on an open connection at all times. Although several advanced classes support disconnected data sets, the JDBC library was not built for intermittent connection scenarios, which are very common in Web applications. In addition, JDBC does not directly support reading or writing XML data. Although several vendors have created JDBC wrappers for XML-based database access, the core J2EE classes do not support it.

ADO.NET, while able to provide the same abilities as ADO and JDBC, is based on a disconnected paradigm. Data retrieved from databases is placed in an object known as a DataSet, and the connection to the database is closed. Data in the DataSet can then be accessed and manipulated without a live database connection. Once the changes are complete, the DataSet can be synchronized back with the database through ADO.NET as a single instantaneous transaction. This disconnected behavior is extremely advantageous, efficient, and often essential when dealing with distributed environments such as Web applications.

ADO.NET is also engineered to work with XML. Not only can ADO.NET automatically translate any data set into XML, it can also abstract an XML schema based on a data set. These features are particularly useful for Web services and other XML-based data-delivery mechanisms.

Web Framework Parallels

In addressing the challenges of the Internet evolution, both .NET and J2EE created framework components to address common application problems. ASP.NET and Struts expand on these components and contribute more robust Web development mechanisms. This next section contrasts the various framework components, with specific focus on validation, caching, state management, security, configuration, internationalization and tracing/instrumentation.

Validation

Almost every significant application requires some form of validation for user input. Without data validation, the application is open to numerous attacks, and may break easily (for example, the user types "not a number" into a field expecting a numeric value). Validating user input not only prevents common problems, it also increases application security.

Both Struts and ASP.NET provide comprehensive validation structures to evaluate user input and accelerate the implementation of validation logic. However, each framework approaches the problem in a very different way, producing a similar result, but unique solutions and toolsets.

Struts Validator

As of Struts 1.1, the Struts framework has included the Struts Validator. The Validator is a new data form super class that can be configured through an XML file. The XML file contains rules for standard validations, such as data type (for example, integer or string) and string format (such as email address, credit card number). The basic rules can easily be customized and new rules can be added. Every form action which requires validation must inherit from the Struts Validator, and the format rules in the XML must be in the form of regular expressions. When the form is submitted, any invalid values and error messages are returned to the view, which must have custom code written to display the validation error messages.

Adding validation to a Struts form requires rewriting the form class, editing an XML file and writing JSP code to display any validation error messages back to the user. As such, validation is best added during the initial design. Adding validation to an existing application requires changing inheritance trees and may break the application.

ASP.NET validation controls

Configuring validation in ASP.NET can be done by simply dragging and dropping server-side controls onto the page at design time and then setting a few properties on the control. ASP.NET provides out-of-the-box validation controls for checking required fields, comparing values, validating ranges and pattern matching. The pattern-matching control contains an extensive library of standard regular expression checks (such as phone number and email address) and can be configured to use any regular expression. Validation can also be done programmatically, but requires a bit more time to create the right events and invoke the validation controls manually.

Although all of these validation controls are server-side controls (that is, they execute on the server), each control is automatically configured to perform client-side validation as well. Client-side validation allows the user to get immediate feedback on their actions, without submitting the page to the server for processing. In fact, the user cannot post the page back to the server until all errors on the page are fixed. At compile time, ASP.NET automatically generates the necessary JavaScript to do client-side validation (if the browser is Internet Explorer 4.0 or higher—otherwise, validation remains server side). Regardless of whether (or how) client-side validation was performed, server-side validation is also performed once the form is received in order to prevent page-spoofing attacks.

Caching

Web applications frequently use caching to speed up client access times. In Struts, caching content is left up to the developer, or to third-party caching systems such as JCACHE. In other words, the developer has to build a custom caching system or integrate a third-party product into any application. Quite often, a developer will build caching functionality into custom tag libraries. Although some J2EE servers offer native caching features, the Java community has yet to develop a standard caching interface. In the future, the J2EE Tiles functionality will provide a built-in system for page and object level caching.

ASP.NET, however, has numerous built-in caching functions, including object-level caching (storing code objects), input parameter-based caching (storing a dynamic page based on input parameters), and time-based caching (storing content for a specified time). Depending on your needs, you can cache data objects or an entire dynamic page. If your display depends on user input, but the actual display changes infrequently, you can even cache the page based on input parameters from the HTTP Request. In other words, you can cache a product page that depends on the product ID. ASP.NET will automatically cache one page for each input parameter (product) that is requested. Subsequent requests for the same product will pull the cached page rather than regenerate it from scratch. All of the ASP.NET caching mechanisms can be configured declaratively with attributes (that is to say, no coding required). Or you can access the cache programmatically through a simple API. The ASP.NET caching systems offer a wide range of options for improving the user response and decreasing access times for static or semi-static content.

State Management

State management allows a Web application to keep track of both the user and the user's data during multiple Web request/response cycles. State management can be performed either on the client side (for example, with cookies or hidden fields) or on the server (for example, in the Session object). However, both client- and server-side state management require some mechanism to identify the user between requests. This mechanism usually consists of either a cookie or a session ID embedded in the URL.

Server side

Both Struts and ASP.NET rely on similar hosted objects (Session and Application) to maintain state between requests. However, ASP.NET offers three separate mechanisms for storing the session information:

1. In Memory—If you choose this option, state will be stored in memory on the machine which receives the request. While this might be okay for a small application that runs on a single server, it is not an acceptable solution for Web farms, since there is no guarantee that subsequent requests from the same user will be end up on the same server.
2. Session-State Store—To use session state in a Web farm, you can use something called a state store. This state store is set up on one of the members of the Web farm. It is essentially a service that can be called locally or from other members of the Web farm. All members of the Web farm need to be configured to work with this central state store and they store/retrieve their session information from here. Although this is a very efficient way of storing session state, it is not bulletproof. If the machine hosting the state store crashes, all state information is lost, since it is stored in memory only.
3. Database—By far the most robust and reliable way of storing session state is in a database. Visual Studio .NET provides database scripts for setting up the state store in Microsoft SQL™ Server.

Although similar features are offered by some J2EE vendors, these features are not inherent in the J2EE or Struts frameworks.

Client side

On the client side, both Struts and the ASP.NET framework use cookies and hidden fields to maintain state by identifying the user on each request. However, the Struts framework relies entirely on the J2EE Application Server to manage the identity, and each server may behave differently. Any additional state must be manually encoded by the developer as a hidden field or dropped in a custom cookie.

In contrast to J2EE, the ASP.NET framework has a single mechanism to automatically manage client identities through cookies and hidden fields, and exposes this to developers through a simple-to-use programming interface. Cookies are stored in collections, and allow developers to use the usual collection handling syntax. ASP.NET also supports cookieless session state, which can be configured through the application's configuration file, and which uses query strings to persist the session ID between requests.

ASP.NET also offers a unique form of client-side state management in the form of the View State property. View State is a property of each ASP.NET control and can be used to retain the value of the control between round trips to the server. This storage makes retention of user input between multiple requests very simple. Developers need to keep in mind, though, that every control has a view state property, and that its value is populated, whether you need it or not. Because view state is implemented as a hidden field and sent to the client with every request, you need to make sure it is enabled only for fields that really require memory.

Security

Security plays a key role in every stage of an application, from the design, to development, to deployment, and into daily use. Struts does not offer any specific security features, as it relies on the security built into the JSP/Servlet and J2EE frameworks. The J2EE framework does offer basic authentication and authorization services; however the exact implementation is often dependent on the J2EE server. On the other hand, the .NET Framework, and ASP.NET in particular, offer many advanced security features that go above and beyond such simple tasks as authentication and authorization.

Authentication

Out of the box, ASP.NET provides Windows, Microsoft Passport, and Forms authentication. Windows and Passport authentication are performed outside of the ASP.NET runtime and are out of the scope of this paper.

Forms Authentication is a mechanism whereby ASP.NET redirects unauthenticated requests to a login form. When the user-supplied credentials are verified, the user is directed back to the originally-requested page. Subsequent request are automatically authenticated without prompting the user. For simple applications, user credentials can be authenticated against user, role and authorization entries in the ASP.NET application's configuration file. For more complex applications, Forms Authentication is usually extended to use an external credential store (see Extending Forms Authentication).

Authorization

Once the user is authenticated, URL authorization determines whether or not to grant access to the requested resource. URL authorization is entirely configuration-based and uses entries in the application's config file to determine which users/roles have access to what resources. Authorization can easily be extended to a full Role-Based Security model.

Impersonation

Impersonation allows ASP.NET applications to execute with the identity of the user who requested the page. Impersonation pushes authentication and authorization out to IIS, as ASP.NET will just use the token received from IIS whether it is authenticated or not. When impersonating, ASP.NET relies on standard NTFS permissions on files and folders in order to determine whether it should allow or deny access to a particular resource.

Configuration

Both Struts and ASP.NET are highly configurable and have centralized, XML-based configuration files for application settings. Some J2EE application servers also support XML-based server configuration. However, each J2EE vendor has a different mechanism for when and how both the server and application configurations are read. Because J2EE uses so many different configuration files (such as struts-config.xml, web.xml, server config files, and so on), debugging configuration can be very difficult. Also, J2EE applications do not have a common mechanism for reading configuration files. Some objects (such as the ServletContext) have automatic access, whereas others (such as the Struts Controller) require custom code.

ASP.NET, on the other hand, has one XML file for each application, and one XML file for the machine as a whole. Every ASP.NET page has native access to anything stored in the application-level XML file. This simplified configuration structure is much easier to debug and access. In addition, ASP.NET will automatically pick up any changes to a configuration file and apply them on the fly. When the runtime detects a change in a config file, it holds incoming request in a queue while it recycles the ASP.NET worker process and loads the new configuration. No requests are lost, and the process is very quick. Although some J2EE servers work this way, many require a full reboot to pick up configuration changes.

Internationalization

Providing international formatting and language features to any site requires considerable effort. Not only do you have to evaluate each piece of text, you also have to evaluate each piece of displayed data (such as prices and address information), each image, and possibly even the color scheme of the entire application. Fortunately, both Struts and ASP.NET offer frameworks to help you with internationalization efforts.

In Struts, and Java in general, the user's geographical location and language are defined as a locale. The locale is passed to other classes, and used to parse information into the proper format for the user's country. The words, phrases and pictures for that language-location pair are stored in a resource bundle in key value pairs. A key word such as "greeting" could be mapped in US-English locales as "hello world!" or in DK-Danish locales as "goddag verden!" The resource bundle can be either a text file or a Java class, depending on which types of resources are required.

In ASP.NET, and the .NET Framework, a comprehensive description of the user's locale is contained in a culture object. Culture-specific formatting is provided automatically by culture-specific instances of date/time, number and text information classes. To obtain culture-specific resources such as text and images, the runtime uses Resource Managers, which read the resource files and return the appropriate resource based on the current culture.

Resources are held in an XML file during development, but can be compiled into multiple satellite assemblies for optimum performance in production. The default culture is compiled into the main assembly, and there is an additional satellite assembly for each culture.

Tracing and Instrumentation

Tracing provides informative messages about the execution of an application at runtime, facilitating fault diagnosis. Instrumentation, on the other hand, is critical in order to measure and monitor an application's performance by means of performance counters.

Struts offers logging through the Log4J components, and limited tracing through features offered by several application servers. These features are often dependent on the actual application server, and vary wildly between systems. Neither J2EE nor Struts implicitly offer performance counters, runtime tracing, or other built-in instrumentation. The developer is left to either choose third-party products or write their own systems for tracing and instrumentation.

Trace listeners and switches

Using the .NET base class library, ASP.NET offers comprehensive tracing capabilities based on the concept of trace listeners and switches. The Trace and Debug classes provide many overloaded methods to generate traces which are received and processed by trace listeners. The runtime provides several different types of listeners to write trace messages to a file, to an event log, or to the debug window of the IDE. Developers can create their own trace listeners to write trace messages to different destinations, such as queues, databases, and so on. Trace switches allow you to enable, disable or filter tracing, based on the value of the trace switch. Out of the box, the framework provides four trace levels (Error, Warning, Info and Verbose), but allows for the creation of your own trace switch hierarchy. Trace listeners and trace switches are configured through the application's web.config file. Whether or not the debug and trace statements are compiled into a given build is controlled by compiler switches.

Application-level tracing

Another key tracing feature of ASP.NET is its configuration-based, application-level tracing. By simply enabling this feature in the web.config file, ASP.NET collects a large amount of diagnostic information and appends it to the requested page. Information collected includes execution timing, the control tree, session and application state, cookies, headers, forms, query string, server variables, and so on.

Performance counters

ASP.NET also offers a large set of performance counters. These provide detailed metrics about the runtime performance of ASP.NET, with regards to requests, sessions, errors, caching, and so on. In addition to these built-in counters, you can create your own performance counters to report application-specific metrics such as the number of orders received, approved or rejected.

Error diagnosis

On the error diagnosis side, identifying the source of problems in an application has never been easier. In addition to providing developers with the ability to set breakpoints and step through both pages and backend components, when an error occurs, ASP.NET generates detailed error messages, including a complete stack trace. This significantly reduces the time and effort spent finding the source of problems.