Technology Excellence  |  General Industry Practice  | Healthcare IT Solutions | Profile | Route Map | Site Map | Contact Us | Search Home Healthcare Apps Solutions Projects Comparison of the Java and .NET platforms This is a comparison of the .NET/Mono and Java/Classpath platforms, excluding their associated programming languages, but including such topics as their history, runtime environments (the Java Runtime Environment and Common Language Runtime), community, development process (Ecma and Java Community Process), politics and licensing issues. The following Contents in this section provide all features of Java and .NET platforms and more. Please fill up the form below and we will submit a proposal for your project. Alternatively, you can send email to contact@optionm.net with the project requirements. Contents Overview Traditional computer applications Runtime inclusion in operating systems ASP.NET & Struts(J2EE): Web Apps Architectures MVC in J2EE and ASP.NET Overview Both platforms and their associated programming APIs were designed carefully. If one has a feature another lacks it is most often the result of a conscious design decision. Usually when different means are employed to address the similar problems, each will have advantages and disadvantages. As such, the reader is advised to avoid the temptation to 'keep score', and instead think about why the designers chose to implement their solution in a given way. Market presence Java is ubiquitous across many disparate operating systems and environments. Numerous Java Virtual Machine (JVM) implementations exist, from both Sun Microsystems and other vendors such as IBM and Apple. In the mobile and embedded space, many companies such as Nokia and Sony have created Java implementation for products like their cell phone and games console range.Sun's 2006 decision to open source Java,. Common Language Runtime (CLR) is also a cross-platform standard. The primary platform is Windows, but implementations do exist for other platforms as well, most notably the Mono Project. .NET also has a growing presence in the mobile space thanks to inclusion in Microsoft's mobile editions of Windows. As yet, support outside of devices running a Microsoft OS is somewhat limited. Java programming language and platform popularity in Open-source projects (measured in number of commits per month, number of lines committed, or number of contributors) is currently much higher than other languages, including C#. License Java While "Java" is a Sun trademark, and only Sun can license the name "Java", numerous free software projects exist that are partially compatible with Sun Java. Most notably, GNU Classpath and GCJ provide a free software class library and a compiler that are partially compatible with the current version of Sun Java. Sun announced in 2006 that all Java source code, excluding closed-source code for which they do not retain rights, will be released under a modified version of the GPL, and then already released two fundamental parts of the JRE and JDK: HotSpot and the javac compiler under the GPL. Following their promise, Sun released the complete source code of the Class library under GPL on May 8, 2007, except some limited parts that were licensed by Sun from 3rd parties who did not want their code to be released under an open-source license. Sun's goal is to replace the parts that remain closed with alternative implementations and make the class library completely open. .NET Microsoft's .NET CLI executable environment, and some of the corresponding class library, have been standardized and can be freely implemented without a license. Several standards-compliant free software environments have been implemented, such as the Mono Project and DotGNU. The Mono Project has also implemented many of Microsoft's non-standard libraries by examining Microsoft materials, similar to GNU Classpath and Java. Microsoft is currently distributing a shared source version of its .NET runtime environment for academic use. The Mono project aims to avoid infringing on any patents or copyrights, and to the extent that they are successful, the project can be safely distributed and used under the GPL. On November 2, 2006, Microsoft and Novell announced a joint agreement whereby Microsoft promised not to sue Novell or its customers for patent infringement.According to a statement on the blog of Mono project leader Miguel de Icaza, this agreement only extends to Mono for Novell developers and users. The Microsoft/Novell agreement was criticized by some in the open source community because it violates the principles of giving equal rights to all users of a particular program In retaliation to the Microsoft/Novell agreement the Free Software Foundation revised its GNU General Public License to close the loophole used by Microsoft and Novell to bypass the GPL's very restrictive provisions on patent deals. The FSF also stated that by selling coupons for Novell's Linux software, the mechanism by which Microsoft circumvented the GNU license, it considers Microsoft to be a Linux vendor, and thereby subject to the full terms and conditions laid out in the GPL.(Microsoft issued the coupons because on the patent deal worked out between the two companies Novell's network patents were considered far more profitable to Microsoft than Microsoft's .NET patents were to Novell.) Community In its proprietorship of Java, Sun works with an open culture, allowing multiple parties, from organizations to individuals, to steer the decision making process. Sun retains exclusive and unlimited legal rights to its Java intellectual properties, and the Java community is subject to those rights. Sun's acceptance of third-party contributions goes to solve the problem of vendor lock-in at the cost of sometimes creating a baffling array of options for beginners wishing to choose a Java-based solution. Java has grown in popularity to become one of the most popular languages of the early 21st century, and the pluralist nature of its development has resulted in many different groups tackling the same (or similar) problems. This issue is particularly acute in the Enterprise space (web/Ajax/Web2.0 applications), where one must not only be familiar with Java, but also the various competing frameworks. While Microsoft has developed C# and .NET without a formal community contribution system, the language and some parts of the executable format and runtime have been standardized and freely distributed through Ecma and the ISO in an open and vendor-neutral process, rather than a process that retains veto and copy rights for Microsoft. However, the standards do not include many new libraries that Microsoft has implemented on top of the standard framework .Numerous C# and CLI community software projects, help and documentation sites, and discussion forums are under active development and maintenance, including those focusing on Windows development with Microsoft .NET or the Mono project, Free software Operating system development under the Mono project, and mobile development using Microsoft's .NET compact framework.. Microsoft is distributing a shared source release (version 1.0) of the .NET virtual machine that can be compiled and used on Windows, FreeBSD, Mac OS X, and other platforms. An updated version (2.0) is currently available, but the only officially supported platform is Windows. A community port to Linux of the 1.0 shared source .NET virtual machine is also available. In March 2003, O'Reilly Media published a book about Microsoft's shared source .NET runtime. Click here to submit your project requirements to Option Matrix, India. Back to top Traditional computer applications Desktop applications Java has sometimes been accused of promising much and delivering little when it comes to desktop applications. Although Java's AWT (Abstract Windowing Toolkit) and Swing libraries are not shy of features, Java has struggled to establish a foothold in the desktop market. Its rigid adherence to the notion of write once, run anywhere makes it difficult to use to the maximum the unique features and modes of working within each individual desktop environment. In the past, desktop applications written in Java have often been accused of looking "alien" on any platform they are run on, although recent versions of Java have started allowing greater use of native widgets. Sun Microsystems has also been slow, in the eyes of some, to promote Java to developers and end users alike in a way which makes it an appealing choice for desktop software. Even technologies such as Java Web Start, which have few parallels within rival languages and platforms, have barely been promoted. The release of Java version 6.0 in December 11, 2006, saw a renewed focus on the desktop market with an extensive set of new tools for closer integration with the desktop. At the 2007 JavaOne conference Sun made further desktop related announcements, including a new language aimed at taking on Adobe Flash (JavaFX), a new lightweight way of downloading the JRE which sees the initial footprint reduced to under 2Mb, and a renewed focus on multimedia libraries. An alternative to AWT and Swing is the Standard Widget Toolkit (SWT), which was originally developed by IBM and now maintained by the Eclipse Foundation. It attempts to achieve improved performance and visualization of Java desktop applications by relying on underlying native libraries where possible. .NET has become increasingly common in open source and free software systems due to its inclusion by the GNOME desktop environment using the Mono framework. Server applications This is probably the arena in which the two platforms are closest to being considered rivals. Java, through its Java EE (aka J2EE, Java(2) Enterprise Edition) platform, and .NET through ASP.NET, compete to create web-based dynamic content and applications. Both platforms are well used and supported in this market, with a bevy of tools and supporting products available for JavaEE and .NET. And both have high profile backers. For example, for Java: Oracle included direct support for Java into its database, while Google has used Java to power tools like Gmail. Some of Sun's current Java-related license agreements for Java EE define aspects of the Java platform as a trade secret, and prohibit the end user from contributing to a third-party Java environment However, while Sun's software is subject to the above license terms, Sun's Java EE API reference has been implemented under an open source license by the JOnAS project. Microsoft's implementation of ASP.NET is not part of the standardized CLI, and while Microsoft's runtime environment and development tools are not subject to comparable secrecy agreements to Java EE, the official Microsoft tools are not open source or free software, and require Windows servers. However, a cross-platform free software ASP.NET 1.1 implementation is part of the Mono project. Embedded applications Mobile applications Java's JavaME (aka J2ME, Java(2) Micro Edition) has a very large base within the mobile phone and PDA markets, with only the cheapest devices now devoid of a KVM (a cut down Java Virtual Machine for use on devices with limited processing power). Java software, including many games, is commonplace. While almost every mobile phone includes a JVM, these features are not always heavily used by users (particularly in North America). Initially Java applications on most phones typically consisted of menuing systems, small games, or systems to download ringtones etc. However, more powerful phones are increasingly being sold with simple applications pre-loaded, such as translation dictionaries, world clock displays (darkness/light, timezones, etc.) and calculators. Some of these are written in Java, although how often phone owners actually use them is probably unknown. In January 2007 Steve Jobs suggested that Apple's iPhone would not support Java.Significantly, at that time Java's mobile platform was perceived as nearly ubiquitous across the cell phone market, commonly being used by software companies to write device-neutral mobile applications. Noted commentators argued against Jobs' stand, but when the iPhone finally appeared it did indeed lack both Java and Adobe's rival Flash technology, favouring instead simple web applications using the phone's Safari browser. In October 2007 Apple bowed to pressure and announced that by early 2008 the iPhone would be opened up to allow development of software other than via the Safari browser. Currently it does not look likely Java or Flash will be directly supported under this plan, although a third party could port JavaME to the iPhone. Leading edge technologies Java has found a market in digital television, where it can be used to provide software which sits alongside programming, or extends the capabilities of a given Set Top Box. TiVo, for example, has a facility called "Home Media Engine", which allows JavaTV software to be transmitted to an appropriate TiVo device to complement programming or provide extra functionality (for example, personalised stock tickers on a business news program.) A variant of Java has been accepted as the official software tool for use on the next generation optical disc technology Blu-ray, via the BD-J interactive platform. This will mean that interactive content, such as menus, games, downloadables, etc. on all Blu-ray optical discs will be created under a variant of the Java platform Rather than using Java, HD DVD (the high definition successor to DVD) uses a technology jointly developed by Microsoft and Disney called HDi that is based on XML, CSS, JavaScript, and other technologies that are comparable to those used by standard web browsers. The BD-J platform is more sophisticated than its iHD rival, with an alleged 8,000 methods and interfaces, as opposed to iHD's 400. And while Microsoft is pushing iHD's XML presentation layer by including it with Windows Vista, iHD is still a newcomer in a market sector where Java technologies are already commonplace. Click here to submit your project requirements to Option Matrix, India. Back to top Runtime inclusion in operating systems .NET/Mono On Windows, Microsoft is promoting .NET as its flagship development platform, by including the .NET runtime in Windows Server 2003 and Windows Vista, and distributing the Visual C# Express development environment at no cost. .NET Framework 3.5 runtime is not pre-installed on versions of Windows prior to Vista SP1, and must be downloaded by the user, which has been criticized because of its large size (65 MB download for .NET 3.5) While neither .NET nor Mono are installed with Mac OS X out-of-the-box, the Mono project can be downloaded and installed separately, for free, for any Mac user who wants to build and/or run C# and .NET software (this excludes most of Windows GUI software though, because required WinForms library is not included, neither is it compatible, with Mono implementation). C# and the CLI are included and used in a number of Linux and BSD based operating systems by way of including the free software Mono Project. As a result of inclusion of .NET or Mono runtimes in the distributions of Windows and Linux, non-GUI applications that utilize the programming interfaces that are common to both .NET and Mono can be developed in C# or any other .NET language and then deployed across many operating systems and processor architectures using a runtime environment that is available as a part of the operating system's installation. Both Microsoft .NET and the Mono project have complete support for the Ecma- and ISO-standardized C# language and .NET runtime, and many of Microsoft's non-standardized .NET programming interfaces have been implemented or are under development in Mono, but each environment includes many components that have not been implemented in the other. Java Starting with XP SP1a, Windows does not ship with a Java runtime environment. However according to a September 2003 press release some OEMs agreed to pre-install the JRE on their desktop and laptop models. Apple's support for Java means it has come pre-installed on all new Apple computers since the launch of Mac OS X. Several Linux maintainers distribute non-free components including Sun Java in official archives that are separated from their main operating system distribution, for example Debian non-free, Ubuntu multiverse, Slackware extra, OpenSuse non-OSS,and Mandriva.The Operating System Distributor License for Java (DLJ) is a Sun initiative to ease distribution issues with operating systems based on OpenSolaris or Linux. Free software operating systems were unable to include any Sun Java Runtime Environment. However, in April 2008, the Fedora 9 and Ubuntu 8.0.4distributions were released with OpenJDK, based completely on free and open source code. OpenJDK doesn't pass all of the compatibility tests in the Java SE 6 JCK yet, because of the remaining encumberences. They however have been reduced to 1%, and OpenJDK can run complex applications such as Netbeans, Eclipse, Glassfish, or JBoss. If Java is not installed on a computer by default, it may be downloaded by the user as a web plugin. The web plugin process has been criticised because of the size of the Java plugin. Unlike other plugins the Java download is a full runtime environment, capable of running not just applets, but full applications and dynamic WebStart apps. Because of this the perceived download footprint is larger than some web plugins. However, compared to Java, other popular browser plugins have larger sizes: Java 6 JRE is 13 MB, but Acrobat Reader is 22 MB, QuickTime 19 MB, Windows Media Player 13 MB, the .NET Framework 3.0 runtime is 54 MB, and the .NET Framework 3.5 runtime is 197 MB. At the JavaOne event in May 2007 Sun announced that the deployment issues with Java would be solved in two major updates during the lifespan of Java 6 (the changes will not be held over to Java 7.) These include: the introduction of a new consumer JRE edition, with an initial 2Mb footprint and the ability to download the remaining 9Mb in sections using an on-demand methodology. the development of drop-in cross platform JavaScript code, which can be used from a web page to install the necessary JRE for a given applet or Rich Internet Application to run, if necessary. an improvement in support for automatically downloading updates to the JRE. support for pre-loading of the JRE, so applets and applications written in Java start up almost instantaneously. Click here to submit your project requirements to Option Matrix, India. Back to top ASP.NET and Struts(J2EE): Web Application Architectures Introduction The last decade has reshaped the way that we do business and access information. Since the emergence of simple information portals in the early nineties, the Internet has rapidly evolved into a major and profitable forum for business and trade. This evolution has spawned two major standards for building enterprise Web applications-Microsoft® ASP.NET (and the Microsoft .NET Framework) and Apache's Struts (along with the J2EE framework). Architects and developers from both the .NET and Java communities are now asking how these two technologies compare in scope, functionality and underlying architecture. In this paper we will provide an overview of the platforms, a rundown of the similarities and differences, and a review of the features that each framework provides to solve common developer problems. We will show how the industry standard patterns implemented in ASP.NET and Struts have helped reduce code complexity and accelerate development times. We will also explore the advantages and disadvantages of each offering, and the utility that they bring to the next generation of development. Brief Evolutionary History of Web Development In the early days of the Web, most business Web sites were simply a form of advertisement, providing user manuals, brochures and catalogues to customers. The dot-com revolution showed businesses that they could also provide online services for their customers. Now, instead of just viewing inventory, customers could also purchase it. This new phase of the evolution created many new requirements. Web sites had to be reliable, available, secure, and, if it was at all possible, fast. These early e-commerce Web sites were often powered by Java-based technologies, including JSPs, EJBs, Servlets, and JDBC; or Microsoft-based technologies, including ASP, VBScript, MTS, ADO, COM and COM+. Although these technologies worked, most of the sites were built quickly without giving much thought to scalability, reliability or security. The Java 2 Enterprise Edition Toward the end of the nineties, the dot-com phenomenon was in full force. However, architects on both sides realized that the natural evolution of Web development would only be achieved through standardization of the mishmash of technologies that were being used. In the spring of 1999, Sun released the J2EE standard, which united the numerous disparate Java technologies under a single banner. This standardization allowed numerous third-party companies to develop tools geared specifically to building J2EE applications, and significantly accelerate the enterprise Web development process. However, even with the advent of the J2EE standard, several key problems remained. Most notably, new and improved Web applications often failed to integrate with back-end ordering, processing and billing systems. Although the front end was well architected and scalable, the system still broke down because the back-end business logic and data persistence often wasn't designed to support the influx of new orders from the Web. The need for more integrated business tools and Web services became apparent. Additionally, another trend was becoming more evident; the larger the scale of the application, the more difficult it was becoming to maintain and extend. The code base for a reliable, scalable application was becoming terribly complex and hard to manage. This background laid the framework for the pattern revolution in J2EE. How could a developer, or architect, design a system that was built on these established technologies, yet avoid the problems with complexity? The origins of ASP.NET During the same time frame, Microsoft decided to pursue a different course, and chose to re-architect the technologies rather than simply regroup them under a different name. Microsoft decided to create a completely integrated environment. The result was the Microsoft .NET Framework, which was a radical shift from earlier application models. To combat code complexity, this new flexible framework naturally incorporated the Model View Controller (MVC) design pattern, and was built around the open standards of the Internet (HTML, XML and SOAP) to support the new paradigm of Web services. During the reengineering process, significant attention was paid to core enterprise requirements such as security, performance, availability, reliability, maintainability, extensibility, and interoperability. The pattern revolution reaches J2EE In the spring of 2000, just around the time that Bill Gates and Steve Ballmer were unveiling .NET, Craig McClanahan began working on the Struts Project in an effort to reduce the code complexity in enterprise-scale Web applications on the Java platform. The Struts extension is an implementation of the Model View Controller (MVC) Pattern, essentially utilizing the Front Controller and Intercepting filter patterns to these ends. We will discuss the differences in MVC implementations later on in this paper. The third age of Web applications At the moment, ASP.NET and Struts have taken the stage to provide powerful solutions to everyday development problems. The enterprise application frameworks that they provide have proven invaluable, and ensure that the development cycle for businesses become shorter and more reliable. While there remain significant differences in both the technology and methodology behind the J2EE and .NET platforms, ASP.NET and Struts make Web development of past days look like pre-industrial labor. 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 or org.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 SQLT 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 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. Framework Patterns Before Struts and ASP.NET, neither the Java nor the Microsoft developer had guidelines for combating application complexity. Many large J2EE and ASP applications are an excellent example of this. Dependencies between the numerous layers of an application made it difficult to change, update or extend. Adding database result caching to an existing J2EE or ASP application would require searching through each page of the application and repeatedly changing every relevant instance of the code to include data caching. Incorporating code in pages also made it difficult to target multiple markets (like client-server or PDA) with the same application, because code would have had to be duplicated and significantly reengineered across these platforms. Many companies began developing their own frameworks to address this problem; but up until the emergence of Struts and .NET, no comprehensive framework was available. This section discusses how Struts and ASP.NET combat application complexity using the MVC pattern, and identifies the unique advantages of each implementation. The MVC Pattern Long before the Web, software architects grappled with the very same user interface problem for console applications. By dissecting the problem, software architects were able to define the Model-View-Controller (MVC) Pattern. The MVC was first commercially implemented in the Smalltalk MVC framework, which was used to standardize Smalltalk-80 user interfaces. The MVC pattern essentially separates an application into three parts: a Model, a View, and a Controller. In the MVC definition, the Model encapsulates all of the available actions and business logic for an application, the View represents the presentation layer of an application, and the Controller represents the mechanism that ensures the appropriate actions are taken when an event occurs. To combat the user interface problem, the MVC pattern has since been adopted, adapted, and incorporated into the J2EE and .NET enterprise application platforms. In the next two sections, we will go over the Struts and ASP.NET implementations of the MVC pattern. Click here to submit your project requirements to Option Matrix, India. Back to top MVC in J2EE and ASP.NET The J2EE MVC: Struts The Struts architecture is essentially derived from a combination of the Front Controller and Intercepting Filter patterns. The Struts framework provides a single controller that governs the application events, while filters catch and process incoming and outgoing events to ensure that each of the MVC components receive exactly the information they need. For example, the Struts Validator is a filter that ensures that the controller receives only validated requests. The Struts framework acts as a façade for Java applications, providing a framework to divide the code of an application into the Model, View and Controller components defined in the MVC pattern. The Struts framework also provides custom tags for communication between these layers, and a centralized controller to manage events and actions. For more details, refer to the Struts MVC implementation section. The ASP.NET MVC: Page Controller ASP.NET implements MVC using the Page Controller pattern. In contrast to the Struts implementation, which allows complete application-level control, the Page Controller pattern applies the controller at the level of individual pages. The ASP.NET runtime intercepts page requests, invokes the requested actions on the model, and determines the correct view to use for the resulting page. The interception and dispatching logic is automated and hidden from developers. ASP.NET divides each page into two parts: a View that contains the various controls, and the code-behind, which contains event handlers for every event that the ASP.NET Controller can raise as it processes the page. Developers don't need to interact with the actual control mechanism; they simply write event handlers to wire up the model and view components. For more details, refer to the ASP.NET MVC Implementation section. Very complex and large applications usually require more flexibility in page-to-page and page-to-process navigation. To provide this flexibility, the ASP.NET controller mechanism can be improved in two different ways: either by centralizing the Page Controller, or by implementing the Front Controller pattern on ASP.NET. Centralizing the Page Controller Developers not familiar with object-oriented programming tend to overlook the power of inheritance and the Page Controller. As applications grow, this can often lead to application complexity problems. However, this need not be the case. Using inheritance, each page can inherit controller and view components from a base page class. Inheritance allows for cascading changes to occur from a centralized point, and reduces code complexity without having to implement a more complex and elaborate controller pattern. However, if you are implementing a large-scale application from scratch, you may want to consider implementing your own Front Controller or investigate the User Interface Process (UIP). Implementing front controller in ASP.NET One alternative to the Page Controller involves creating a single application level controller based on a custom HttpHandler object. The HttpHandler intercepts requests before the ASP.NET page receives them. The controller can then perform similar actions to the Struts controller. A similar approach can be used to provide pre- and post-processing in the form of an Intercepting Filter. Unlike the controller, the filter simply modifies the incoming request or the outgoing response. In .NET, implementing a Front Controller with the Intercepting Filter is fairly straightforward The Controller part of the implementation is usually broken into two parts, a Handler and a Command Processor. The Handler object receives the requests from the Web server, processes them, and selects an appropriate command based on XML parameters stored in the Web.Config file. The Command Processor performs the specific commands required to satisfy the request. When finished, the commands are forwarded through a mechanism so that the appropriate pages can be displayed.