In this architectural model, independent processes collaborate to perform some task in a coordinated fashion. The peer approach is common in situations where either a lot of computing power is needed to perform an intense calculation or where independent systems need to guarantee that synchronized states are maintained. Any system that is transactional makes use of this model for at least part of its functionality.
The peer model treats all processes as equals, although it often requires one of them to act as a group coordinator.
An example of a peer processing situation in scientific applications is gene sequencing; a business processing example is executing a distributed purchasing transaction.
In these situations, each process calculates part of some result and contributes it to the whole. For example, as a customer places an order, a pricing process calculates a specific customer�s price for each item on an order and adds
those prices to the order information. J2EE supports peer processing via the Java Transaction Architecture (JTA) API. Using this API, your components can interact in a scoped, coordinated way with each other and with external systems.
JTA is one of the many J2EE APIs available to you, and transactional support is one of the key features of any J2EE EJB container.
1. Transaction Manager compartment
The Transaction Manager (TM) coordinates all activities on behalf of all interested parties. The transaction manager cooperates with all the other transaction managers that are within the scope of the transaction.
2. Application compartment
The application, such as an EJB client or an EJB itself, controls a transaction it starts.
The interface between the client and the transaction manager is the javax.transaction.UserTransaction object.
3. Application Server Compartment
The Application Server creates and controls transactions in a similar way to the client. An EJB container represents the application server in the EJB universe.
4. Resource Manager
Any resources that wish to take part in a transaction must have a specific resource manager. The resource manager registers itself with the transaction manager and then performs the commit or the rollback when requested by the transaction manager.
The resource manager also understands two-phase commits. The resource manager is typically the driver to a persistent data store of some kind.
5. Transaction Service Implementation
The low-level transaction service provides distributed transaction capabilities and takes care of the propagating transactions from upstream or to
downstream objects and resources. It is bundled into the EJB server.