Java Interview Questions

A three-tier architecture is any system which enforces a general separation between the following three parts:
1.    Client Tier or user interface
2.    Middle Tier or business logic
3.    Data Storage Tier
Applied to web applications and distributed programming, the three logical tiers usually correspond to the physical separation between three types of devices or hosts:
1.    Browser or GUI Application
2.    Web Server or Application Server
3.    Database Server (often an RDBMS or Relational Database)
However, inside of the application server, there is a further division of program code into three logical tiers. This is kind of fractal: the part (app server object design) resembles the whole (physical system architecture). In a classic JSP/Servlet system, these objects are usually implemented as:
1.    JSPs or Servlets responsible for creating HTML or WML user interface pages
2.    Servlets or JavaBeans responsible for business logic
3.    Servlets, JavaBeans, or Java classes responsible for data access. These objects usually use JDBC to query the database.
In an EJB system, the three logical tiers are usually implemented somewhat differently:
1.    JSPs, Servlets, or Java client applications responsible for user interface
2.    Session Beans or Entity Beans whose methods implement business logic and business rules
3.    Entity Beans whose fields represent data; these fields are “persisted” (stored and retrieved) either by the EJB server (for container-managed persistence) or by the Entity Beans themselves (for bean-managed persistence)
As you can see, the precise definition of “tiers” can vary widely depending on the particular needs and choices of an application designer. However, they all maintain the general division of client-logic-storage.
If the architecture contains more than three logical tiers — for instance, multiple data feeds, multiple transactional data sources, multiple client applications — then it is typically called an “N-tier” or “Distributed” architecture.

Actually, servlets/JSPs and EJB are complimentary, not competing technologies: Servlets provide support for writing web based applications whereas EJBs provide support for writing transactional objects. In larger web systems that require scalability, servlet and JSP or XML/XSL technologies provide support for the front end (UI, client) code, where EJB provides support for the back end (database connection pooling, declaritive transactions, declaritive security, standardized parameterization…)
The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This is generally considered a Good Thing in non-trivial applications because it allows for internal reuse, allows flexibility by providing a separation of concerns, gives a logical separation for work, and allows the business logic to be tested separately from the UI (among others).
Some of the hings that servlets and JSPs can do that EJBs cannot are:
•    Respond to http/https protocol requests.
•    (With JSP) provide an easy way to format HTML output.
•    Easily associate a web user with session information
Some of the things that EJBs enable you to do that servlets/JSPs do not are:
•    Declaritively manage transactions. In EJB, you merely specify whether a bean’s methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you’ll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple datasources.
•    Declaritively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean. In Servlets/JSPs you must write code to do this. Note, however that the security model in EJB is sufficient for only 90% to 95% of application code - there are always security scenarios that require reference to values of an entity, etc.

•    An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
•    An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.
•    An enterprise Bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
•    An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
•    An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.
•    The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.
•    The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
•    The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
•    The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.
•    The enterprise bean must not attempt to directly read or write a file descriptor.
•    The enterprise bean must not attempt to obtain the security policy information for a particular code source.
•    The enterprise bean must not attempt to load a native library.
•    The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
•    The enterprise bean must not attempt to define a class in a package.
•    The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
•    The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
•    The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject() or EntityContext. getEJBObject() instead.