What is received by an invoked method when an object is passed to it by reference.

6.11.1.6 Dynamic Method Invocation

Dynamic method invocation is used when the client object requests a service [by description] but does not know the specific object ID or class of object to satisfy the request. This supports runtime-configured applications where the relationships between components are not determined at design time, that is, components are not tightly coupled [see the discussion on component coupling in Chapter 5].

Figure 6.43 illustrates how dynamic method invocation takes place. The sequence of steps shown in the figure begins at the point where a client identifies a particular implementation object that it wishes to send a method invocation request to. The steps are as follows:

The client object sends the message to the dynamic method invocation utility.

The dynamic method invocation utility accesses an interface repository [a runtime database] that contains IDL descriptions of the methods associated with various objects. The dynamic method invocation utility identifies one or more objects that have methods that could satisfy the request.

The request is converted to IDL code and routed to those objects.

The IDL code is passed via the client-side ORB [for the client platform] to the network.

The message is passed over the network through the ORB core, using the GIOP and IIOP as with the static invocation mechanism.

The message is received by the client-side ORB [this time on the server-object's platform].

The message is passed via the object adapter to the appropriate object [which may need to be instantiated].

The object adapter searches the implementation repository to find an already running instance of the required server object or, otherwise, instantiates and registers the newly instantiated server object with the repository.

If the appropriate object on the server has an IDL skeleton, the message is passed via the server skeleton and thereby translated from IDL code into the message format of the target [server] object.

In the more complicated case, when the server object does not have an appropriate skeleton, the dynamic skeleton utility dynamically creates a skeleton for the server object and translates the IDL code into the message format of the target [server] object.

The server object receives the message and acts on it.

5.3.3 Invocation Table

Due to the asynchrony of the object adapter interface, the ORB has to keep a record of currently active method invocations. For this purpose it has a table of these method invocations. The table contains entries of the form [H, O, M, Tin, Tout], consisting of handle H, object reference O of the target object, method name M, thunk Tin for the input parameters, and [sometimes empty] thunk Tout for results.

Therefore, from the point of view of an ORB, a method invocation is executed in three steps. First the ORB accepts a method invocation from an invocation-generating component and forwards it to the invocation-executing component:

Acceptance of method invocation [O, M, Tin] via invoke.

Generation of a new handle H and entry of [H, O, M, Tin, NIL] in the invocation table.

Selection of component responsible for executing the invocation and transfer of the method invocation to this component.

H is returned as the result of invoke.

The component executing the invocation then processes the method invocation and notifies the ORB of the results of the method invocation:

Acceptance of Tout for the method invocation with handle H at the object adapter interface via answer_invoke.

Replacement of the associated entry [H, O, M, Tin, NIL] in the table of active method invocations with entry [H, O, M, Tin, Tout].

For the third and last step the component generating the invocation may use wait[{Hi}] to wait for the completion of one of the invocations indicated by the handles {Hi}. Internally the ORB then blocks until answer_invoke is invoked for one of the handles and then returns this handle to the caller. The component generating the invocation then uses results[H] to fetch the results of the method invocation with handle H at the invocation adapter interface:

Find entry with handle H in the invocation table.

Tout is returned as the result of invoke, and the entry with handle H is deleted from the invocation table.

Method invocation procedures

IV.D.1. Sequence Diagrams

Sequence diagrams describe interactions among objects by depicting the time ordering of method invocations. A sequence diagram consists of the following elements, as shown in Fig. 8:

Class role represents the roles the object plays. The objects at the top of the diagram represent class roles.

Lifeline represents the existence of an object over a period of time. A vertical dotted line extending from the object is used to denote a lifeline.

Activation represents the time during which an object is performing an operation. Thin rectangles placed on lifelines are used to denote activations.

Method invocation represents communication between objects. Horizontal arrows labeled with method calls are used to denote method invocations.

Suppose you have two classes named PrintableObject and Print. An object of the Print class is to print a Printable object to a printer. The Print class has a method printAnObject [Object o], which is invoked to print an object. After printing is finished, the Print object notifies the Printable Object by invoking the object's finished method. The interactions between the objects just described are illustrated in Fig. 9.

4 GENERATED PROGRAM

The generated program is a distributed program, running in a distributed memory environment [on a NOW]. Due to the tasks distribution and the nesting of parallelism, the generated program is not SPMD as it is the case when sequential programs are distributed using the Owner Computes rule.

Thus, the communication mechanisms we use take into account the fact that the processor which owns an object does not know when this object is accessed and which processor generates the access. On each processor, a thread [distinct from the local computing thread] manages remote creation and remote method invocation on local fragments of objects; both operations are implemented with the standard Java RMI package.

We also take into account the fact that parameter passing is different in the Java environment depending on whether the method invocation is local or remote. In a local method invocation, parameter is passed by reference [the caller and the method called have a reference on the same object], whereas in a remote method invocation, parameters are passed by remote copy when the parameter is not a remote object. To keep the same parameter passing semantics in a distributed memory and in a shared memory environment, we are faced with two options:

to implement parameter passing by remote reference, by passing a proxy as a parameter, allowing the method called to access the object by RMI;

to pass parameters by remote copy [at method call and return], and then to manage the coherence of accesses to distinct copies of the same object.

In the first prototype, the first option has been chosen because it is easier to implement, but for efficiency reasons both approaches should be used.

9.3.3 HTTP Requests

All Pachube requests between clients and servers are performed by using HTTP requests. As previously discussed, the REST architecture uses HTTP request types for different types of method invocations and Pachube is no different. Pachube uses four different HTTP request types for its operations: GET, PUT, POST, and DELETE. The different requests are used on different occasions:

GET: This request method is used to retrieve sensor data from a Pachube server. With a GET request, the URI provided as part of the request contains both the identity of the data feed and the client’s data format. The URI contains information about the type of data the client wants to receive, the identity of the feed, and what data format the client wants. The identity of the data feed is given as the directory part of the HTTP URI, whereas the data format is provided as a file extension.

PUT: This method is used when submitting new sensor data to the Pachube server. Data to be submitted from the client to the server are provided in the data portion of the HTTP request, which follows the HTTP header. As with the GET request, the feed identity and the data format are included in the HTTP URI that is sent together with the HTTP request.

POST: This request method is used to create a feed and to create a new data stream within a previously established feed. The body of the HTTP request sent by the client contains the definition of the feed or the data stream. The definition is provided in EEML format. When establishing a stream, the server creates a stream into which the client may use the PUT method to insert data.

DELETE: This request method is used to delete a data feed or a data stream. The URI provided with the request contains the identifier of the feed or stream. Once a feed or stream has been deleted, it cannot be restored.

5.3.2 Potential Causes

3.6.1 Histories

We model the observable behavior of an execution of a concurrent system by a sequence of events called a history, where an event is an invocation or response of a method. We write a method invocation as 〈x.m[a⁎]A〉, where x is an object, m is a method name, a⁎ is a sequence of arguments, and A is a thread. We write a method response as 〈x:t [r⁎]A〉, where t is either OK or an exception name, and r⁎ is a sequence of result values.

An invocation and a response match if they name the same object and thread. An invocation in H is pending if no matching response follows the invocation. A method call in a history H is a pair consisting of an invocation and either the next matching response in H or a special ⊥ value [pronounced “bottom”] if the invocation is pending [i.e., if there is no subsequent matching response]. We say that a method call is pending if its invocation is pending, and that it is complete otherwise. A history is complete if all its method calls are complete. For a history H, we denote the subsequence of H consisting of all events of complete method calls [i.e., eliding all the pending invocations of H] by complete [H].

The interval of a method call in a history H is the history's sequence of events starting from its invocation and ending with its response, or the suffix of H starting from its invocation if the method call is pending. Two method calls overlap if their intervals overlap.

A history is sequential if its first event is an invocation, and each invocation, except possibly the last, is followed immediately by a matching response, and each response is immediately preceded by an invocation. No method calls overlap in a sequential history, and a sequential history has at most one pending invocation.

A subhistory of a history H is a subsequence of H. Sometimes we focus on a single thread or object: A thread subhistory, H|A [“H at A”], of a history H is the subsequence of all events in H whose thread names are A. An object subhistory H|x is similarly defined for an object x. We require each thread to complete each method call before calling another method: A history H is well formed if each thread subhistory is sequential. Henceforth, we consider only well-formed histories. Although thread subhistories of a well-formed history are always sequential, object subhistories need not be; method calls to the same object may overlap in a well-formed history. Finally, because what matters in the end is how each thread views the history, we say that two histories are equivalent if every thread has the same thread subhistory in both histories; that is, H and H′ are equivalent if H|A=H′|A for every thread A.

How can we tell whether a concurrent object is correct? Or, said differently, how do we define correctness for a concurrent object? The basic idea is to require a concurrent execution to be equivalent, in some sense, to some sequential history; the exact sense of equivalence is different for different correctness properties. We assume that we can tell whether a sequential object is correct, that is, whether a sequential object history is a legal history for the object's class. A sequential specification for an object is just a set of legal sequential histories for the object. A sequential history H is legal if each object subhistory is legal for that object.

A method m of an object x is total if for every finite complete history H in the sequential specification of x and every invocation 〈x.m[a⁎]A〉 of m, there is a response 〈x:t[r⁎]A〉 such that H⋅〈x.m[a⁎]A〉⋅〈x:t[r⁎]A〉 is in the sequential specification of x. A method is partial if it is not total.

7.2.1 Object Management

When seen from the client side, an object is in either of two states: requests can be processed, or they can't. In the former case, the client will receive the expected result; in the latter case, it gets an OBJ_NOT_EXIST exception.

On the server side, an object's state is more fine-grained. There is a total of four states that an object adapter can associate with a CORBA object, as shown in Figure 7.1.

An object begins and ends its life cycle in the nonexistent state. In this state, an object adapter has no information about an object. This state is left during object creation and reentered by object destruction.

During creation, the object adapter is made aware of an object's identity, and the object enters the inactive state. Once an object is created, the object adapter is able to generate and export object references. However, clients are unable to distinguish between inactive and nonexistent objects, as the object is still unable to receive method invocations.

Activation makes an object accessible by clients. In the ethereal state, an object is ready to receive requests, but there is yet no servant associated with the object. In the case of incoming method invocations, object adapters have different options for treating the request:

Rejection: The invocation is rejected with an error message.

Holding: The invocation is deferred. If the object becomes active, the invocation is executed; if the object becomes inactive, it is rejected.

On-demand activation: An object adapter could actively invoke some user callback code to incarnate a servant for activation.

Incarnation associates an ethereal object with a servant. Method invocations can now be executed.

Note that transitions between these states need not be distinct. In fact, this is the more common case. Usually, creation, activation, and incarnation happen at the same time, and later, objects are usually etherealized and deactivated simultaneously. Frequently, the ethereal state is not considered, and in many terminologies, “activation” implicitly includes incarnation, and “deactivation” implicitly includes etherealization.

Common difference in “activation” terminology

As another dimension of object state, objects can be characterized as being transient or persistent. Even though this distinction is made at the object adapter level, it is more commonly associated with the object itself. An object is called persistent if and only if the object adapter is persistent—and likewise for transience.

Transient versus persistent objects

The life cycle of transient object adapters and of the transient objects it holds is bounded by the life cycle of the server process they were created by. If the server process is terminated, all its transient object adapters and transient objects are implicitly destroyed. Persistent objects, however, are implicitly deactivated when the server process is terminated, but not destructed. Therefore, it is possible to reactivate persistent objects when the server restarts.

Persistent objects allow a servant to evolve or migrate, ideally without interruption in service.

Signals and Slots

Communication between objects in Qt is achieved by the use of a novel mechanism based on signals and slots. This idea is best motivated by considering the relationship between GUI events, such as button clicks, and the corresponding object method invocation to carry out the activity associated with the event.

The typical way of relating GUI events to method invocations is to use callback functions. With a callback function, a pointer to the method is registered with the GUI object; this method is invoked in the GUI handler code. A major drawback of this approach is the lack of parameter checking: with this method, there is no language-based method available to verify that the GUI handler code provides the right typed parameters to the callback function.

To address this, Qt uses signals and slots. A slot is the name of a function that can be invoked at runtime [such as the name of class method]; a signal corresponds to an event that invokes slots that have been connected to it. The standard QObject::connect[] method is used to connect one object’s signal to another object’s slot. This connect method makes all the difference: it gives the system the opportunity to enforce parameter correctness.

To see how this works, consider the specific example of a basic Qt application illustrating slots and signals shown below.

1 #include

2 #include

3

4 int main[int argc, char ∗argv[]]

5 {

6    QApplication a[argc, argv];

7

8    QPushButton quitButton["Quit"];

9

10   QVBoxLayout layout;

11   layout.addWidget[&quitButton];

12

13   QWidget window;

14   window.setLayout[&layout];

15

16   QObject::connect[&quitButton,

17            SIGNAL[clicked[]],

18            &a, SLOT[quit[]]];

19

20   window.show[];

21

22   return a.exec[];

23 }

In this example, the QtGui and QApplication modules are used to create an application containing a window and a single button widget. The QVBoxLayout class arranges all widgets assigned to the layout object on a single vertical column.

On line 16, the clicked[] signal of the button object is connected to the quit[] slot of the application object.

Aside from illustrating a generic use of slots and signals, this example also represents a complete and portable stand-alone Qt application. Of course, few interesting applications will be implemented in a single source document. For genuine code development, we now consider the Qt development environment.

8.2 DYNAMIC INVOCATION INTERFACE

The Dynamic Invocation Interface is the interface of the dynamic invocation adapter specified by CORBA. It is used to invoke methods on objects for which no stubs are available in the application [e.g., to implement a bridge that works for all object types].

The main components of a DII are Request objects that represent a method invocation, the name of the method being invoked, the object reference of the target object, and the parameters.

When a method invocation is executed over the DII, all parameters of the method invocation are packaged into Anys and conveyed along with the object reference of the target object and the method name to the DII. An example of this is the interface Account, which models a bank account and includes deposit, withdrawal, and balance display operations:

The following C++ code piece shows the invocation of the method deposit [100] using DII:

The invocation of_request[] on the target object of the method invocation with the name of the method being invoked used as the parameter produces a new Request object. This Request object represents the DII method invocation. The input parameter amount is added to the list of parameters through the use of add_in_arg[]. The invocation returns a reference to an Any object in which the value 100 is inserted via the overloaded operator = operators.] The invocation of invoke[] transfers the method invocation to the ORB and then blocks until the method invocation has been processed.