Ans: 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.
Ans: When configured in Standalone mode each distribution starts a single JVM process with its own configuration, management instruments and deployments. When configured in Domain mode, multiple servers are managed from a centralized point called Domain Controller which maintain the configuration and provisions applications for deployment on the single nodes which are part of the Domain
Ans: 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
Ans: 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.
Ans: 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.
Ans: Seam runs beautifully on other application servers - just like everything else the Hibernate team does, this is not a JBoss-only thing.
Ans: JBossCache enables easy distribution of datasets across your computing environments. It is based on JGroups and enables clustering and high availability of that data. You may choose to distribute the data with JBoss Messaging to move it where it is needed for computation or event-based programming.
Ans: 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.
Ans: JBoss registers in the JNDI tree a JTA UserTransaction Object which can be user to manage a distributed transaction.
Ans: 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
Ans: 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.
Ans: 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.
Ans: 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.
Ans: The first step is to measure the different components of your app to see where the degradation is. Is it an external resource (database, message server, etc.)? Is it internal? Where is the app spending all its time?
So the first step could be to to use JBoss JMX agents and monitor the components deployed to the application server. Once it's clear which component or library takes most of the time or most of resource you can use a more specialized tool like JProbe and examine the single method or the single objects loaded in memory.
Ans: JBoss registers in the JNDI tree a JTA UserTransaction Object which can be user to manage a distributed transaction.
Ans: When the validate-on-match option is set to true, the database connection is validated every time it is checked out from the connection pool using the validation mechanism specified in the next step.
On the other hand, background-validation fires a background validation as dictated by the background-validation-millis.
You cannot apply both of them, they are mutually exclusive.
Ans: One core difference between Standalone mode and Domain mode is that Standalone mode allows manual deployment of applications by copying archives into the deployment folder. On the other hand, in Domain mode applications are managed and copied through the CLI or the Admin Console into the data folder of the single nodes. That being said, some applications might require to know the physical path where the application has been deployed: one good example is LifeRay portal which requires some workarounds to run in Domain mode. So always check the applications requirement before committing to a change from Standalone mode to Domain mode.
Ans: In terms of configuration: The httpd side does not need to know cluster topology in advance, so the configuration is dynamic and not static and as a consequence you need very little configuration on the httpd side
In terms of load balancing: You have an improved load balancing as main calculations are done on the backend servers, where more information is available and thus a fine grained web application lifecycle control
Ans: 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: