Each has garnered the support of industry leaders. For example, J2EE has gained strong support from the Java community (e.g., BEA, IBM, Oracle, Sun, etc.) and .NET spearheads the Web services effort for Microsoft. While development paths may differ, the aforementioned vendors have been strong proponents of Web services and open-standards that include WSDL, ebXML/UDDI and SOAP.
The J2EE Multitiered Model
J2EE multitiered applications are usually considered to be three-tiered applications because they are distributed over three locations (client machine, J2EE server and database server or legacy systems at the back end). It is important to note that although a J2EE application may consist of three tiers (client tier, business tier and EIS tier) or four tiers (client tier, Web tier, business tier and EIS tier), J2EE multitiered applications are generally considered to be three applications. Application logic is divided into components according to function. Accordingly, the various application components that make up a J2EE application are installed on different machines depending on the tier in the multitiered J2EE environment to which the application belongs. The following are the three tiers that comprise the J2EE multitiered model.
Client Machine (Client Tier)
The J2EE client tier is divided into two main categories that include Web-based clients and application clients.
Web-based client (a.k.a thin client) executes in a standard Web browser such as Microsoft Internet Explorer (IE) and Mozilla Firefox. A Web-based client is comprised of two main parts that include: 1) dynamic Web pages containing various types of markup languages (e.g., HTML, XML, etc.) which are generated by Web components (JSPs and servlets) on the Web tier and 2) a Web browser which renders the pages received from the server. Web-based clients typically do not execute complex business rules, query databases and/or connect to legacy systems. Normally, heavyweight operations are offloaded to Enterprise Java Beans (EJBs) executing on the J2EE server where they may leverage the reliability, security and speed of J2EE-server-side technologies.
Biggest Advantage: Available on a majority of client machines (e.g., laptops, PCs, Tablet, etc.).
Biggest Disadvantage: Limited to the capabilities of HTML, JavaScript and other related Web-scripting languages.
Application clients are Java applications that run in a Java virtual machine (JVM), and provide a way for users to handle tasks that require a richer user interface (UI) that can be provided by markup languages. Application clients can directly access EJBs running on the business tier. Alternatively, if required, an application client may also open an HTTP connection to establish communication with a servlet running in the Web tier.
Biggest Advantage: Richer user interface.
Biggest Disadvantage: Must be installed on each client machine.
Web-based and application clients have their own distinct benefits and drawbacks that must be taken into consideration regarding the needs and requirements of the solution being deployed (e.g., CRM, ECMS, ERP, etc.).
While these architectures are usually kept distinct, there is another model that has not been much utilized, but which presents some obvious advantages in a mix of these capabilities, both internal to the enterprise and in its external-facing modalities. These are application-specific runtimes that can be fairly limited additional extension profiles to existing core markup mime typed plug-ins to augment UIs that travel with the application from the Web tier to the Web-based client, where the functionality is optionally added to the client's Web browser for the length of runtime required by the application to take the processing load off the server onto the client or that can be maintained as an addition to the browser's plug-ins.
This model is characterized by specialized viewers that have not found their way into markup standards for Web services as yet, such as Macromedia Flash MX which has added forms management to its feature set along with Adobe SVG Viewer for Lifecycle forms manager. Heretofore, this model has been widely dropped in favor of server-based processing, where the implementation of increased capacity is more predictable and, therefore, more economically feasible than in the client.
However, consider the recent announcement of an Outlook standalone subset available by subscription. This is an attempt by Microsoft to see if such a modularization will fit its evolving software-by-subscription service strategy. If Redmond is looking into this, others will, too. Despite the fact that the aforementioned display technologies are not now modularized to take advantage of this model, it seems likely that, as seen in the Microsoft experiment cited above, the modularization of software-by-subscription or in special-purpose, short-lived extensions that travel with their application, modularization seems inevitable.
The monolithic single-vendor solution model seems doomed in the face of open-source software based on open, public standards. Open-source developers already have their offerings aligned with this modularized model, by default largely since OSS does not lend itself to monolithic, deliberately non-interoperable proprietary systems, and with its availability and the advantages to the business world of eliminating single-vendor locked-in dependence, this prediction of the demise of these unwieldy, bloated leviathans certainly looks like the handwriting on the wall in this arena. Regardless, there is currently an excess amount of processing power going unused on the client side, and load-balancing considerations, as we move into an era of greater processing asset utilization (grids) will increasingly require moving the processing load onto the client, especially if this capacity is kept to small and optionally short-lived profiles. Also, there is a good chance that more modular architectures will find favor in a more mix-and-match set of software functionalities as the post-Y2K IT environment presents the necessity of adapting to a necessarily heterogeneous systems.
