Overview of Business Services

As discussed in Chapter 6, before business services (also called the business layer) can be implemented, design documents must include a good preliminary specification of the needed main classes, or business objects, and how these business objects are to be packaged into components. As we examine business objects and their implementations, the following key design points should be considered:

• Regardless of how the information they use is actually stored, business objects encapsulate real-world business operations.
• Business objects control sequencing and enforcement of business rules, as well as the transactional integrity of the operations they perform.
• Each business object method should perform exactly one unit of work; each unit of work should in turn be implemented in exactly one method.
• Calling methods on business and data objects enables higher-level operations.
• Whether or not a particular caller is transactional, business objects should work properly.
• Business objects called directly from a presentation layer should not retain per-object state across method calls. Business objects called within a presentation layer can retain per-object state within a transaction boundary (a boundary between services layers).
• Minimizing network traffic between remote presentation layers and business objects is important; therefore, business objects should be network-friendly.
• Role-based security should be used to restrict access to business objects, as they are the gatekeepers that control data access.
• Transaction models, such as those within MTS, provide a straightforward model for handling errors generated within business object methods.

Based on the design points mentioned above, business object implementations will likely be important company assets for use in many applications.