When designing a business application, the scope (or power) of each remote operation ultimately depends on the transaction requirements of the application. However in general, it is a good practice to make operation requests as powerful as possible in order to hide the details of the business application ABL from the client programmer.

Also, the more power that remote operations have, the fewer requests must be made from the client to accomplish tasks over the network, thus reducing the opportunity for the network to be a bottleneck.

Session-managed operations over a bound connection

For session-managed applications that use bound connections, which support complex transactions, the operations can perform simple (less powerful), fine-grained procedures and functions because the ultimate result for a client does not have to be completed in a single request. Each procedure or function executed in a series of session-managed requests can help to assemble the context of a single transaction until a single committing operation completes the transaction after this context is complete.

An example might be a transaction to assemble a bill of materials (BOM), where the transaction depends on what components are already in stock for the BOM, requiring the client to invoke different operations to complete the structure of the transaction. Once the structure is completed for any missing components, the BOM transaction can be committed using a final operation.

Session-free or unbound session-managed operations

For a session-free application or a session-manage application that uses unbound connections, whether simple or complex (powerful), each operation must complete any transaction that it starts. Operations typical of this type of application include returning the current outdoor temperature given a zip code, or returning a zip code given a street address. A more powerful example might be an operation that returns all the available seats on airline flights to a given destination, followed by another operation that attempts to reserve a selected list of seats on any of the available carriers, based on a set of parameterized preferences, or specifically by seat number. In all cases, these operations complete their function in one request, and if a result is in some way unsuccessful, the request might simply be repeated with or without modification of the parameters involved.

Context can, however, be maintained for a session-free or for an unbound session-managed application between requests using input-output parameters provided by the business application procedures and SOAP Web service operations. You can also use the SESSION:SERVER-CONNECTION-CONTEXT attribute to pass character data from one ABL session to another that executes requests from the same connected client. An example might be an order entry SOAP Web service that allows a user to obtain status of a particular order, then examine the detail lines of that order.

In this case the context might be a customer number passed in a getOrders procedure to get the status of all that customer's orders. This might be followed by a getOrderLines procedure for a selected order, with both the customer number and order number passed as parameters to get the detail lines of a selected order for the customer. In this case, the context is really being maintained in persistent storage, such as a database, that is shared by all clients of the application.

When you use the SESSION:SERVER-CONNECTION-CONTEXT attribute to pass character data as session context, the session manager ensures that whatever value you assign to the attribute for one request is available in the ABL session that executes the next request from the same client." For more information, see Use the SERVER-CONNECTION-CONTEXT attribute.