Browse Prior Art Database

Client Server Algorithm for Distributed Libraries

IP.com Disclosure Number: IPCOM000109032D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 5 page(s) / 245K

Publishing Venue

IBM

Related People

Gladney, HM: AUTHOR

Abstract

Disclosed is a means of transaction management for distributed data applications when it is impractical to apply methods such as those imbedded in distributed database management systems.

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

Client Server Algorithm for Distributed Libraries

       Disclosed is a means of transaction management for
distributed data applications when it is impractical to apply methods
such as those imbedded in distributed database management systems.

      Distributed library services require that each patron be able
to use his favorite workstation to exploit libraries in whatever
computing environments library custodians choose.  This means that
simple, standard protocols should connect varied clients to varied
servers with varied communication protocols.  Atomic transactions are
needed to implement data integrity.

      The invention is a distributed algorithm.  The server part
ensures atomic actions for any blend of conversational and batch
sessions and protects against security violations.  The client part
allows each application both synchronous and asynchronous
interactions, buffering the application from behavior of the
communications vehicle.  Together, the two portions decouple
transaction boundaries from network message boundaries.

      The algorithm provides economical transaction management for
any distributed database application in which each "clump" of data
has a single point of control.
CLIENT/SERVER PROTOCOL

      Referring to the figure, each data service (Connect, Store,
Retrieve, ...) consists of a client part and a server part.  Each
client drives its server by a transmitted order, which stimulates a
reply.  A sequence of such orders is called a request and evokes a
response.  Valid requests conform to the abstract syntax:
      request       ::= step
      step          ::= initiator order
      initiator     ::= connect-order | prefix
      connect-order ::= patronid libraryid timestamp
      capability password
      prefix        ::= patronid libraryid timestamp
      capability
      order         ::= store-order | retrieve-order |
      transform-order
                        | ... |  commit-order
      commit-order  ::= commit | rollback
A response is a sequence of messages and results.
      response      ::= reply*
      reply         ::= message resultmessage     ::= class
      code [value]
      result        ::= code [value]
request  ::=  step: a request from a client is sequence of steps.
Its simplest form is a single conversational step.  However, a
request may be a batch with many orders which are partitioned into
individual transactions by commit orders.
step ::= initiator order: an initiator begins each step to identify
the patron for whom orders are being issued, the library which is to
be accessed, and the current value of the requestor's clock.  This
initiator is similar to a batch "job card".
initiator  ::=  connect-order | prefix:  an initiator can be either a
Connect invocation or a slightly shorter prefix.
order...