Clouds
Home

J2EE Overview

J2EE Servlet 1

J2EE Servlet 2

J2EE JSP

J2EE JDBC

J2EE JNDI LDAP

J2EE RMI

J2EE EJB

J2EE JMS

J2EE XML

J2EE STRUTS

J2EE SERVERS

J2EE Best Practices

J2EE Logging

J2EE Testing

J2EE Deployment

J2EE Development Process

J2EE Overview Interview Questions


What is J2EE? What are J2EE components and services?

J2EE (Java 2 Enterprise Edition) is an environment for developing and deploying enterprise applications. The J2EE platform consists of J2EE components, services, Application Programming Interfaces (APIs) and protocols that provide the functionality for developing multi-tiered and distributed Web based applications.
A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and communicates with other components. The J2EE specification defines the following J2EE components:
Component type Components Packaged as
Applet applets JAR (Java ARchive)
Application client Client side Java codes. JAR (Java ARchive)
Web component JSP, Servlet WAR (Web ARchive)
Enterprise JavaBeans Session beans, Entity beans, Message driven beans JAR (EJB Archive)
Enterprise application WAR, JAR, etc EAR (Enterprise ARchive)
Resource adapters Resource adapters RAR (Resource Adapter ARchive)

So what is the difference between a component and a service?

A component is an application level software unit as shown in the table above. All the J2EE components depend on the container for the system level support like transactions, security, pooling, life cycle management, threading etc. A service is a component that can be used remotely through a remote interface either synchronously or asynchronously (e.g. Web service, messaging system, sockets, RPC etc). A service is a step up from "distributed objects". A service is a function that has a clearly defined service contract (e.g. interface, XML contract) to their consumers or clients, self contained and does not depend on the context or state of other services.

What is a Service Oriented Architecture (SOA)?

SOA is an evolution of the fundamentals governing a component based development. Component based development provides an opportunity for greater code reuse than what is possible with Object Oriented (OO) development. SOA provides even greater code reuse by utilizing OO development, component based development and also by identifying and organizing right services into a hierarchy of composite services. SOA results in loosely coupled application components, in which code is not necessarily tied to a particular database. SOAs are very popular and there is a huge demand exists for development and implementation of SOAs.

What are Web and EJB containers?

Containers (Web & EJB containers) are the interface between a J2EE component and the low level platform specific functionality that supports J2EE components. Before a Web, enterprise bean (EJB), or application client component can be executed, it must be assembled into a J2EE module (jar, war, and/or ear) and deployed into its container.

Why do you need a J2EE server? What services does a J2EE server provide?

A J2EE server provides system level support services such us security, transaction management, JNDI (Java Naming and Directory Interface) lookups, remote access etc. J2EE architecture provides configurable and nonconfigurable services. The configurable service enables the J2EE components within the same J2EE application to behave differently based on where they are deployed. For example the security settings can be different for the same J2EE application in two different production environments. The non-configurable services include enterprise bean (EJB) and servlet life cycle management, resource pooling etc. Server supports various protocols. Protocols are used for access to Internet services. J2EE platform supports HTTP (HyperText Transfer Protocol), TCP/IP (Transmission Control Protocol / Internet Protocol), RMI (Remote Method Invocation), SOAP (Simple Object Access Protocol) and SSL (Secured Socket Layer) protocol.

Explain the J2EE 3-tier or n-tier architecture?

This is a very commonly asked question. Be prepared to draw some diagrams on the board. The J2EE platform is a multi-tiered system. A tier is a logical or functional partitioning of a system. Each tier is assigned a unique responsibility in a 3-tier system. Each tier is logically separated and loosely coupled from each other, and may be distributed.
  • Client tier represents Web browser, a Java or other application, Applet, WAP phone etc. The client tier makes requests to the Web server who will be serving the request by either returning static content if it is present in the Web server or forwards the request to either Servlet or JSP in the application server for either static or dynamic content.
  • Presentation tier encapsulates the presentation logic required to serve clients. A Servlet or JSP in the presentation tier intercepts client requests, manages logons, sessions, accesses the business services, and finally constructs a response, which gets delivered to client.
  • Business tier provides the business services. This tier contains the business logic and the business data. All the business logic is centralized into this tier as opposed to 2-tier systems where the business logic is scattered between the front end and the backend. The benefit of having a centralized business tier is that same business logic can support different types of clients like browser, WAP (Wireless Application Protocol) client, other standalone applications written in Java, C++, C# etc.
  • Integration tier is responsible for communicating with external resources such as databases, legacy systems, ERP systems, messaging systems like MQSeries etc. The components in this tier use JDBC, JMS, J2EE Connector Architecture (JCA) and some proprietary middleware to access the resource tier.
  • Resource tier is the external resource such as a database, ERP system, Mainframe system etc responsible for storing the data. This tier is also known as Data Tier or EIS (Enterprise Information System) Tier.
The advantages of a 3-tiered or n-tiered application: 3-tier or multi-tier architectures force separation among presentation logic, business logic and database logic. Let us look at some of the key benefits:
  • Manageability: Each tier can be monitored, tuned and upgraded independently and different people can have clearly defined responsibilities.
  • Scalability: More hardware can be added and allows clustering (i.e. horizontal scaling).
  • Maintainability: Changes and upgrades can be performed without affecting other components.
  • Availability: Clustering and load balancing can provide availability.
  • Extensibility: Additional features can be easily added.

Explain MVC architecture relating to J2EE ?

This is also a very popular interview question. MVC stands for Model-View-Controller architecture. It divides the functionality of displaying and maintaining of the data to minimize the degree of coupling (i.e. promotes loose coupling) between components. It is often used by applications that need the ability to maintain multiple views like HTML, WML, Swing, XML based Web service etc of the same data. Multiple views and controllers can interface with the same model. Even new types of views and controllers can interface with a model without forcing a change in the model design.
  • A MODEL represents the core business logic and state. A model commonly maps to data in the database and will also contain core business logic.
  • A VIEW renders the contents of a model. A view accesses the data from the model and adds display logic to present the data.
  • A CONTROLLER acts as the glue between a model and a view. A controller translates interactions with the view into actions to be performed by the model. User interactions in a Web application appear as GET and POST HTTP requests. The actions performed by a model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

What is the difference between a Web server and an application server ?

Web Server

  • Supports HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page (static content) or delegates the dynamic response generation to some other program such as CGI scripts or Servlets or JSPs in the application server.
  • Uses various scalability and fault-tolerance techniques

Application Server

  • Exposes business logic and dynamic content to the client through various protocols such as HTTP, TCP/IP, IIOP, JRMP etc. Uses various scalability and fault-tolerance techniques. In addition provides resource pooling, component life cycle management, transaction management, messaging, security etc.
  • Provides services for components like Web container for servlet components and EJB container for EJB components.

What are ear, war and jar files? What are J2EE Deployment Descriptors ?

The ear, war and jar are standard application deployment archive files. Since they are a standard, any application server (at least in theory) will know how to unpack and deploy them. An EAR file is a standard JAR file with an ".ear" extension, named from Enterprise ARchive file. A J2EE application with all of its modules is delivered in EAR file. JAR files cant have other JAR files. But EAR and WAR (Web ARchive) files can have JAR files. An EAR file contains all the JARs and WARs belonging to an application. JAR files contain the EJB classes and WAR files contain the Web components (JSPs, Servlets and static content like HTML, CSS, GIF etc). The J2EE application client's class files are also stored in a JAR file. EARs, JARs, and WARs all contain one or more XMLbased deployment descriptor(s).

Deployment Descriptors

A deployment descriptor is an XML based text file with an ".xml" extension that describes a component's deployment settings. A J2EE application and each of its modules has its own deployment descriptor.
  • application.xml: is a standard J2EE deployment descriptor, which includes the following structural information: EJB jar modules, Web war modules, etc. Also since EJB jar modules are packaged as jars the same way dependency libraries like log4j.jar, MyAppsUtil.jar etc are packaged. The application.xml descriptor will distinguish between these two types of jar files by explicitly specifying the EJB jar modules.
  • ejb-jar.xml: is a standard deployment descriptor for an EJB module.
  • web.xml: is a standard deployment descriptor for a Web module.

Explain J2EE class loaders ?

J2EE application server sample class loader hierarchy is shown below. As per the diagram the J2EE application specific class loaders are children of the "System -classpath" class loader. When the parent class loader is above the "System -classpath" class loader in the hierarchy as shown in the diagram (i.e. bootstrap class loader or extensions class loader) then child class loaders implicitly have visibility to the classes loaded by its parents. When a parent class loader is below a "System -classpath" class loader in the hierarchy then the child class loaders will only have visibility into the classes loaded by its parents only if they are explicitly specified in a manifest file (MANIFEST.MF) of the child class loader.
Every J2EE application or EAR gets its own instance of the application class loader. This class loader is also responsible for loading all the dependency jar files, which are shared by both Web and EJB modules. For example third party libraries like log4j, utility (e.g. MyAppsUtility.jar) and common (e.g. MyAppsCommon.jar) jars etc. Any application specific exception like MyApplicationException thrown by an EJB module should be caught by a Web module. So the exception class MyApplicationException is shared by both Web and EJB modules. The key difference between the EJB and WAR class loader is that all the EJB jars in the application share the same EJB class loader whereas WAR files get their own class loader. This is because the EJBs have inherent relationship between one another (i.e. EJB-EJB communication between EJBs in different applications but hosted on the same JVM) but the Web modules do not. Every WAR file should be able to have its own WEB-INF/lib third party libraries and need to be able to load its own version of converted logon.jsp servlet. So each Web module is isolated in its own class loader.
So if two different Web modules want to use two different versions of the same EJB then we need to have two different ear files. As was discussed in the Q5 in Java section the class loaders use a delegation model where the child class loaders delegate the loading up the hierarchy to their parent before trying to load it itself only if the parent cant load it. But with regards to WAR class loaders, some application servers provide a setting to turn this behavior off (DelegationMode=false). This delegation mode is recommended in the Servlet 2.3 specification.
As a general rule classes should not be deployed higher in the hierarchy than they are supposed to exist. This is because if you move one class up the hierarchy then you will have to move other classes up the hierarchy as well. This is because classes loaded by the parent class loader cant see the classes loaded by its child class loaders (uni-directional bottom-up visibility)

What do the terms internationalization(i18n) and localization(l10n) mean, and how are they related?

Localization (aka l10n, where 10 is the number of letters between the letter l and the letter n in the word localization ) refers to the adaptation of an application or a component to meet the language, cultural and other requirements to a specific locale (i.e. a target market).
Internationalization (aka i18n, where 18 is the number of letters between the letter i and the letter n in the word internationalization) refers to the process of designing a software so that it can be localized to various languages and regions cost-effectively and easily without any engineering changes to the software. A useful website on i18n is http://www.i18nfaq.com.

What are the characteristics of an internalized program ?

  • The same executable can run worldwide without having to recompile for other or new languages.
  • Text messages and GUI component labels are not hard-coded in the program. Instead they are stored outside the source code in ".properties" files and retrieved dynamically based on the locale.
  • Culturally dependent data such as dates and currencies, appear in formats that conform to end user's region and language. (e.g. USA -> mm/dd/yyyy, AUS -> dd/mm/yyyy).

What are the different types of data that vary with region or language ?

Messages, dates, currencies, numbers, measurements, phone numbers, postal addresses, tax calculations, graphics, icons, GUI labels, sounds, colors, online help etc.

What is a Locale?

A Locale has the form of xx_YY (xx - is a two character language code && YY is a two character country code. E.g. en_US (English - United States), en_GB (English - Great Britain), fr_FR (french - France). The java.util.Locale class can be used as follows:

Locale locale1 = new Locale("en", "US");
Locale locale2 = Locale.US;
Locale locale3 = new Locale("en");
Locale locale4 = new Locale("en", "US", "optional"); // to allow the possibility of more than one
// locale per language/country combination.
locale2.getDefault().toString(); // en_US
locale2.getLanguage(); // "en"
locale2.getCountry(); // "US"


Resource bundles can be created using the locale to externalize the locale-specific messages:
Message_en_US.properties
Greetings = Hello
Message_fr_FR.properties
Greetings = Bonjour
These resource bundles reside in classpath and gets read at runtime based on the locale.

Locale currentLoc = new Locale("fr", "FR");
ResourceBundle messages = ResourceBundle.getBundle("Message", currentLoc);
System.out.println(messages.getString("Greetings")); //prints Bonjour


Note: When paired with a locale, the closest matching file will be selected. If no match is found then the default file will be the Message.properties. In J2EE, locale is stored in HTTP session and resource bundles (stored as *.properties files under WEBINF/ classes directory) are loaded from the web.xml deployment descriptor file. Locale specific messages can be accessed via tags (e.g. Struts, JSTL etc).

The java.text package consists of classes and interfaces that are useful for writing internationalized programs. By default they use the default locale, but this can be overridden. E.g. NumbeFormat, DateFormat, DecimalFormat, SimpleDateFormat, MessageFormat, ChoiceFormat, Collator (compare strings according to the customary sorting order for a locale) etc.

DateFormat:

Date now = new Date();
Locale locale = Locale.US;
String s = DateFormat.getDateInstance(DateFormat.SHORT, locale).format(now);


NumberFormat:

NumberFormat usFormat = NumberFormat.getInstance(Locale.US);
String s1 = usFormat.format(1785.85); // s1 ?? 1,785.85
NumberFormat germanyFormat = NumberFormat.getInstance(Locale.GERMANY);
String s2 = germanyFormat.format(1785.85); // s2 ?? 1.785,85


To use default locale:

NumberFormat.getInstance();
NumberFormat.getPercentInstance();
NumberFormat.getCurrencyInstance();


To use specific locale:

NumberFormat.getInstance(Locale.US);
NumberFormat.getCurrencyInstance(myLocale);



Servlet Interview Questions - Part 1 >>>




Home Clouds