2.2 requests

OODBTG Reference Model

See entry under 2.1 operations.

OMG Core Object Model Operation Dispatching

When an operation request is issued, a specific operation implementation(method) is selected for execution. This selection process is called operationdispatching. In the Core model, the process of selecting an implementationto invoke is based on the type of the object supplied as the controllingargument of the actual call11. The operationof the given name defined on the immediate type of the controlling argumentis chosen for invocation. In some cases this can be done at compile timewith no loss of flexibility, in others it must be delayed to executiontime.

4.2.7 Argument Passing and Results

Consider an operation W with the signature

w : (x1:s1, x2:s2,...,xn:sn) --> (y1:r1,y2:r2,..., ym:rm)

An invocation (request) of W might be writtenas:

r1,..., rm <-- w (E1,...,En)

where w is the name of W,Ei are expressions providing the input arguments, and ri accept the returnresults.

The request is legal if the expressions E1,...,En evaluate to a1,...,anand the immediate type of ai £si (£ is thesubtype relationship). The signature guarantees that the request returnsa set of results, b1,...,bm,and the immediate type of bi £ri.

Note that if the types of the arguments or results of Wbelong to NTypes then the subtype check is defined by the component thatdefines the non-object types. In most cases this is likely to be type equality.

The execution semantics consists of binding arguments and return valuesto formal parameters. The expressions Ei result in either non-objects orOIDs (collectively dvals). Operationally, these dvals are copied into theformal parameters. How the effect of copying is accomplished is not specified,nor is it required that the OIDs be the same, only that the object theyrefer to be the same. The objects that the OIDs refer to are notcopied. For example, consider the following operation specification andinvocation:
operation X defined in Type T

X (x: T)

X being invoked in some code

X (a_T)

Following the invocation, x refers to the same object as a_T. Operationrequests made to the OID in x will function exactly as if they had beenmade to the OID in a_T. It is not the case, however, that an assignmentto x will change a_T (or even the object x refers to). In this sense, theCore Model defines a pass-by-value parameter passing semantics.

11 The single controlling argument restrictioncan be relaxed in a component and generalized to multiple argument dispatching.


A request is an event, i.e. something that occurs at a particular time.The information associated with a request consists of an operation, a targetobject, zero or more actual parameters, and an optional request context[CORBA Specification 2.2.2 Requests].


See 2.1 Operations.


No notion of request.

Open Distributed Processing

Computationally, supports requests

Management Information Model

Not applicable.


SQL functions associated with ADTs are invoked using either a functionalnotation or a dot notation (the dot notation is syntactic sugar for thefunctional notation). For example:

See also 2.4 specification of behavioral semantics.


A message is a request for execution of a method.


Class data members and member functions are accessed as if they wereelements of a data structure. A request for access is given by specifyingthe name of an object (e.g., a reference) and the name of the operation,together with the appropriate parameters.


A request to execute a named method on a given object is called an invocation.Invocations may be specified in two ways. An in-line method invocationis indicated by two contiguous colon characters. For example, the followinginvokes method FOO of object OBJ, with parameter PARM:

An explicit invocation is specified using the INVOKE statement. An INVOKEstatement similar to the above invocation would be:

The INVOKE statement allows the name of the method to be invoked tobe contained in a variable. In addition, parameters can be passed BY CONTENT(by value) or BY REFERENCE, and these options can be specified separatelyfor each parameter in different INVOKE statements.


A request is act of sending a message to an object's interface withthe expectation that the object will perform a known operation that isassociated with the message.


Emerald supports concurrency both between objects and within an object.Within a network many objects can execute concurrently. Within a singleobject, several operation invocations can be in progress simultaneously,and these can execute in parallel with the object's internal process (ifit has one). To control access to variables shared by different operations,the shared variables and the operations manipulating them can be definedwithin a monitor [Hoa74]. Processes synchronize through built-incondition objects. An object's process executes outside of the monitor,but can invoke monitored operations when it needs to access shared state.[BHJL86]

See entry under 2.9 communication model for an example objectdefinition.


See entry under 2. Objects.

System Object Model (SOM)

Client requests are invoked on objects by specifying the name of anobject and the name of the operation along with parameters to invoke onit. An object can support multiple operations.

OLE Component Object Model

Requests resemble calls to C++ functions. However, functions are alwayscalled indirectly, through interfaces, as described in the entry under2. Objects.

Analysis and Design Methods

SA: Instances make requests by generatingevents.

CA: Instances make requests via messageconnections. "A Message Connection is a mapping of one Object intoanother (or occasionally to a Class, to create a new Object), in whicha 'sender' sends a message to a 'receiver.' to get some processing done."


JA: An actor instance "inputs astimulus, the use case instance executes and starts a transaction belongingto the use case." See 2.10 events.

WD: "When one object sends a messageto another object, the sender is requesting that the receiver of the messageperform the named operation, and (possibly) return some information."

WD: Rather than make requests, programsapply an operation to an object.

EA: A request is one kind of interaction.

FA: An input event is a request for asystem operation.

OA: "A means by which an operationis invoked. It consists of an operation name and zero or more actual parameters."A request is issued to cause an operation to be performed."

BD: Instances make requests by sendingmessages or invoking member functions. The term used depends on the implementationlanguage.

HA: "... [T]he basic model of communicationbetween objects is taken from Coleman et al. (1992). In this model, servicesare requested from a client object such that the provider of the serviceis directly named by the client. Information flow can be bi-directionalsuch that the result of a request is returned to the client. The communicationmechanism is synchronous. "

NA: Objects 'call' or 'invoke' featuresupon objects. See 2.3 messages.

featuresmatrix intro page