The operation model controls the operation flow. The operation flow is the set of tasks that the operation must perform such as getting data from a magnetic reader, validating data obtained in a view, accessing a journal, sending data to the host, receiving data from the host, and printing a receipt. Operation steps are implementations of these tasks. When the application is using client/server operations, the server has a different operation model from the client. The server operation model receives requests from the client machine. Its operation flow includes all the operation steps to process the operation on the server such as adding an entry in the journal, sending data to the host, receiving data from the host, updating the journal, and printing a report on a server-based laser printer. The operation model may perform cross-field validations, which check whether there is a valid relationship between a particular data value and other specific data values and whether the value complies with specific business rules, which is a semantic validation.

The server operation model has access to the data provided by the client operation through the operation context and usually accesses the appropriate services for sending the corresponding data, properly formatted, to either the journal, the host, a printer, or other appropriate destination. Again, all these tasks inside the operation flow may result in one or more operation steps, depending on the specific solution chosen in the implementation design. Usually, every transaction to the host inside an operation on the server requires a set of processes (for example, journaling or counters update). This set of processes may result in an operation step.

To perform the tasks in its flow, an operation model may use one or more operation steps. The data used by these steps is in the operation context or in the context chain to which the operation context belongs. Both sides, client and server, can access it. The steps access local services, appropriately formatting the data required by the service, to perform actions such as updating a journal or counter, receiving reply data, and printing a receipt. An important local service that a client operation model can use is the Java Connector, which sends the operation to the server and transports data from the client operation context to the server operation context so the server operation model may work with these data. Depending on the implementation of the business logic, a flow can have a single operation step that has all the logic for the operation or as many operation steps as there are atomic tasks inside the operation flow. (That is, there can be one step for validation, one for executing the operation on the server side, one for receiving the reply data, one for printing, and so on.)

The execute method of the operation is where the operation flow (business logic) is implemented. Alternatively, you can define your operation flows based on states of the business process and use a flow processor to handle the flow. When the operation uses a flow processor, a state in the flow processor represents an operation step in the operation flow.

An operation view plays the observer role in an Observer design pattern and the operation model is a subject. Alternatively, a command processor or another operation model could be the observer of the operation model. As a special observer of an operation, the server side of the Java Connector is responsible for getting the request from the client, launching the corresponding operation on the server, and processing the requested business operation.