How do remote invocations work?
Figure 2 diagrams a remote invocation. In order to invoke the remote object instance, the client first obtains its object reference. (There are many ways to do this, but we won’t detail any of them here. Easy ways include the Naming Service and the Trader Service.) To make the remote invocation, the client uses the same code that it used in the local invocation we just described, substituting the object reference for the remote instance. When the ORB examines the object reference and discovers that the target object is remote, it routes the invocation out over the network to the remote object’s ORB. (Again we point out: for load balanced servers, this is an oversimplification.) How does this work? OMG has standardized this process at two key levels: First, the client knows the type of object it’s invoking (that it’s a shopping cart object, for instance), and the client stub and object skeleton are generated from the same IDL. This means that the client knows exactly which operations it
Figure 2 diagrams a remote invocation. In order to invoke the remote object instance, the client first obtains its object reference. (There are many ways to do this, but we won’t detail any of them here. Easy ways include the Naming Service and the Trader Service.) To make the remote invocation, the client uses the same code that it used in the local invocation we just described, substituting the object reference for the remote instance. When the ORB examines the object reference and discovers that the target object is remote, it routes the invocation out over the network to the remote object’s ORB. (Again we point out: for load balanced servers, this is an oversimplification.) Figure 2 How does this work? OMG has standardized this process at two key levels: First, the client knows the type of object it’s invoking (that it’s a shopping cart object, for instance), and the client stub and object skeleton are generated from the same IDL. This means that the client knows exactly which oper
