Functional architecture
Functional architecture provides both the set of patterns used to implement the business functionality and the frameworks in which these business functions execute.The areas of business functionality of WebSphere Commerce include:
- catalog
- merchandising
- marketing
- promotions
- trading
- user management
- order management
The frameworks in WebSphere Commerce are:
- calculation framework
- reporting framework
- Tools framework
- Business policy framework
- MVC
- Command framework
- Runtime framework
- WebSphere Commerce common architecture
Before examining how the WebSphere Commerce Server functions, it is useful to look at the larger picture of the software components that relate to WebSphere Commerce.- WebSphere Commerce presentation layer
WebSphere Commerce uses Java Server Pages (JSP) to implement the view layer of the Model-View-Controller (MVC) design pattern. The view layer is in charge of retrieving data from the database through the use of data beans and formatting it to meet the display requirements. The view layers determines whether the request is sent to a browser or streamed out as XML. JSP files present a clean separation between data content and presentation.- 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 database schema
The WebSphere Commerce database model was designed for data integrity and optimal performance. WebSphere Commerce provides several hundred tables that store WebSphere Commerce instance data. To maintain data integrity, and to ease maintenance referential integrity, constraints are widely used in the database model. Indexes are used carefully on Commerce tables to avoid over-indexing and to provide a good balance between data retrieval and data manipulation activities (insert and update). The business rules are implemented at the application level rather than through the use of database trigger. Triggers, however, are used to facilitate data staging and optimistic locking. A limited number of SQL based database stored procedures are used for data intensive activities.