NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/std/unix/416

Internet Message Format | 1992-09-09 | 5.7 KB

Path: sparky!uunet!uunet!not-for-mail
From: [e-mail] (Peter Collinson)
Newsgroups: comp.std.unix
Subject: Standards Update, The Proposed ROSE API
Date: 9 Sep 1992 14:37:05 -0700
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Lines: 142
Sender: [e-mail]
Approved: [e-mail] (Moderator, Sean Eric Fagan)
Message-ID: <[e-mail]>
NNTP-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor

The Proposed ROSE API


David Cannon <[e-mail]> reports on the July 13-17, 1992
meeting in Chicago, IL :

A project authorization request (PAR) has been submitted to the
Distributed Systems Steering Committee (DSSC) for review, covering the
Transparent Remote Operations Interface (TROI) proposal.  The first
ROSE meeting presented the details of the proposal, and a second
meeting on Friday, was a BOF on the technical content.

The presentation was led by JJ.Cinecoe and Dan Shia.  JJ.Cinecoe
anticipated the obvious question of ``why do we need a Remote
Operations Service Elements (ROSE) API?'' He proposed that the work of
the TROI group was essential for two reasons:

   - it provides vendor OSI application portability,

   - there is a requirement by large corporate users who
     want to write specialised applications which are needed
     to be portable across multiple platforms.

ACSE (Association Control Service Element) is too complex for a
user-programmable platform; ROSE is perceived to better fill the need,
and offers a ``true'' peer-to-peer relationship with another
end-system.

The purpose of the proposed project is to generate an IEEE API for the
classes of operations defined by ROSE.  It is intended to co-locate
meetings of the group with both the OSE Implementors Workshop (OIW)
and the IEEE POSIX meetings.  If both of these options are used the
group would be meeting on average every six weeks.  [ed. - The OSE in
OIW is ``Open Systems Environment''. This is the NIST supported group,
which used to meet as the OSI Implementors Workshop, and has recently
had its scope expanded.]

A quick overview of ROSE vs. RPC:

   - RPCs tend to be very proprietary.

   - RPCs bundle together:

        - interaction semantics

        - data transfer

   - ROSE unbundles these and provides

        - a variety of synchronous and asynchronous classes
          of operation.

        - transfer of user-defined data streams.

   - ROSE can provide an equivalent service to RPC across
     different platforms.

Dan Shia described the Computing Environment on OSI (CEO), of which
TROI is one component.  The aim is to enable the construction of
highly efficient distributed concurrent systems by providing a very
thin API over the top of the protocol engine, and is based on OSI ACSE
(Association Control Service Element), ROSE and ASN.1 (Abstract Syntax
Notation 1).

The proposal is based on experience gained from an implemented,
working testbed.

Someone wanted to know what the difference was between this proposal
and the POSIX.12 (Protocol Independent Interfaces) Simple Network
Interface proposal.  Dan suggested that the main differences were
user-defined data presentation and remote operation facilities.

Dan outlined the problems involved in using full ASN.1, which is
unparseable, and went on to describe ASN.C.  This incorporates a
simplified data definition language enabling the automatic creation of
data objects, together with the ASN.1 data manipulation language and
can be handled, for example, by a C language preprocessor.

The ASN.C specification allows data-object specification through
statements which can be mapped on to functions or to extensions of the
C language.  These could ultimately call XOMcreate to generate the
data objects.  XOM is being standardized by the IEEE's P1224 working
group, and is based on X/Open's Object Management API.

Someone asked whether XOM could do the work of encoding the ASN.1
rules for a particular data-object.  Dan said it could for public
objects, but wasn't very good at handling user- defined objects.

Dan went on to describe some RPC shortcomings, which include the
inability to support:

   - all ASN.1 types

   - callbacks

   - multicast

   - peer-to-peer interactions

He also described some limitations of XAP and P1238, (the IEEE's FTAM
working group,) including

   - over-complexity for applications writers

   - non-integrated naming service

   - non-integration of IPC and ITC (Inter-Thread
     Communication) support.

He concluded that this led to the inherent attraction of the CEO
system, which amongst others provides for:

   - RPC (blocking) support

   - Request/reply (non-blocking) support

   - Multiple underlying protocol stacks

   - peer-to-peer operations

The relatively high-level approach offers a number of plusses, for
example a short training period, rapid OSI application development,
the ability to port existing applications to the OSI environment, and
suitability for development of server applications.

In summary TROI is an attractive proposition; the main problem from an
IEEE viewpoint is that much of the elegance is dressed in extensions
to languages - ASN.1, C and any other required language binding - and
languages are not the province of TCOS-SS.  (TCOS-SS, the Technical
Committee on Operating Systems - Standards Subcommittee, is the
organizing group within the IEEE for the POSIX related standards
efforts.) If they can be shown to be justifiable and useful the APIs
could be worked under the TCOS umbrella, but there are some fears that
the API work alone may not offer substantially more than P1003.12 and
the XOM work.

Volume-Number: Volume 29, Number 28