Java_J2EE_Job_Interview_Companion

since it is a bit more involved than Scrum. You could become agile by introducing Scrum first from Waterfall and then add XP practices one at a time. You could also say that you like the “agile” methodology due to its iterative nature as opposed to the big bang approach in “waterfall” and it promotes a more collaborative approach compared to the waterfall methodology.

Enterprise – Key Points

J2EE is a 3-tier (or n-tier) system. Each tier is logically separated and loosely coupled from each other, and may be distributed.

J2EE applications are developed using MVC architecture, which divides the functionality of displaying and maintaining of the data to minimize the degree of coupling between enterprise components.

J2EE modules are deployed as ear, war and jar files, which are standard application deployment archive files.

HTTP is a stateless protocol and state can be maintained between client requests using HttpSession, URL rewriting, hidden fields and cookies. HttpSession is the recommended approach.

Servlets and JSPs are by default multi-threaded, and care should be taken in declaring instance variables and accessing shared resources. It is possible to have a single threaded model of a servlet or a JSP but this can adversely affect performance.

Clustering promotes high availability and scalability. The considerations for servlet clustering are:

Objects stored in the session should be serializable.

Design for idempotence.

Avoid using instance and static variables in read and write mode.

Avoid storing values in the ServletContext.

Avoid using java.io.* and use getResourceAsStream() instead.

JSPs have a translation or a compilation process where the JSP engine translates and compiles a JSP file into a JSP servlet.

JSPs have 4 different scope values: page, request, session and application. JSPs can be included statically, where all the included JSP pages are compiled into a single servlet during the translation or compilation phase or included dynamically, where included JSPs are compiled into separate servlets and the content generated by these servlets are included at runtime in the JSP response.

Avoid scriptlet code in your JSPs and use JavaBeans or custom tags (e.g. Struts tags, JSTL tags, JSF tags etc) instead.

Databases can run out of cursors if the connections are not closed properly. The valuable resources like connections and statements should be enclosed in a try{} and finally{} block.

Prepared statements offer better performance as opposed to statements, as they are precompiled and reuse the same execution plan with different arguments. Prepared statements are also more secure because they use bind variables, which can prevent SQL injection attacks.

JNDI provides a generic interface to LDAP and other directory services like NDS, DNS etc.

In your code always make use of a logical JNDI reference (java:comp/env/ejb/MyBean) as opposed to physical JNDI reference (ejb/MyBean) because you cannot guarantee that the physical JNDI location you specify in your code will be available. Your code will break if the physical location is changed.

LDAP servers are typically used in J2EE applications to authenticate and authorize users. LDAP servers are hierarchical and are optimized for read access, so likely to be faster than database in providing read access.

RMI facilitates object method calls between JVMs. JVMs can be located on separate host machines, still one JVM can invoke methods belonging to an object residing in another JVM (i.e. address space). RMI uses object serialization to marshal and unmarshal parameters. The remote objects should extend the UnicastRemoteObject.

To go through a firewall, the RMI protocol can be embedded within the firewall trusted HTTP protocol, which is called

HTTP tunneling.

EJB (i.e. 2.x) is a remote, distributed multi-tier system, which supports protocols like JRMP, IIOP, and HTTP etc. EJB components contain business logic and system level supports like security, transaction, instance pooling, multi-

threading, object life-cycles etc are managed by the EJB container and hence simplify the programming effort. Having said this, there are emerging technologies like:

Hibernate, which is an open source object-to-relational (O/R) mapping framework.

EJB 3.0, which is taking ease of development very seriously and has adjusted its model to offer the plain old Java objects (i.e. POJOs) based persistence and the new O/R mapping model based on hibernate.

Refer Q14 – Q18 in Emerging technologies / Frameworks section for brief discussion on hibernate and EJB 3.0.

EJB transaction attributes (like Required, Mandatory, RequiresNew, Supports etc) are specified declaratively through EJB deployment descriptors. Isolation levels are not part of the EJB 2.x specification. So the isolation levels can be set on the resource manager either explicitly on the Connection or via the application server specific configuration.

A transaction is often described by ACID (Atomic, Consistent, Isolated and Durable) properties. A distributed transaction is an ACID transaction between two or more independent transactional resources like two separate databases. A 2-phase commit is an approach for committing a distributed transaction in 2 phases.

EJB 2.x has two types of exceptions:

System exception: is an unchecked exception derived from java.lang.RuntimeException. It is thrown by the system and is not recoverable.

Application exception: is specific to an application and is thrown because of violation of business rules.

EJB container managed transactions are automatically rolled back when a system exception occurs. This is possible because the container can intercept system exceptions. However when an application exception occurs, the container does not intercept and leaves it to the code to roll back using ctx.setRollbackOnly() method.

EJB containers can make use of lazy loading (i.e. not creating an object until it is accessed) and dirty marker (i.e. persist only the entity beans that have bean modified) strategies to improve entity beans performance.

Message Oriented Middleware (MOM) is a software infrastructure that asynchronously communicates with other disparate systems through the production and consumption of messages. Messaging enables loosely coupled distributed communication. Java Messaging Service (JMS) is a Java API that allows applications to create, send, receive read messages in a standard way, hence improves portability.

Some of the design decisions you need to make in JMS are message acknowledgement modes, transaction modes, delivery modes etc, synchronous vs. asynchronous paradigm, message body types, setting appropriate timeouts etc.

XML documents can be processed in your Java/J2EE application either using a SAX parser, which is event driven or a DOM parser, which creates a tree structure in memory. The other XML related technologies are DTD, XSD, XSL, XPath, etc and Java and XML based technologies are JAXP, JAXB etc.

There is an impedance mismatch between object and relational technology. Classes represent both data and behavior whereas relational database tables just implement data. Inheritance class structure can be mapped to relational data model in one of the following ways:

Map class hierarchy to single database table.

Map each class to its own table.

Map each concrete class to its own table

Generic meta-data driven approach.

Normalize data in your database for accuracy and denormalize data in your database for performance.

RUP (Rational Unified Process) has 4 phases in the following order Inception, Elaboration, Construction, and Transition. Agile (i.e. lightweight) software development process is gaining popularity and momentum across organizations. Several methodologies like XP, RUP, Scrum, FDD, TDD etc fit under this agile development methodology banner. All these methodologies share many characteristics like iterative and incremental development, stand-up meetings to improve communication, automatic build, testing and continuous integration etc.

UML is applicable to the object oriented (OO) problem solving. There are different types of UML diagrams like use case diagrams, class diagrams, sequence diagrams, collaboration diagrams, state chart diagrams, activity diagrams, component diagrams, deployment diagrams etc.

Class diagrams are vital within OO methods. Class diagrams have the following possible relationships: association, aggregation, composition, generalization, realization and dependency.

Struts is an MVC framework. Struts action classes are not thread-safe and care should be taken in declaring instance variables or accessing other shared resources. JSF is another Web UI framework like Struts gaining popularity and momentum.

Log4j has three main components: loggers, appenders and layouts. Logger is a utility wrapper class. JUnit is an open source unit-testing framework.

You can improve the performance of a J2EE application as follows :

1.Manage and recycle your valuable resources like connections, threads etc by either pooling or caching.

2.Use effective design patterns like session façade, value object, and fast lane reader etc to minimize network overheads.

3.Set appropriate time-outs for HttpSession objects.

4.Use JDBC prepared statements as opposed to statements.

5.Release database connections in a finally {} block when finished.

6.Apply least restrictive but valid transaction isolation level.

7.Batch database requests.

8.Minimize serialization costs by marking references like file handles, database connections, etc which do not require serialization by declaring them transient.

Some of the J2EE best practices are:

1.Recycle your valuable resources by either pooling or caching.

2.Automate your build process with tools like Ant, CruiseControl, and Maven etc, and continuously integrate your code into your build process.

3.Build test cases first using tools like JUnit.

4.Use standard J2EE packaging to improve portability.

5.Apply appropriate proven design patterns.

6.Use proven frameworks like Struts, Spring, Hibernate, JSF, JUnit, Log4J, etc.

7.Handle and propagate exceptions correctly.

8.Avoid resource leaks by closing all database connections after you have used them.

The goals of application server clustering are to achieve scalability, load balancing, and high availability.

Java Management Extension (JMX) framework can improve the manageability of your application, for performance problems, critical events, error conditions etc and perform health checks on your hardware, database server etc. You can also configure and control your application at runtime.

Finally get familiarized with some of the key Java & J2EE design patterns like:

1.MVC design pattern: J2EE uses this design pattern or architecture.

2.Chain of responsibility design pattern: Servlet filters use a slightly modified version of chain of responsibility design pattern.

3.Front controller J2EE design pattern: provides a centralized access point for HTTP request handling to support the integration system services like security, data validation etc. This is a popular J2EE design pattern.

4.Composite view J2EE design pattern: creates an aggregate view from atomic sub-views.

5.View helper J2EE design pattern: avoids duplication of code. The helper classes are JavaBeans and custom tags (e.g. Struts tags, JSF tags, JSTL tags etc).

6.Service to worker and dispatcher view J2EE design pattern: These two patterns are a combination of front controller and view helper patterns with a dispatcher component. These two patterns differ in the way they suggest different division of responsibility among components.

7.Bridge design pattern: Java Data Base Connectivity (JDBC) uses the bridge design pattern. The JDBC API provides an abstraction and the JDBC drivers provide the implementation.

8.Proxy design pattern: RMI & EJB uses the proxy design pattern. A popular design pattern.

9.Business delegate J2EE design pattern: used to reduce the coupling between the presentation tier and the business services tier components.

10.Session façade J2EE design pattern: too many fine-grained method calls between the client and the server will lead to network overhead and tight coupling. Use a session bean as a façade to provide a coarse-grained service access layer to clients.

11.Value object J2EE design pattern: avoid fine-grained method calls by creating a value object, which will help the client, make a coarse-grained call.

12.Fast-lane reader J2EE design pattern: access the persistence layer directly using a DAO (Data Access Object) pattern instead of using entity beans.

13.Service locator J2EE design pattern: expensive and redundant JNDI lookups can be avoided by caching and reusing the already looked up service objects.

Recommended reading on J2EE design patterns:

Core J2EE Patterns: Best Practices and Design Strategies, Second Edition (Hardcover) by Deepak Alur, Dan Malks, John Crupi.

Tech Tip #8:

Q. How do you list the files in current directory sorted by size in a UNIX machine?

$> ls –l | grep ^- | sort -nr

Q. How do you delete blank lines in a file in a UNIX machine ?

$> cat file1.txt | grep –v ‘^$’ > file2.txt

Q. How would you display all the files recursively under current directory in a UNIX machine?

$> find . –depth -print

Q. How would you display disk usage in kilobytes in a UNIX machine?

$> du –k

Let us put all together in the next section

SECTION THREE

How would you go about…?

This section basically assesses your knowledge of how to perform certain tasks like documenting your project, identifying any potential performance, memory, transactional, and/or design issues etc.

It also assesses if you have performed any of these tasks before. If you have not done a particular task, you can demonstrate that you know how to go about it if the task is assigned to you.

This section also recaps some of the key considerations discussed in the Java and Enterprise sections. Question numbers are used for cross-referencing with Java and Enterprise sections.

Q11 & Q14 are discussed in more detail and can be used as a quick reference guide in a software project. All the other questions excluding Q11 & Q14 can be read just before an interview.

Q 01: How would you go about documenting your Java/J2EE application? FAQ

A 01: To be successful with a Java/J2EE project, proper documentation is vital.

Before embarking on coding get the business requirements down. Build a complete list of requested features, sample screen shots (if available), use case diagrams, business rules etc as a functional specification document. This is the phase where business analysts and developers will be asking questions about user interface requirements, data tier integration requirements, use cases etc. Also prioritize the features based on the business goals, lead-times and iterations required for implementation.

Prepare a technical specification document based on the functional specification. The technical specification document should cover:

Purpose of the document: e.g. This document will emphasize the customer service functionality.

Overview: This section basically covers background information, scope, any inclusions and/or exclusions, referenced documents etc.

Basic architecture: discusses or references baseline architecture document. Answers questions like Will it scale? Can this performance be improved? Is it extendable and/or maintainable? Are there any security issues? Describe the vertical slices to be used in the early iterations, and the concepts to be proved by each slice. Etc. For example which MVC [model-1, model-2 etc] paradigms (Refer Q3 in Enterprise section for MVC) should we use? Should we use Struts, JSF, and Spring MVC etc or build our own framework? Should we use a business delegate (Refer Q83 in Enterprise section for business delegate) to decouple middle tier with the client tier? Should we use AOP (Aspect Oriented Programming) (Refer Q3 in Emerging Technologies/Frameworks)? Should we use dependency injection? Should we use annotations? Do we require internationalization? Etc.

Assumptions, Dependencies, Risks and Issues: highlight all the assumptions, dependencies, risks and issues. For example list all the risks you can identify.

Design alternatives for each key functional requirement. Also discuss why a particular design alternative was chosen over the others. This process will encourage developers analyze the possible design alternatives without having to jump at the obvious solution, which might not always be the best one.

Processing logic: discuss the processing logic for the client tier, middle tier and the data tier. Where required add process flow diagrams. Add any pre-process conditions and/or post-process conditions. (Refer Q9 in Java section for design by contract).

UML diagrams to communicate the design to the fellow developers, solution designers, architects etc. Usually class diagrams and sequence diagrams are required. The other diagrams may be added for any special cases like (Refer Q107 in Enterprise section):

State chart diagram: useful to describe behavior of an object across several use cases.

Activity diagram: useful to express complex operations. Supports and encourages parallel behavior. Activity and statechart diagrams are beneficial for workflow modeling with multi threaded programming.

Collaboration and Sequence diagrams: Use a collaboration or sequence diagram when you want to look at behavior of several objects within a single use case. If you want to look at a single object across multiple use cases then use statechart.

Object diagrams: The Object diagrams show instances instead of classes. They are useful for explaining some complicated objects in detail such as highlighting recursive relationships.

List the package names, class names, database names and table names with a brief description of their responsibility in a tabular form.

Prepare a coding standards document for the whole team to promote consistency and efficiency. Some coding practices can degrade performance for example:

Inappropriate use of String class. Use StringBuffer instead of String for compute intensive mutations (Refer Q21 in Java section).