Method of modifying a protocol between distributed objects

Details Method of modifying a protocol between distributed objects Method of modifying a protocol between distributed objects

2000-04-14

2003-09-09

Follansbee, John (Department: 2126)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

Reexamination Certificate

active

06618765

ABSTRACT:

The present invention concerns a method of modifying a protocol between distributed objects in an environment based on an ORB (Object Request Broker) distributed object manager. One prior art ORB is the DCOM (Distributed Component Object Model) ORB.
BACKGROUND OF THE INVENTION
Many applications use an environment of the above kind. Examples are telecommunications or transport supervisory applications, applications constituting an intelligent network, etc.
In a distributed object environment, an application can use different servers to provide services to clients.
A client process is a program which uses services and a server process is a program which provides services to clients.
An object of the client process (a process which therefore corresponds to an instance of execution of a program) can solicit a service of the server by sending it a corresponding message. A corresponding object of the server executes the service and, if necessary, sends a response back to the client process object.
The invention addresses more particularly the transmission to the client object of notifications referred as call-backs. These are messages sent by a server object to a client object at the initiative of the server object when the client object has subscribed to a call-back service. A typical example of the use of a call-back service of this kind relates to supervisory applications in which clients wish to be informed of changes of properties of objects.
To subscribe to a server object service of this kind, a client object usually solicits an “advise” method of the server object. This method provides for the specification of parameters, in particular input parameters to enable the server object to call the client back when it has call-backs to send.
In practice, various protocols can be used to establish the call-back communications protocol.
In the particular case of a DCOM ORB, a simple mechanism can be used whereby, to enable the server object to call it back to send it a call-back, the client object, which has one or more input interfaces, supplies an input parameter to the server object at a subscription interface specific to that object and in the form of a pointer to one of its interfaces.
Another available mechanism is the connection points mechanism.
An ORB such as the DCOM ORB offers a standard mechanism referred to as the connectable objects mechanism to enable a client object to subscribe to a server object. In that mechanism, which is shown diagrammatically in
FIG. 1
, the server object which sends the call-backs, referred to as the connectable object, can support a connection point container interface.
In the example shown, the connectable server object S has a connection point container interface ICPC. Any client can request a particular connection point via this ICPC input interface.
In the example shown, a client object X has an input interface IS
1
and an input interface IS
2
. It can send to the connection point container interface ICPC of the server object S a request (
1
) for allocation of a connection point for a given protocol associated with its input interface IS
1
. If the server object S supports the given protocol, it creates a corresponding connection point object CP
1
. The connection point CP
1
has a connection point interface ICP
1
. The client object can then subscribe to the service by soliciting (
2
) the advise method of this interface ICP
1
of the connection point CP
1
. Thereafter, the connection point CP
1
sends (
3
) call-backs to the corresponding input interface IS
1
of the client object.
If it wishes to receive call-backs in a different protocol at its other input interface IS
2
, the client object can submit a connection point allocation request to the server object in respect of that protocol. The server object then creates a new connection point object CP
2
, if appropriate.
As shown in
FIG. 1
, the connectable object S and the connection points CP
1
, CP
2
are in practice often in the same object, in other words in the same class of the C++ language, even if their interfaces are separate.
Another available mechanism is that referred to as the custom marshaling mechanism. The skilled person is familiar with this marshaling mechanism in the particular context of the DCOM ORB. As shown diagrammatically in
FIG. 2
, the mechanism replaces a pair of standard representative elements of the object-object protocol used by the client object to subscribe to the server object, with a pair of personalized representative elements enabling use of a specific personalized communications protocol, such as the sockets shown in FIG.
2
.
In the well-known object-object protocol, when an object of a client process sends a message to a given object of a server process, the message passes through a pair of representative elements of the server object. This pair manages the corresponding interprocess calls in a manner which is transparent for the two remote objects, namely the client object and the server object. The pair includes a Proxy representative element of the server object in the client process and a corresponding Stub representative element in the server process.
The advantage of an object protocol of the above kind is that the objects do not need to know where the objects with which they exchange messages are located. With this protocol, the ORB conceals the location of the objects, as it were, which considerably simplifies access to the objects wherever they are located.
The Proxy element of the pair of representative elements includes all the interfaces of the server object.
The standard pairs of Proxy/Stub representative elements of these interfaces may not suit the client object, for example because they are not efficient enough.
The marshaling mechanism proposed by the ORB enables the use of a different interface.
The objects which enable the use of a mechanism of the above kind include a marshaling interface denoted IMarshal.
Accordingly, when the ORB detects that a new pair of Proxy elements is to be created for sending messages between two remote objects, it asks the message destination object if it supports a marshaling interface. If it does not support a marshaling interface, the ORB creates the standard pair of representative elements. If it does support a marshaling interface, the ORB creates a personalized pair of representative elements corresponding to the class of object specified by the destination object.
The personalized pair of representative elements completely replaces the standard pair of representative elements. In other words, it includes all the interfaces that the standard pair would include.
FIG. 2
is a simplified diagram showing the application of a mechanism of the above kind. The server object S has a marshaling interface IMarshal which enables the ORB to create a personalized pair of representative elements. The client object X sends its messages to the server S via this personalized pair, which is formed of a personalized proxy representative element CProxy(S) and a personalized Stub representative element CStub(S).
The two representative elements are personalized in the sense that they use a personalized interobject communications protocol corresponding to their class.
For example, a mechanism of the above kind is used in practice to implement a socket type communications protocol at the level of the personalized pair, for example with network connection if the two objects are on different machines or with shared memory if the two objects are on the same machine. This is symbolized in
FIG. 2
by the arrow indicating a socket connection.
The above mechanism has been applied in the prior art to implementing a cache. For example, the first time that the client object asks the name of the server object, the personalized Proxy element finds it and then retains it. Accordingly, it can subsequently supply the name directly, without sending any call to the server object.
The invention addresses the possibility of modifying protocols for the call-back service. The need to modify call-back protocols can become

Affiliated with

Also associated with

Rating

Method of modifying a protocol between distributed objects does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method of modifying a protocol between distributed objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of modifying a protocol between distributed objects will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3087090