Browse Prior Art Database

Client Object Model for Distributed Servers

IP.com Disclosure Number: IPCOM000117944D
Original Publication Date: 1996-Jul-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 106K

Publishing Venue

IBM

Related People

Chamberlain, RN: AUTHOR [+2]

Abstract

In a distributed time-independent client-server (or message-driven) environment, a client application process can send request messages to remote servers and, in general, for each request message expect to receive multiple reply messages.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Client Object Model for Distributed Servers

      In a distributed time-independent client-server (or
message-driven) environment, a client application process can send
request messages to remote servers and, in general, for each request
message expect to receive multiple reply messages.

      The needs of the application may dictate that the client
process is never (or not always) blocked while it waits for replies
from servers and that consequently, an arbitrarily large number of
replies may be pending at any time.

      This introduces an administrative burden on a client
application to correlate each reply with its originating request and
deal with it appropriately.  The interleaving of requests with
replies can become complex especially when communication errors
occur.  Also, it cannot normally be assumed that messages (requests
or replies) will arrive in the same order they were sent.

      While procedural APIs for client programming provide mechanisms
for obtaining asynchronous replies to server requests they offer
little help with their administration or the appropriate structuring
of the client application.  These procedural mechanisms go under
names such as reply solicitation calls (with wait or nowait),
callbacks, correlation identifiers and message qualifiers.

      Various application-specific strategies may be needed to
determine when a particular client-server message-flow is complete,
for example
  o  Know how many replies to expect and just count them
  o  Find one flagged as the last, check the sequence number on it
      and continue till all earlier sequence numbers have arrived
  o  Time out
  o  Emulate a remote procedure call; additional, but orthogonal,
      effort is involved in (de) marshalling in/out parameters and
      the procedure name
  o  Terminate on one of a number of error conditions.

      The solution described here introduces the Flow class which
models a client-server message flow; that is, a request message sent
from the client to a server and any reply messages which are
returned, directly or indirectly.

      A Flow object encapsulates and provides a consistent interface
to the mechanisms of synchronization, correlation, message-flow state
and reply handling during the lifecycle of the client-server flow,
irrespective of the details of the underlying implementation, which
is completely hidden.

A Flow object supports one of three reply synchronization models
  o  Synchronous..the client process is blocked till the replies are
      received
  o  Deferred synchronous..the process continues with other work and
      at some point in the future actively seeks replies.
  o  Asynchronous..the process continues with other work but remains
      passively ready to be driven by the replies as they arrive.

   ...