JBoss AS Interview Preparation Guide

Download PDF

JBoss is a popular open source application server based on JEE technology. Being JEE based, the JBoss supports cross-platform java applications. It was embedded with Apache Tomcat web server. It runs under any JVM of 1.3 or later versions. JBoss supports JNDI, Servlet/JSP (Tomcat or Jetty), EJB, JTS/JTA, JCA, JMS, Clustering (JavaGroups), Web Services (Axis), and IIOP integration (JacORB).

JBoss cache is a product. Frequently accessed Java objects are cached by utilzing JBoss cache to improve the performance of e-business applications. JBoss decreases the network traffic and increases the scalability of applications by eliminating unnecessary database acces.Fully transactional features and highly configurable set of options which are to deal with concurrent data access, are provided by JBoss cache in an efficient manner possible for the applications.

JBoss JBPM is a workflow and BPM engine. Enabling the creation of business processes that coordinates between people, applications and services is the functionality of BPM engine. The combination of workflow applications development with process design is a feature of JBoss jBPM. The business process is graphically represented to facilitate a strong link between the business analyst and technical developer. This feature is provided by the JBoss jBPM process designer.

Different components of the application are to be measured. This step is to find where the degradation is, whether it is external or internal and where is the appliciation spending all the time. Using Joss JMX agents and monitoring the deployed components to the application server involves in the first step.

After finding the most of the time spent by specific components or libraries or most of the resources, one can use Jprobe a specialized tool for examining the single object or the objects loaded in the memory.

► Java Transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.
► The Java™ Transaction API (JTA) allows applications to perform distributed transactions, that is, transactions that access and update data on two or more networked computer resources.
► The Java Transaction API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for an application server, and a standard Java mapping of the X/Open XA protocol intended for a transactional resource manager.

The perception of EJB3 as being a simple clone of Hibernate is primarily based on developer familiarity with Hibernate and a similarity of naming, as well as common purpose, and that Hibernate is morphing itself into an EJB3 implementation based on the work going into the specification, not the other way around.

EJBs are supposed to be components, in the sense that they're not just one class, but a set of classes, descriptors and usage and management contracts. All of this in order to allow a container (JBoss,
Weblogic, etc.) to provide services to those components, and to be able to reuse and distribute this components. This services are, among others, transactions, concurrent access control, security, instance pooling, etcetera.
Hibernat is "just" an ORM (Object/Relational Mapping) tool. Quick and dirty, this means you can store an object tree belonging to an class hierarchy in a relational DB without writing a single SQL query. Quite cool, IMO. But no transaction control, no instance pooling, no concurrency control, and certainly no security.

The Session interface wraps a JDBC Connection. This interface is a single threaded object which represents a single unit of work with application and persistent database. It's retrieved by the SessionFactory's openSession() method

Yes: that is many threads can access it cuncurrentely and request for sessions. It holds cached data that has been read in one unit of work and may be reused in a future unit of work. Good practice is to create it when the application is initialized.

JBoss registers in the JNDI tree a JTA UserTransaction Object which can be user to manage a distributed transaction.

You can't with a Servlet. A JTA transaction must start and finish within a single invocation (of the service() method). You should consider using a Stateful SB. In a SFSB with a JTA transaction, the association between the bean instance and the transaction is retained across multiple client calls.

EJBs are now plain old Java objects (POJO) that expose regular business interfaces (POJI), and there is no requirement for home interfaces.

► Use of metadata annotations, an extensible, metadata-driven, attribute-oriented framework that is used to generate Java code or XML deployment descriptors.
► Removal of the requirement for specific interfaces and deployment descriptors (deployment descriptor information can be replaced by annotations).
► Interceptor facility to invoke user methods at the invocation of business methods or at life cycle events.
► Default values are used whenever possible (“configuration by exception” approach).
► Reduction in the requirements for usage of checked exception.
► A complete new persistence model (based on the JPA standard), that supersedes EJB 2.x entity beans

A local-tx-datasource identifies a data source that uses transactions, even distributed trans actions within the local application server, but doesn’t use distributed transactions among multiple application servers. An xa-datasource on the other hand identifies a data source that uses distributed transaction among multi-ple application servers.

Basically starting JBoss with the “all” configuration contains everything needed for clustering:
It has all the libraries for clustering:

► JGroups.jar, jboss-cache.jar
► Clustered beans (cluster-service.xml)
► HA-JNDI
► HTTP session replications (tc5-cluster-service.xml)
► Farming
► HA-JMS

You could activate the "Commit Option A" that is the container caches entity bean state between transactions. This option assumesthat the container has exclusive access to the persistentstore and therefore it doesn’t need to synchronizethe in-memory bean state from the persistent store at the beginning of each transaction.

The JGroups framework provides services to enable peer-to-peer communications between nodes in a cluster. It is built on top a stack of network communication protocols that provide transport, discovery, reliability and failure detection, and cluster membership management services.

It is technically possible to put a JBoss server instance into multiple clusters at the same time, this practice is generally not recommended, as it increases the management complexity.

Built on the standards JavaServer Faces and EJB 3.0, JBoss Seam unifies component and programming models and delivers a consistent and powerful framework for rapid creation of web applications with Java EE 5.0. Seam simplifies web application development and enables new functionality that was difficult to implement by hand before, such as stateful conversations, multi-window operation, and handling concurrent fine-grained AJAX requests. Seam also unifies and integrates popular open source technologies like Facelets, Hibernate, iText, and Lucene.

Seam runs beautifully on other application servers - just like everything else the Hibernate team does, this is not a JBoss-only thing.

Seam only works on JDK 5.0 and above. It uses annotations and other JDK 5.0 features.

In my opinion one of the biggest obstacle in the movement towards SOA adoption is the organization’s own IT department.Too many people in the IT organization conceive SOA as a technology concept only, and as such think of SOA as just a set of technologies and infrastructure for exposing, securing, running, and managing Services. Put it this way, SOA is nothing more than Web Services and standardized middleware. The critical flaw in thinking is confusing the technology that sits beneath the Services level of abstraction and the mechanism by which Services are accessed with the architectural approach that aims to decouple the implementation from the consumption and focus on sustainable architecture that allows for continuous change.

Successful SOA adoption requires a cultural shift in the way IT is done. The Service-oriented movement to agility and loose coupling demands a shift from traditional, waterfall styles of development (design-build-test-deploy-manage) to iterative approaches to continuous Service modeling

In my opinion BPEL and BPM are quite different things so they cannot even be compared. The problems boils down to the fact that these years maybe BPEL has been marketed for something which isn't: that is a Business Process Management framework.
BPEL is made up for service orchestration, that is publishing new services as a function of other services.
while BPM si needed for handling human task management functionalities and subprocess management.

Java API for XML-Based RPC (JAX-RPC) is a Legacy Web Services Java API, it uses SOAP and HTTP to do RPCs over the network and enables building of Web services and Web applications based on the SOAP 1.1 specification, Java SE 1.4 or lower.JAX-WS 2.0 is the successor to JAX-RPC 1.1. JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. However there are lots of differences:

► JAX-WS maps to Java 5.0 and relies on many of the features new in Java 5.0 like Web Service annotations.
► JAX-RPC has its own data mapping model, JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas.
► JAX-WS introduces message-oriented functionality, dynamic asynchronous functionality which are missing in JAX-RPC.
► JAX-WS also add support, via JAXB, for MTOM, the new attachment specification.

JBossTS supports Web Services transactions, including extended transaction models designed specifically for loosely-coupled, long running business processes. J2EE transactions can integrate seamlessly with Web Services transactions using our integrated, bi-directional transaction bridge. Interoperability with many other vendors is provided out-of-the-box and JBoss is an active participant in these standards.

For Seam 1.3: Seam was developed against JBoss 4.2. Seam can still be run against JBoss 4.0. The seam documentation contains instructions for configuring JBoss 4.0.


For Seam 1.2: Since Seam requires the latest edition of EJB3, you need to install JBoss AS from the latest JEMS installer. Make sure that you select the "ejb3" or "ejb3+clustering" profile to include EJB3 support. Also, the jboss-seam.jar library file from the Seam distribution must be included in each Seam application you deploy. Refer to examples in Seam distribution (inside the examples directory) to see how to build and package Seam applications.

Yes, you can run Seam applications in plain Tomcat 5.5+ or in the Sun GlassFish application server. To run Seam application in Tomcat, you need a number of additional library files and a few configuration files to bootstrap the JBoss EJB3 inside Tomcat. Please refer to the deploy.tomcat ANT build target for the Seam booking example (in the examples/booking directory of the Seam distribution) for more on how to build a Tomcat WAR for Seam applications. Refer to this blog post on how to run Seam in Sun's Glassfish application server.