SAP BOPF vs J2EE transactional frameworks

BOPF

Enterprise Java Beans

1

SAP’s Business Objects (BO) are modelled and implemented using Business Object Modelling Framework.

Enterprise Java beans and its runtime framework are J2EE components that are comparable with the SAP BOPF in the world of transactional systems.

2

BOPF controls the application business logic as well as the data retrieval of the buffer and persistency layer.

The Persistency and Caching layer is maintained by the persistency provider. Example of persistency service providers are: hibernate, toplink etc.

3

BOPF standalone transaction manager is responsible for maintaining consistency of the transaction, by adhering to the principles of ACID properties.

Transaction manager is responsible for maintaining consistency of the transaction, by adhering to the principles of ACID properties.

4

BOPF transaction manager associates one or more service manager instances with a calling transactional context.

Transaction manager associated with the persistency service provider associates the newly created transaction object with the current calling thread.

5

Data buffer and persistency are also clearly separated from each other as well as from the business logic. This allows to establish individual buffer and persistency implementations. BOPF provides facility to the user to implement his own buffering logic and mechanism.

All the persistency service providers work on an intermediate data caching mechanism to synchronize the transactional data between user session and database. The complexity of synchronization is hidden from the user.

6

BO is a coarse grained business object, which consists of fine grained nodes. A Node is a semantically related set of attributes of a business object. Nodes are hierarchically defined and related. Each business object has only one Root Node. Nodes are defined via compositions in a tree, and in addition, linked in an arbitrary structure via associations that can be separate from the tree structure.

EJB can be designed either as a coarse grained or fine grained entity, depending on the need of the business requirement. Fine grained EJBs could be assembled via spring dependency injection or using object relational mapping – association. Structurally, EJBs could also be grouped via association or composition.

7

Transactional attributes are not defined for (at) the method or actions in a Node. Rather the scope of the transaction is defined and determined by the Transaction Manager and Service Manager of BO.

A transaction in BOPF is spawned for a BO, rather than for a transactional method in a node inside it.

Due to the coarse grained modelling and runtime handling of the same model, it is in most cases useful to have consistency check of the whole model before saving of the model.

BOPF transaction can be chained by using the “Save and Continue” transaction pattern. In this model, every new save happens in a new transaction.

BOPF transaction can be terminated by using the “Save and Exit” transaction pattern. By following this pattern no new services could be executed using the same transaction.

BOPF transaction could be rolled back by calling the cleanup method of transaction manager.

Transaction manager can create any number of new transactions, and associate with the calling thread, if necessary configurations are maintained. In an enterprise transactional component like enterprise java beans, new transactions are spawned according to following transactional attributes set at the transactional methods of Bean.

1. “Not Supported” – If a method ‘A’ with this transactional attribute value is invoked from an existing transactional context, the calling transaction will be suspended until the method ‘A’ is executed.
2. “Supports”- The method ‘A’ is executed as part of calling transaction. If the calling thread is not part of a transaction, method ‘A’ will be executed as normal method.
3. “Required” – The method ‘A’ will be executed as part of the calling transactional scope. But if the calling thread is not in a transactional scope, a new transaction will be created and executed under that context. Also the same transaction will be propagated to succeeding methods.
4. “Requires New” – If a method is executed under an existing transaction, the calling transaction is suspended and a new transaction will be created for this method. The same transaction will be propagated to succeeding method calls. Once all the method calls are completed, the suspended caller transaction shall be resumed.
5. “Never”- If a method is marked with this transactional attribute value, and if this is called from a transactional context, Remote Exception will be thrown.

8

BOPF transaction manager provide services to retrieve information about the changes made during the current transaction.

Persistency Service Provider provides API to retrieve the information about the current transaction.

9

BOPF service manager provides interfaces to get data about the nodes in following 3 ways.

1. RETRIEVE
2. RETRIEVE_BY_ASSOCIATION
3. QUERY

Persistency Service Provider provides API to retrieve bean information via following ways.

1. LOAD
2. CREATEQUERY

10

BOPF offers two different types of associations between nodes in a BO. The association between nodes in a BO is always unidirectional.

1. Composite associations (From Parent to Child) :Uni-directional
2. General associations(Uni-directional)

Persistency Service Provider could create following types of association.

1. Uni-directional association.
2. Uni-directional association with join table.
3. Bi-directional association.
4. Bi-directional association with join table.

11

BOPF abstracts isolation level to the user.

But user could set certain transactional characteristics on the transaction manager, via, transaction manager’s  set_transaction_context(…) method.

Using java, you can perform transactions under different isolation levels at connection level.

1. TRANSACTION_SERIALIZABLE – The most accurate transaction settings, but slow in performance.
2. TRANSACTION_REPEATABLE_READ – In this even though dirty reads and non-repeatable reads are prevented, phantom reads can occur.
3. TRANSACTION_READ_UNCOMMITTED- In this dirty reads, non-repeatable reads and phantom reads are possible.
4. TRANSACTION_READ_COMMITTED- In this dirty reads are prevented, but non-repeatable reads and phantom reads are possible.

12

BOPF transaction manager provide following functionalities.

1. SAVE (Equivalent to Commit JTA).
2. CLEANUP (Equivalent to rollback JTA).
3. GET_TRANSACTIONAL_CHANGES (Equivalent to getTransaction in JTA).

A Transaction manager shall perform following functionalities.

1. Begin a transaction.
2. Commit a transaction.
3. Rollback a transaction.
4. Suspend a transaction.
5. Set transaction time out.
6. Get Transaction object.