Server Reference Guide : 3. OpenROAD Server Components : Business Policy Manager
 
Share this page                  
Business Policy Manager
ASOLib supports the concept of Business Policy Manager (BPM) or Transaction Control Object. In ASOLib, a BPM is a normal user class object to which all calls from a given client should be channeled. Functionality can be programmed into the BPM methods to implement business policy and create and use business objects. An existing user class can be used as a BPM.
One objective of a fat server/thin client system is to move as much of the intelligence and control from the client to the server. The intelligence includes:
Controlling user transactions
Creating, destroying, and controlling business objects
Storing and retrieving cached object data
Policing rogue or out-of-sequence calls
Simply exposing normal business objects and their methods requires substantial client intelligence. But moving the majority of the business logic (and the data access) to the server can make a client thinner. Also, programming multiple heterogeneous client technologies can be achieved more quickly and easily.
Some user interface control program logic exists in any client, but an OpenROAD Server application should not rely solely on the client getting things right. This is particularly important when the intention is to deploy different client technologies either now or at some time in the future.
Ideally, an OpenROAD Server application should be self-contained and able to protect itself from inappropriate or malicious client access.
A BPM presents a control object interface to a client. The scope of a BPM can be an entire application, or there can be multiple BPM classes used to manage distinct areas of functionality. Where appropriate, a BPM may make use of further BPMs, either within or outside the same application image. This technique can be used for application partitioning.
For details about how to define a BPM at runtime from an OpenROAD client, see How Interaction Between a TCA and an Application Using ASOLib Works.
The following diagram illustrates BPM's control object interface:
The BPM may simply pass control to 4GL procedures, or to the methods of business objects that it has created. In addition, the BPM method call can be validated based on the current state of the user's transaction or dialogue. A finite state machine can be useful in implementing this protective logic.
For an example of how to create and expose a user class as a BPM, see How You Can Use ASOLib Within an OpenROAD Server Application.