home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0027.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  5.2 KB  |  144 lines
  1. Submitted-by: pc@hillside.co.uk (Peter Collinson)
  2.  
  3. USENIX Standards Watchdog Committee
  4. Stephen R. Walli <stephe@usenix.org>, Report Editor
  5.  
  6. The Proposed ROSE API
  7.  
  8.  
  9. David Cannon <D.Cannon@exeter.ac.uk> reports on the July 13-17, 1992
  10. meeting in Chicago, IL :
  11.  
  12. A project authorization request (PAR) has been submitted to the
  13. Distributed Systems Steering Committee (DSSC) for review, covering the
  14. Transparent Remote Operations Interface (TROI) proposal.  The first
  15. ROSE meeting presented the details of the proposal, and a second
  16. meeting on Friday, was a BOF on the technical content.
  17.  
  18. The presentation was led by JJ.Cinecoe and Dan Shia.  JJ.Cinecoe
  19. anticipated the obvious question of ``why do we need a Remote
  20. Operations Service Elements (ROSE) API?'' He proposed that the work of
  21. the TROI group was essential for two reasons:
  22.  
  23.    - it provides vendor OSI application portability,
  24.  
  25.    - there is a requirement by large corporate users who
  26.      want to write specialised applications which are needed
  27.      to be portable across multiple platforms.
  28.  
  29. ACSE (Association Control Service Element) is too complex for a
  30. user-programmable platform; ROSE is perceived to better fill the need,
  31. and offers a ``true'' peer-to-peer relationship with another
  32. end-system.
  33.  
  34. The purpose of the proposed project is to generate an IEEE API for the
  35. classes of operations defined by ROSE.  It is intended to co-locate
  36. meetings of the group with both the OSE Implementors Workshop (OIW)
  37. and the IEEE POSIX meetings.  If both of these options are used the
  38. group would be meeting on average every six weeks.  [ed. - The OSE in
  39. OIW is ``Open Systems Environment''. This is the NIST supported group,
  40. which used to meet as the OSI Implementors Workshop, and has recently
  41. had its scope expanded.]
  42.  
  43. A quick overview of ROSE vs. RPC:
  44.  
  45.    - RPCs tend to be very proprietary.
  46.  
  47.    - RPCs bundle together:
  48.  
  49.         - interaction semantics
  50.  
  51.         - data transfer
  52.  
  53.    - ROSE unbundles these and provides
  54.  
  55.         - a variety of synchronous and asynchronous classes
  56.           of operation.
  57.  
  58.         - transfer of user-defined data streams.
  59.  
  60.    - ROSE can provide an equivalent service to RPC across
  61.      different platforms.
  62.  
  63. Dan Shia described the Computing Environment on OSI (CEO), of which
  64. TROI is one component.  The aim is to enable the construction of
  65. highly efficient distributed concurrent systems by providing a very
  66. thin API over the top of the protocol engine, and is based on OSI ACSE
  67. (Association Control Service Element), ROSE and ASN.1 (Abstract Syntax
  68. Notation 1).
  69.  
  70. The proposal is based on experience gained from an implemented,
  71. working testbed.
  72.  
  73. Someone wanted to know what the difference was between this proposal
  74. and the POSIX.12 (Protocol Independent Interfaces) Simple Network
  75. Interface proposal.  Dan suggested that the main differences were
  76. user-defined data presentation and remote operation facilities.
  77.  
  78. Dan outlined the problems involved in using full ASN.1, which is
  79. unparseable, and went on to describe ASN.C.  This incorporates a
  80. simplified data definition language enabling the automatic creation of
  81. data objects, together with the ASN.1 data manipulation language and
  82. can be handled, for example, by a C language preprocessor.
  83.  
  84. The ASN.C specification allows data-object specification through
  85. statements which can be mapped on to functions or to extensions of the
  86. C language.  These could ultimately call XOMcreate to generate the
  87. data objects.  XOM is being standardized by the IEEE's P1224 working
  88. group, and is based on X/Open's Object Management API.
  89.  
  90. Someone asked whether XOM could do the work of encoding the ASN.1
  91. rules for a particular data-object.  Dan said it could for public
  92. objects, but wasn't very good at handling user- defined objects.
  93.  
  94. Dan went on to describe some RPC shortcomings, which include the
  95. inability to support:
  96.  
  97.    - all ASN.1 types
  98.  
  99.    - callbacks
  100.  
  101.    - multicast
  102.  
  103.    - peer-to-peer interactions
  104.  
  105. He also described some limitations of XAP and P1238, (the IEEE's FTAM
  106. working group,) including
  107.  
  108.    - over-complexity for applications writers
  109.  
  110.    - non-integrated naming service
  111.  
  112.    - non-integration of IPC and ITC (Inter-Thread
  113.      Communication) support.
  114.  
  115. He concluded that this led to the inherent attraction of the CEO
  116. system, which amongst others provides for:
  117.  
  118.    - RPC (blocking) support
  119.  
  120.    - Request/reply (non-blocking) support
  121.  
  122.    - Multiple underlying protocol stacks
  123.  
  124.    - peer-to-peer operations
  125.  
  126. The relatively high-level approach offers a number of plusses, for
  127. example a short training period, rapid OSI application development,
  128. the ability to port existing applications to the OSI environment, and
  129. suitability for development of server applications.
  130.  
  131. In summary TROI is an attractive proposition; the main problem from an
  132. IEEE viewpoint is that much of the elegance is dressed in extensions
  133. to languages - ASN.1, C and any other required language binding - and
  134. languages are not the province of TCOS-SS.  (TCOS-SS, the Technical
  135. Committee on Operating Systems - Standards Subcommittee, is the
  136. organizing group within the IEEE for the POSIX related standards
  137. efforts.) If they can be shown to be justifiable and useful the APIs
  138. could be worked under the TCOS umbrella, but there are some fears that
  139. the API work alone may not offer substantially more than P1003.12 and
  140. the XOM work.
  141.  
  142. Volume-Number: Volume 29, Number 28
  143.  
  144.