Home
User Guide
The information contained in this section applies to IBM WebSphere Commerce Version 7.0.0.9 and Feautre Pack 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in new editions.
Developing
The topics in the Developing section describe tasks performed by an application developer.
Persistent object model
WebSphere Commerce deals with a large amount of persistent data. There are numerous tables defined in the current database schema. Even with this extensive schema, however, you might need to extend or customize the database schema for your particular business needs.
WebSphere Commerce enterprise beans
The persistence layer within the WebSphere Commerce architecture is implemented according to the EJB component architecture. The EJB architecture defines two types of enterprise beans: entity beans and session beans. Entity beans are further divided into container-managed persistence (CMP) beans and bean-managed persistence (BMP) beans.
Object life cycles
The enterprise beans in the object model include both independent and dependent objects. An independent object has its own life cycle, controlled directly by the create or remove requests of the business logic invoking the object. A dependent object has a life cycle that is attached to another object, known as the owner object (which may also in turn be a dependent object, but further up the association hierarchy, an independent object exists). When the owner object is deleted, all dependent objects are also deleted. The actual deletes are controlled by cascading delete specifications within the database.

Object life cycles

The enterprise beans in the object model include both independent and dependent objects. An independent object has its own life cycle, controlled directly by the create or remove requests of the business logic invoking the object. A dependent object has a life cycle that is attached to another object, known as the owner object (which may also in turn be a dependent object, but further up the association hierarchy, an independent object exists). When the owner object is deleted, all dependent objects are also deleted. The actual deletes are controlled by cascading delete specifications within the database.

For example, given a user object that returns an address book object and a list of order objects, if the user object is deleted, its address book object is also deleted (since the book is owned by the user), and so are all the address objects within the book (since the addresses are owned by the book). However, the order objects are not deleted because the owner of orders is a store object, not the user object.

A specific design pattern is used for the creation of dependent objects. The create method of a dependent object must supply a reference to its owner object; therefore, the owner object must exist before the dependent object can be created.