Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Object Attributes on Demand in a Cooperative Processing Environment

IP.com Disclosure Number: IPCOM000113543D
Original Publication Date: 1994-Sep-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 208K

Publishing Venue

IBM

Related People

Duffield, DM: AUTHOR [+4]

Abstract

Described is a technique used when distributed objects are being created in a cooperative processing environment. This technique implements optimized attribute initialization of these distributed objects.

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

Object Attributes on Demand in a Cooperative Processing Environment

      Described is a technique used when distributed objects are
being created in a cooperative processing environment.  This
technique implements optimized attribute initialization of these
distributed objects.

      As shown in the Figure, the distributed objects use an
object-oriented paradigm, where the host's resources are represented
as objects on the Programmable Work Station (PWS).  These 'proxy'
objects represent the host resources through attributes (information
about the resource) and behaviors (actions that can be taken against
the host resource).  Fig. 1.  Problem Domain.  Representing a
distributed object representation (proxy object) of a host resource,
while hiding the complexity and volume of the host data access.

      In a typical data processing environment (for example, a single
computer system), the attributes of system resources such as files,
printers, users, etc, are easily accessible through host Application
Programming Interfaces (APIs) and commands.

      However, when trying to provide a distributed view of a
system's resource attributes, the situation is not so simple.  The
problems with accessing the remote host data for display are as
follows:
  o  There is a 'mega-data' problem.  Typically, there are hundreds
of
     separate attributes for a host resource object.  Transferring
all
     of this data to the PWS is a time and resource-consuming task,
     especially if a particular attribute may not be used.
  o  For each host object representation on the PWS, there may be
     different host API record formats, or even different APIs.  For
     example, attribute X may be available from host API
     'RetrieveSimpleStuff', while attribute Y may be available from
     host API 'RetrieveNotSoSimpleStuff'.  Forcing a programming user
     of the PWS object to distinguish between different host APIs and
     record formats is poor encapsulation.
  o  The problem is further complicated when list processing is
     involved.  Different host APIs are used to return lists of host
     resources and their attributes, versus returning only a single
     instance of the host object.  Often, the host list API returns
     less data (less attributes) about the resource.  This could
force
     a programmer to decide beforehand how a proxy object will handle
     the host data - either from a list API or a single API, and a
     'single' interface to the host resource from the proxy object
may
     be compromised.  For example, if the list API is used, a client
     may not have access to the full detail about the host resource,
     because all of the attributes have not been retrieved.

      The following describes a programming solution, where the end
users (clients) of the solution are other application programs:

      Our solutio...