Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN
Network Working, Group                                P.M. Karp, MITRERequest for Comments #146                             D.B. McKay, IBMNIC 6742                                              D.C. Wood, MITRE                                                      12 May 1971Categories: D.4, D.7Obsoletes: noneUpdates: none                Views on Issues Relevant to Data Sharing                          on Computer NetworksIntroductionThe formation of a committee to address the problems of achievingdata sharing on the ARPA Network, as suggested by Arie Shoshani(RFC #140) is desirable at this point of network development.  Weconcur with Shoshani's ideas (presented in an introductory paperto the network data sharing meeting, scheduled for Tuesday, May 18)and believe that purpose of the committee should be -        a) to classify the issues involved and to propose various           approaches;        b) to integrate the hitherto independent network activities           that address problems in the area of data sharing, and;        c) to set up and coordinate appropriate experiments to test           the services developed and to evaluate alternative           approaches.This position paper is intended to augment Shoshani's as a basisfor discussion at the data sharing meeting. No attempt is madeto discuss specific means of implementation since many approachesto data handling problems are possible and have been proposed.Rather, our viewpoint on what the committee's role should be ingiving some cohesion to various existing implementations ispresented.                                                                [Page 1]

Our Views    One approach to achieving data sharing on the ARPA Network canbe thought of as having three stages, which roughly correspond tothe modes of use or operation. Within each stage are various levelsof development required to get to the next stage. This developmentis not necessarily sequential. A description of the three stagesfollows.Stage 1: Data handling services are provided at various Hosts.         The user talks directly to the serving Host (via TELNET         or by addressing a known socket) to explicitly access         the service.  This mode of operation corresponds to         Bhushan's category of "direct" usage (RFC #114).  The         data services provided by the serving Host range from         simple ones, such as White's file transfer system (RFC #122)         to sophisticated systems such as the CCA's data machine         (NIC 5791 and 6706).Stage 2: The user has access to an intermediate process or data         control facility* that routes his requests for a particular         data service to the serving system. The user must explicitly         identify the data services to the used.  This mode of         operation corresponds to Bhushan's category of "indirect"         access. The data control facility provides the necessary         control commands, data transformations, and accessing         methods. A single request would include the use of several         interacting services. For example, Heafner's Data         Reconfiguration Service (RFC #l38) could be used in         conjunction with the use of CCA's data machine._______________*The data control facility is not necessarily located at his localHost. Such a facility may exist on from one to all Host (i.e.,ranging from centralized to completely distributed).                                                                [Page 2]

Stage 3: The user treats the network as a single resource and is         unconcerned with the location of the services, data files,         etc. All references are by name. In this mode of opera-         tion, the data control facility can function as a referral         center for data service requests by using the most ap-         propriate data service available and by automatically         combining the use of several services that may be needed         to satisfy a request.  For example, data could be retrieved         from several files, each managed by a different data         management system. The data control facility must be         cognizant of the location of data files, their structure,         data management system capabilities, etc.Some approaches to the design of the data control facility havebeen suggested by Shoshani, notably the integrated data managementsystem (IDMS) and the unified data management system (UDMS). Thenotion of the network machine (RFC #51) is closest to the capabilitiesone would see in Stage 3.Relevant Areas of DevelopmentThe data control facility can range anywhere from a simple inter-face to an intelligent front-end processor to a network-wide re-ferral system.  In any case, a common means is desirable forhandling applications such as file transfer, on-line update andretrieval of data, information gathering and reporting, and programaccess to data. To attain this end, a few of the areas in whichdevelopments will be required include:     a)  a data description language, permitting the user to define         the physical structure of files, to define logical files,         and to categorize data fields for name referencing. The         language should be designed to facilitate the resolution of         physical discrepancies in data and file structures. The         user should be able to superimpose logical restructuring of         data without any change in the physical structure.                                                                [Page 3]

b) a control or access language that can be mapped into         various data management languages. Considered here is         Shoshani's suggested two-level approach with perhaps a         meta-language implementation to facilitate conversions         among already existing languages.     c)  methods for managing and merging distributed data, search         mechanisms for file directories, error recovery techniques,         etc.Independent ARPA Network activities that in effect constituteStage 1 have touched on these areas and should be incorporated intothe overall data sharing scheme such that all of the isolatedpieces are compatible.  For example,      a) the data reconfiguration service (RFC #138) would beinvoked by the data control facility whenever data transformationsare required.      b) the file transfer protocol (RFC #114, #122)should be consistent with other data handling services.      c) CCA's data machine should be a subset or part of any datacontrol facility. The network data language and set of datamanagement services that they plan to implement can perhaps beadopted network-wide.      d) the network machine concept (RFC #51) for defining the pro-gram and data environments should be resurrected. The data controlfacility should be a subset of a network machine architecture.Some other relevant topics include NIL (RFC #51), DEL (RFC 5), thenotion Of MYLOCAL n, YOUR LOCAL n, and STANDARD n (RFC #42), userlevel protocol objectives as described in RFC #76 and #91.                                                                [Page 4]

Experimentation and Testing---------------------------As data services are developed on the network, a coordinatedeffort is desirable     a)  to exercise individual implementations to see         if they work, both alone and in conjunction with         other data services, and     b)  to evaluate alternative approaches.Some examples of experimentation to test data services follow:     1.  File Transfer Protocol         The file transfer protocol should be used to         manipulate data files controlled by various         systems.     2.  Data Transfer to Data Computer         The ability to transfer existing data bases and         their structures onto the data computer should be         demonstrated.     3.  Data Restructuring         The ability to define logical restructuring of         data for users needs which would be accessible by         name should be demonstrated. The original physical         structure would be maintained.     4.  Data Transformation         The ability to access various data management         systems on the network without the user being         concerned with the data transformation involved         should be demonstrated. Necessary calls to forms         available on the Data Reconfiguration Service         should be handled automatically and should be         transparent to the user.                                                                [Page 5]

5.  Data Consistency         Problems of maintaining consistency when duplicate         copies of a data file exist and updates to the file         are made should be investigated. Automatic use of         file transfer protocol and DRS to generate new         duplicate copies should be included.     6.  Data Privacy         Access controls for privacy Of data files in the         network environment should be designed and evaluated.         This includes controls on parts of distributed files.Our recommendation is that the committee on data sharing beresponsible for coordinating development in these areas, forattempting to maintain consistency among data services, and fortesting services in a series of experiments as they are implemented.       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by BBN Corp. under the   ]       [ direction of Alex McKenzie.                   12/96   ]                                                                [Page 6]

[8]ページ先頭

©2009-2025 Movatter.jp