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.

Most of the WebSphere Commerce entity beans are CMP entity beans. A small number of stateless session beans are used to handle intensive database operations, such as performing a sum of all the rows in a particular column. One advantage of using CMP entity beans is that developers can utilize the EJB tools provided in WebSphere Commerce Developer. These tools allow developers to define Java objects and their database table mappings. The tools automatically generate the required persisters for the entity beans. Persisters are Java objects that persist Java fields to the database and populate Java fields with data from the database.

WebSphere Commerce uses EJB 2.x modules, but most of the entity beans are at EJB 1.1 level. WebSphere Commerce Developer provides two extensions to the EJB 1.1 specification: EJB inheritance and association. EJB inheritance allows an enterprise bean to inherit properties, methods, and method-level control descriptor attributes from another enterprise bean that resides in the same group. An association is a relationship that exists between two CMP entity beans.

Some of the WebSphere Commerce entity beans exploit the EJB inheritance feature. The WebSphere Commerce entity beans do not use the associations feature. To minimize complexity in the object model IBM recommends that you do not use the association feature when developing entity beans. Instead of using associations, use object relationship between enterprise beans. Do this by adding explicit getter methods in the enterprise beans.

WebSphere Commerce provides two sets of enterprise beans: private and public. Private enterprise beans are used by the WebSphere Commerce runtime environment and tools. You must not use or modify these beans.

Public enterprise beans, on the other hand, are used by commerce applications, and can be both used and extended. These public enterprise beans are organized into the following EJB modules:

• Catalog-ProductManagementData

• ContentManagement-WorkspaceFlowData

• Enablement-BaseComponentsData

• Enablement-RelationshipManagementData

• Enablement-TicklerData

• GiftRegistry-BaseComponentData

• GiftRegistry-OrderIntegrationData

• Marketing-CampaignsAndScenarioMarketingData

• Marketing-CustomerProfilingAndSegmentationData

• Marketing-ExperimentationManagementData

• Member-MemberManagementData

• Merchandising-PromotionsAndDiscountsData

• Order-OrderCaptureData

• Order-OrderManagementData

• WebSphereCommerceServerExtensionsData

• Trading-AuctionsAndRFQsData

Some of the EJB modules in the preceding list contain session beans. In order to simplify migration in the future, you should not modify a session bean class. If required, you can create a new session bean in the WebSphereCommerceServerExtensionsData EJB module. For more information about creating new session beans, refer to Writing new session beans.

A program that uses enterprise beans must deal with the Java Naming and Directory Interface (JNDI) as well as the home and remote interfaces of enterprise beans. To simplify the programming model, an access bean for each enterprise bean is generated. When creating your own enterprise beans, use the tooling in WebSphere Commerce Developer to generate this access bean.

• 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.

• Transactions
  The Enterprise JavaBeans V2.1 architecture specifies three alternative commit-time options with respect to the instance state.

• Primary keys
  A primary key is a unique key that is part of the definition of a table. It can be used to distinguish one record from others. All records must have a primary key. When you create a new record in a table, you may need to generate a unique primary key for the record.

• Access beans
  WebSphere Commerce commands interact with access beans rather than directly with entity beans. Access beans provide a simpler interface to clients, caching of the home object, and reduced call traffic to the enterprise bean.

• Extending the WebSphere Commerce object model
  Application requirements may lead you to extend the existing WebSphere Commerce object model. The WebSphere Commerce object model can be extended in two ways.

• Extending the WebSphere Commerce object model with session beans
  One of the strengths of WebSphere Commerce stems from its ability to take advantage of container-managed persistence (CMP) entity beans. CMP entity beans are distributed, persistent, transactional, server-side Java components that can be generated by the tools provided by WebSphere Commerce Developer. In many cases, CMP entity beans are an extremely good choice for object persistence and they can be made to work at least as efficiently or even more efficiently than other object-to-relational mapping options. For these reasons, WebSphere Commerce has implemented core commerce objects using CMP entity beans.

• Create new session beans
  When creating new session beans, create them in the WebSphereCommerceServerExtensionsData project.

Related concepts

Persistent object model
Extending the WebSphere Commerce object model

Related tasks

Create new entity beans