Browse Prior Art Database

Generating Specific Server Programs in Distributed Object-Oriented Customer Information Control System

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

Publishing Venue

IBM

Related People

Knapman, JM: AUTHOR

Abstract

When a customer needs to write a distributed object oriented application, the state of the art using IBM*'s Distributed System Object Model (DSOM) requires that he write one or more server programs to provide house keeping and management functions. In general, this is a difficult, even challenging, task, especially if transactional integrity is also required.

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

Generating Specific Server Programs in Distributed Object-Oriented
Customer Information Control System

      When a customer needs to write a distributed object oriented
application, the state of the art using IBM*'s Distributed System
Object Model (DSOM) requires that he write one or more server
programs to provide house keeping and management functions.  In
general, this is a difficult, even challenging, task, especially if
transactional integrity is also required.

      IBM's CICS* transaction processing software provides support
for distributed applications with transactional integrity, including
a considerable degree of resource management, but does not naturally
support distributed object oriented applications.  By natural support
is meant the ability, as in DSOM, to allow application programmers to
enjoy the flexibility and productivity of viewing remote, distributed
objects as if they were compiled in the local program.

      Because CICS already provides a great deal of housekeeping and
management service, an interface to these services is required,
rather than a complete implementation of a server program in the DSOM
sense.  Such an interface can be defined by making the crucial
connection between an object and traditional CICS application
programs.

      As shown in Fig. 1, a CICS application program may issue a LINK
command to other such programs which may pass state information
between each other using various temporary storage facilities that
CICS provides.  Parametric data is passed from the caller using an
area of storage known as the the COMMAREA.

      Data is passed in the COMMAREA rather than as parameters.  The
equivalent of invoking several methods on an object is to LINK to
several programs, passing saved state between them.  CICS provides
various means of doing this, from using part of the COMMAREA to
storing
in temporary queues or files.  There is no provision for callback.

      The object oriented view (Fig. 2) is that the client program
invokes the methods of an object (local or remote).  The state
information is encapsulated in the object and the programmer should
not be concerned with its management.  This is true both to the
programmer who writes the client program and the one who writes the
object.  Consequently, It should be a very simple change to alter an
application so that a remote object becomes local and vice versa.  In
practice, this means that the customer must write a server program
that instantiates and allocates storage for remote objects, and
performs other housekeeping services.

      In Fig. 2, 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 hel...