CHAPTER V: J2EE

5.1 ENTERPRISE EDITION OVERVIEW

 The Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing
multitier enterprise applications.
 The J2EE platform simplifies enterprise applications by basing them on standardized,
modular components, by providing a complete set of services to those components, and
by handling many details of application behavior automatically, without complex
programming.
 The J2EE platform takes advantage of many features of the Java 2 Platform, Standard
Edition (J2SE), such as "Write Once, Run Anywhere" portability, JDBC API for database
access, CORBA technology for interaction with existing enterprise resources, and a
security model that protects data even in internet applications.
 Building on this base, the Java 2 Platform, Enterprise Edition adds full support for
Enterprise JavaBeans components, Java Servlets API, JavaServer Pages and XML
technology.
 The J2EE standard includes complete specifications and compliance tests to ensure
portability of applications across the wide range of existing enterprise systems capable of
supporting the J2EE platform. In addition, the J2EE specification now ensures Web
services interoperability through support for the WS-I Basic Profile.
 The Java 2 Enterprise Edition (J2EE) provides a standard for developing multitier,
enterprise services.
 J2EE architecture supports component-based development of multi-tier enterprise
applications. A J2EE application system typically includes the following tiers:
 Client tier: In the client tier, Web components, such as Servlets and JavaServer
Pages (JSPs), or standalone Java applications provide a dynamic interface to the
middle tier.
 Middle tier: In the server tier, or middle tier, enterprise beans and Web Services
encapsulate reusable, distributable business logic for the application. These server-tier
components are contained on a J2EE Application Server, which provides the platform
for these components to perform actions and store data.
  Enterprise data tier: In the data tier, the enterprise's data is stored and persisted,
typically in a relational database.

 J2EE applications are comprised of components, containers, and services.

Components are application-level components.
 Web components, such as Servlets and JSPs, provide dynamic responses to requests
from a Web page.
 EJB components contain server-side business logic for enterprise applications.
 Web and EJB component containers host services that support Web and EJB
modules.

5.1.1. Java 2 Enterprise Edition Architecture

 J2EE uses a 4-level model for web development.
 The browser runs on the client displaying HTML and optionally runs JavaScript.
 The middle tier is comprised of two layers: a Presentation Layer and a Business Logic
Layer.
 The data manages persistent data in a database and, where appropriate, legacy data
stores.
 J2EE implements the Presentation Layer with Servlets and, more recently, Java
provides the option to generate webpages with dynamic content using JavaServer
Pages (JSP).
 Servlets/JSP generate webpages with dynamic content (typically originating from the
database).
 They also parse webpages submitted from the client and pass them to Enterprise
JavaBeans for handling. Servlets and JSPs run inside a Web Server.
 J2EE implements the Business Logic layer with Enterprise JavaBeans (EJB).
Enterprise JavaBeans are responsible for logic like validation and calculations as well
as provided data access (e.g. database I/O) for the application. Enterprise JavaBeans
run inside an Application Sever.
 Under J2EE, EJBs access a database through one of two means:
 1. •using a JDBC interface which requires a lower level of coding and/or
2. •using SQLJ which provides a higher level interface to the database
 In addition to these components for web application, J2EE provides for access by non-
web clients to the business logic layer. A standalone Java application (IIOP client) can
access an EJB directly using J2EE’s Remote Method Invocation (RMI) API.

5.1.2 Supporting J2EE APIs

J2EE provides a number of “supporting” APIs. The purpose of most of these APIs is to enable
interaction between the “main” software layers/components in the J2EE architecture.
•Remote Method Interface (RMI)
•Java Naming and Directory Interface (JNDI)
•Java Message Service (JMS)
•Java Transaction API (JTA)
•Java Database Connectivity (JDBC) / SQLJ
•JavaMail /JMC

Remote Method Interface (RMI)

 RMI is an important API used for supporting distributed computing and has been
supported in core Java since version 1.1. RMI allows a Java client application to
communicate with a Java server application by invoking methods on that remote object.
 With RMI, the client gets a reference to a server object and then it can invoke methods on
that object as if it were a local object within the same virtual machine.
 For server objects developed in other languages, you must employ other techniques like
using Java IDL with CORBA or RMI/IIOP to access the server object.

Java Naming and Directory Interface (JNDI)

  JNDI allows Java programs to use name servers and directory servers to look up objects
or data by name. This important feature allows a client object to locate a remote server
object or data.
 JNDI is a generic API that can work with any name or directory servers. Server providers
have been implemented for many common protocols (e.g. NIS, LDAP and NDS) and for
CORBA object registries.
 Of particular interest to users of J2EE, JNDI is used to locate Enterprise JavaBean (EJB)
components on the network.

Java Message Service (JMS)

 JMS is an API for using networked messaging services.

 Data sent in a message is often intended as a sort of event notification (e.g. a Email-
handling process may need to be notified when a request is enqueued).
 Another common use for messaging (thus JMS) is for interfacing with “external”, third
party or legacy applications, typically via a Message Oriented Middleware product like
IBM’s MQ Series (now WebSphere MQ).
 It can be complex/risky to use RPC/RMI to directly invoke remote applications while a
messaging solution can provide a simpler and more reliable interconnection.

5.2 Multi-Tier Architecture

 The J2EE platform uses a multitiered distributed application model.

 Application logic is divided into components according to function, and 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 component belongs. Client-tier components run on the client machine.
 J2EE multi-tiered applications are generally considered to be three-tiered applications
because they are distributed over three different locations
 Client machines
 The J2EE server machine
  The database or legacy machines at the back end

Fig 5.1 Multitiered Applications

 Web-tier components run on the J2EE server.

 Business-tier components run on the J2EE server.
 Enterprise information system (EIS)-tier software runs on the EIS server.

 Although a J2EE application can consist of the three or four tiers shown, J2EE
multitiered applications are generally considered to be three-tiered applications because
they are distributed over three different locations: client machines, the J2EE server
machine, and the database or legacy machines at the back end.
 Three-tiered applications that run in this way extend the standard two-tiered client and
server model by placing a multithreaded application server between the client application
and back-end storage.
 Fig 5.2 J2EE Components

 J2EE applications are made up of components.

 A J2EE component is a self-contained functional software unit that is assembled into a
J2EE application with its related classes and files and that communicates with other
components.
 The J2EE specification defines the following J2EE components:
 Application clients and applets are components that run on the client.
 Java Servlet and JavaServer Pages (JSP) technology components are Web
components that run on the server.
 Enterprise JavaBeans (EJB) components (enterprise beans) are business
components that run on the server.

 J2EE components are written in the Java programming language and are compiled in the
same way as any program in the language.
 The difference between J2EE components and "standard" Java classes is that J2EE
components are assembled into a J2EE application, verified to be well formed and in
compliance with the J2EE specification, and deployed to production, where they are run
and managed by the J2EE server.

5.2.1 J2EE Clients

 A J2EE client can be a Web client or an application client.
Web Clients
 A Web client consists of two parts: dynamic Web pages containing various types of
markup language (HTML, XML, and so on), which are generated by Web components
running in the Web tier, and a Web browser, which renders the pages received from the
server.
 A Web client is sometimes called a thin client.
 Thin clients usually do not do things like query databases, execute complex business
rules, or connect to legacy applications.
 When you use a thin client, heavyweight operations like these are off-loaded to enterprise
beans executing on the J2EE server where they can leverage the security, speed, services,
and reliability of J2EE server-side technologies.

Applets

 A Web page received from the Web tier can include an embedded applet.
 An applet is a small client application written in the Java programming language that
executes in the Java virtual machine installed in the Web browser.
 However, client systems will likely need the Java Plug-in and possibly a security policy
file in order for the applet to successfully execute in the Web browser.

Application Clients

 A J2EE application client runs on a client machine and provides a way for users to handle
tasks that require a richer user interface than can be provided by a markup language.
 It typically has a graphical user interface (GUI) created from Swing or Abstract Window
Toolkit (AWT) APIs, but a command-line interface is certainly possible.
 Application clients directly access enterprise beans running in the business tier. However,
if application requirements warrant it, a J2EE application client can open an HTTP
connection to establish communication with a servlet running in the Web tier.
 5.3 Best Practices in J2ee

A Best Practice is a proven technique for achieving a desired result. It is a repeatable

technique that has been successful in real life situations, and can be broadly applied across
many problems.
Best practices in two major sections:
1. Best practices in theory.
2. Best practices in practice.

5.3.1 Development Life Cycle

The most critical element of any application development philosophy is the methodology
that defines the entire application development cycle. Since methodologies used to make
modern J2EE applications are so diverse, we will not endorse any particular
methodology.Instead, we will define five relatively generic steps that any significant
development method will need to support. The best practices under each can then be
integrated into your development cycle.

Fig 5.3 Development Life Cycle

The above Fig shows the major steps in a development cycle, and the areas in which Best
Practices can be applied for each step.
Development life cycle
Attack risk as early as possible
Design
 Design for change with dynamic domain model
 Use a standard modeling language
 Recycle your resources

Develop
 Use proven design patterns
 Automate the build process
 Integrate often
 Optimize communication costs
Test
 Build test cases first
 Create a testing framework
 Automate testing

Deploy
 Use j2ee standard packaging specification
 Use tools to help in deployment
 Back up your production data and environment

Tune
 Build a performance plan
 Manage memory and plug leaks
 Focus on priorities

Environments
 Do not restrict deployment options at design time
 Create a responsive development environment
5.4 COMPARISON BETWEEN J2EE AND .NET

Both .NET and J2EE target the enormous market for enterprise applications and Web services.
This quick-comparison provides a basic sense of advantages and disadvantages carried by both
frameworks in various areas.

Orientation

J2EE is Java-centric and platform neutral, while .NET is Windows-centric and language-neutral.
This means developers are restricted to Java language in the J2EE and Windows in the .NET
framework.

Difference in Strategies

J2EE is basically a series of standards. One the other hand, .NET is Microsoft's product strategy
based on evolution of its Visual Studio 6.0.

Industry Involvement

Sun has rallied the entire industry behind its J2EE standard, especially the top software vendors
who have adapted the J2EE interface such as BEA, IBM, and Oracle. On the other hand, .NET is
based on Microsoft's sole efforts to grab the Web services market share.

Rapid Application Development

 Both .NET and J2EE offer rapid application deployment features in their own way.
 Some are more powerful in .NET compared with J2EE and vice versa. J2EE offers state
management services to ease up developers on writing code and managing state.
 On the other hand, the real advantage behind ASP.NET is that it is independent of client
device and allows for user interfaces to be rendered to alternative user interfaces without
rewriting code.

Pros and Cons of Single Vendor Solutions

 J2EE offers solutions from multiple vendors with a wide variety of tools, products and
applications.
  This does provide additional and varied functionality but at a cost
 J2EE tools often times are not interoperable due to problems in portability.
 On the other hand, .NET provides a complete solution of tools and services from
Microsoft, but which may lack some of the higher-end features found in J2EE solutions.

Platform Maturity

 Large J2EE vendors such as BEA, Borland, Sybase offer tried and tested solutions to
their large customer base.

 J2EE does have certain aspects that are new and immature such as automatic persistence
provided by EJB, Java Connector Architecture, and Web services support.

 In the case of Microsoft, some of the .NET is based on Windows DNA but most of it is
rewritten as far as the new CLR is concerned.

 Moreover, C# language and Web services support is new and according to many
testers, .NET VB is very different from the earlier VB version.

 Hence, we can say that in the overall sense J2EE is the more mature platform.

The Language Factor

 Java programming language is at the center of J2EE.
 All components such as EJB and servlets that are deployed in J2EE framework are also
written in Java.
 Although JVM byte code is language-neutral, but in practice this byte code can only be
used with Java.
 On the other hand, the .NET framework, based on the new CLR, enables development in
any language that is supported by Microsoft's tools.
 The pro of this multi-language support is that a single .NET component can be written in
several languages.
 As far as the cons is concerned, first you need experts in different languages to fully
develop, debug and maintain a particular application written in multiple languages.
 it requires a significant cost in training and retaining knowledgeable developers.

The Portability Factor

  Since Java Runtime Environment (JRE) is available on any platform -- Win 32, Unix,
Mainframe -- there is no doubt about easy and effective J2EE portability.
 In the .NET case, the portability aspect is not promising since industry analysts are
skeptical of Microsoft's claims regarding Multiple platform support based on the
company's lackluster performance in meeting industry expectations.

Web Services Support

 J2EE enables eBusiness collaboration and Web services through its JAXP (Java API for
XML Parsing).
 .NET does create Web services but due to its beta release it does not earn much
credibility as a realistic deployment platform.
 Moreover, .NET's lack of support for ebXML poses a real problem for its industry-wide
acceptability.

Tools

 Current IDEs for Java development include WebGain's Visual Cafe, IBM's VisualAge for
Java, Borland's JBuilder, etc.
 These tools are not entirely interoperable because they do not originate from a single
vendor.
 On the other hand, Microsoft's Visual Studio .NET has remarkable productivity features
that include Web forms, .NET's GUI component set, and much more.
 The aspect of single-vendor integration, wizards, and other user-friendly features are
highly advantageous for building Web services.

Hardware Costs

Both .NET and J2EE support Win32 platform, a less expensive alternative to Unix and
Mainframe systems. In general, Microsoft's solution has an aggressive price comparative to J2EE
that offers varied price and service levels from high-end to low-end inexpensive solutions.

Performance and Developer Empowerment

J2EE is an ideal platform for educated and knowledgeable developers to leverage the
programming control over lower-level services such as state management and caching. In
comparison, .NET architecture lacks lower-level performance improvement services, blocks
introduction of errors into the system and is thus more suitable for developers who require more
hand-holding.

5.4.1 The Features Of .Net And J2ee

Table 5.1 Comparison of .net and J2ee Features