Browse Prior Art Database

Distributed Object Encapsulation of Customer Information Control System Distributed Transaction Processing

IP.com Disclosure Number: IPCOM000114623D
Original Publication Date: 1995-Jan-01
Included in the Prior Art Database: 2005-Mar-29
Document File: 4 page(s) / 160K

Publishing Venue

IBM

Related People

Knapman, JM: AUTHOR

Abstract

The Object Management Group's CORBA object model provides a simple model of distributed processing in which remote processes are encapsulated as objects and appear as if they were local. IBM*'s Distributed System Object Model (DSOM) program provides this notion by creating local proxy objects that represent remote objects. The communication model thus provided is of synchronous invocation and return with the local and remote objects having continuing state as shown in Fig. 1.

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

Distributed Object Encapsulation of Customer Information Control
System Distributed Transaction Processing

      The Object Management Group's CORBA object model provides a
simple model of distributed processing in which remote processes are
encapsulated as objects and appear as if they were local.  IBM*'s
Distributed System Object Model (DSOM) program provides this notion
by creating local proxy objects that represent remote objects.  The
communication model thus provided is of synchronous invocation and
return with the local and remote objects having continuing state as
shown in Fig. 1.

      An object is denoted by a box with turrets.  The turrets
correspond to methods of the object, and hence comprise the object's
interface.

      A DSOM client program is expected to locate a server on which
the required object is implemented.  It is expected that the customer
or a third party will provide a repository (the implementation
repository) to help.  Programs such as IBM's CICS*, of course,
provides such services through various tables.

      The client program is presumably constructed as a number of
objects but that is not mandatory.

      DSOM builds a proxy object dynamically.  It has the same
interfaces as the remote object but interfaces to the sockets classes
and the Object Request Broker (ORB).  Hence the client program, after
the initial setup, sees the remote object as a local object.

      Marshalling and de-marshalling includes converting data types
between hardware platforms (RISC System/6000* and PS/2*) based on the
IBM SOM Interfaced Definitions Language (IDL) specifications stored
in the interface repository.  If an object is passed as a parameter,
it is converted to a remote reference so that the remote object can
invoke its methods back on the client program.  This is a form of
callback and is required to access any of the object's attributes.
Structures and simple types, however, are passed as data, which means
they are copied.

      One function of CICS, known as Distributed Transaction
Processing (DTP) based on SNA's APPC (LU 6.2), provides a somewhat
different communication model, namely half-duplex message passing
between pairs of processes, each having a continuing state.

In order to bridge between these two models, two things are required:
  1.  Converting method invocations to messages, which is the
       marshalling function providing by DSOM and is very similar to
       that needed for the COMMAREA storage in CICS Distributed
Program
       Link (DPL), another CICS function.
  2.  Providing a simple extension to the remote object model that
       allows half duplex.

      The need is for a simple, consistent extension so that a
customer gains the flexibility of being able to switch from DPL to
DTP, for example, or from a local to a distributed application with
the minimum of disruption.

      The half-duplex mode of communication impl...