ROSE: The Service



next up previous
Next: ROSE: The Protocol Up: Remote operation of Previous: Concepts and Processes

ROSE: The Service

The Remote Operation Service Element (ROSE) provides the mechanism for an application entity to cause some operation to be performed remotely, possibly receiving a result from that operation. Marshall Rose says of the OSI ROSE

...the RO-notation specifies the external behavior of systems without placing unnecessary constraints on the internal design of those systems. Many ...feel that this capability is likely to be a key factor in the overall success of OSI standardization. []

ROSE forms a part of an application entity, a particular combination of Application service elements and a control function that determines how they interact. ACSE will always be a part of that application entity also. Other ASEs can be included, depending on the requirements to be met by this application entity.

The services offered by ROSE allow an operation to be invoked (RO-INVOKE), a result or error to be returned (RO-RETURN-RESULT and RO-RETURN-ERROR) and also allow the remote system or the ROSE service provider to reject the operation invocation (RO-REJECT-U and RO-REJECT-P). It is worth noting the basic difference between the usual connection-oriented communication between cooperating processes in the OSI environment and the remote operation approach. Although ROSE uses the context established by ACSE, it provides its user the opportunity to interact with another OSI system while maintaining minimal state information. All ROSE services are unconfirmed. That means there is no initial setup stage, no negotiated end to the contact. ROSE defines five classes of operation based on these two modes: synchronous or blocking operation, and four variations on asynchronous operation. Asynchronous operation can expect reporting of both results and errors, errors only, results only, or neither results nor errors.

Parameters of the service invocations specify the operation the remote system must execute and any argument needed for the operation. An invocation identifier matches a result with the right request. Not all operations have results. For example, an operation to delete a file from a remote system does not generate a result. However, good practice suggests that the initiator of the request get feedback on the operation. The responder uses RO-RESULT to return a result or simply to notify the initiator that the operation is complete. In synchronous operation mode, RO-RESULT or RO-ERROR must follow an RO-REQUEST. In asynchronous operation mode, RO-RESULT or RO-ERROR will follow RO-REQUEST unless the option of no reporting was specified.

  
Figure: Reasons for ROSE service user generated rejections

A responder may fail to execute an instruction if a problem occurs. An error may be caused by a local condition at the responder's system, such as a resource unavailable, or a file not found. On the other hand, an ``error'' is sometimes the correct and expected result of an operation. For example, before writing a new database entry with a key value that is supposed to be unique, a process will first attempt to read the entry with that key value. The expected ``error'' reply, ``No such entry'', is exactly what is required to allow the process to write the new entry. The Presentation Context for an application needing this response would include the following entry in its abstract syntax definition:

-- error definitions
noMatchingKeyFound ERROR ::= 0
When an initiator requests a read with a specified key value, the responder returns RO-ERROR with parameter error-value=0. The user of ROSE receives this expected result and issues a request to write the new entry into the database.

If the database read operation yields an RO-RESULT (the normal ``successful'' conclusion of the read operation) with the content of an entry in the database with the new key, then the initiator process will be unable to write its new entry with the key it had calculated. RO-REJECT-U provides an opportunity for another stage in this conversation. Suppose the read operation yields RO-ERROR with error value indicating ``Duplicate entries for this key value'', the initiator can respond with RO-REJECT-U with reason equal ``Unexpected error''. The responding application entity would then have notice of an error in the database. If no RO-REJECT-U were issued, the error condition would continue undetected. The application process that uses ROSE determines what error or result to convey; ROSE itself defines the rejection by providing reasons.



next up previous
Next: ROSE: The Protocol Up: Remote operation of Previous: Concepts and Processes



boots cassel
Wed Feb 7 10:22:57 EST 1996