By Carl Malamud ran pare ~y p CearUl etwor gba eor VSAM file, DEC RMS file, or rela tional y terns...
2
------- - -- - -- - - -- -- --- -- -- - ---- ---- By Carl Malamud NITWOIIIUIlI8 DAT I Clearly, then, the distributed file ys- tern ia networking topic. But hat about the databa ? A an extension of the file tem, it gives programmers and users a higher-level environment with a more ad- vanced way of accessing data. Many rela- DATA COMMUNICATIONS 0 MAY 1990 0 provided by a native RMS driver. With a file protocol uch a DAP, programmer and users can issue the same command, appending a logical name that specifie where the data re ides (UHOST3::DISKl"). But DAP provides command transparency, not location transparency: Users must Imo at hich node of the net ork (and on hich di k drive) the data is located. Location transparency is furnished by DEC's Distributed File Service (DFS), the equivalent of Sun icrosystem Inco's twork File System (NFS). With DFS, all data can appear as a serle of logical disk drives or ubdirectories inde- pendent of any specific physical host. Given this capability, users can di tribute data throughout the ne ork. For example, help fit can be put on ODe m. chiDe, then made available to an u en on the network. H server breaks, the file can be put on another machine, and a name er notified, without modifying the logical ume known by users and a . . Thi kind of distributed file sy tern offers the ability to all data a logi- cal hole. No matter which . on the network a client· on, al a see the same files and logical identifiers. This is especially important on large networks that mu t serve ten of thou- sands of u r. It's impossible to as ign a workstation to each user-it' simply not cost-effective, and it' impossible to diet on hich computer a given user . going to work. Services like DFS and NFS enable users to see their fil , no matter which computer they happen to be on. (RMS), for instance, i the fil y tem on the VS operating y tem. RMS i re- ponsible for accepting a request for a fil operation from a client program u ing a logical id nillier ( uch as DISKl), map- ping it to a ph ical disk drive ( uch as DUAO), and then fulfilling the request. RMS al u a related program, Lock Manager, that decides there are DO confticting operation under way. On a single computer, there are thus t 0 mod- ules used for acce sing data: the file ys- tem and the lock manager. When remote machines (and re- source) are in olved in the DECnet envi- ronment, the Data Access Protocol (DAP) i used to extend the local services of RMS across a DECnet. The services provided by DAP are 'dentical to those TIA A NCY 'ACT There' no imple answer, but a common thread run through all relevant discu ions-transparency. Any service available lOCally needs to be transparently available throughout the De ork. Such tran parency com at two lev- els. The lower, command transparency, means the user hould be able to ork with a familiar command tructure hen accessing local and remote data. The high- er, location transparency, means the u r hould be unaware of the location of the data (see figure). That's essentially the goal of distributed applications. But the goal i just beginning to be achieved, and it involves t 0 application-level rvices that are central to distributed applications: database and distributed file systems. Let' tart with local file access. DEC's Record Management Service ran pare e p C earUl etwor g ne of the la t thing I do before hipping a book manuscript to my publi h- er i send out drafts to ex- pert in the networking in- du try to make sure I haven't made a total fool of myself. Last time around, one of my revie - er ,a pre-eminent authority on computer network , penciled the following com- ment next to my chapter on databases: .. ta networking topic ... delete?" My immediate response was to get on the phone to every other authority who e number I had to see if I wa as off the mark as thi reader eemed to think. But while I was soliciting econd opinion , I realized that if an indu try expert could fail to e how database were a networ - ing topic, then maybe the is ues were no as readily apparent aI first thought. To be fair, the issue does not imply involve databases. What needs to be as- se sed are the ways in which remote data acce to file and databa involve net- working concern .
Transcript of By Carl Malamud ran pare ~y p CearUl etwor gba eor VSAM file, DEC RMS file, or rela tional y terns...
------- - -- - -- - - 1\11'1~\IVI\\()f~l\I\(, \II'\\~ -- -- --- -- -- - ---- ----
By Carl Malamud
NITWOIIIUIlI8 DAT IClearly, then, the distributed file ys
tern i a networking topic. But hat aboutthe databa ? A an extension of the file
tem, it gives programmers and users ahigher-level environment with a more advanced way of accessing data. Many rela-
DATA COMMUNICATIONS 0 MAY 19900
provided by a native RMS driver.With a file protocol uch a DAP,
programmer and users can issue thesame command, appending a logical namethat specifie where the data re ides(UHOST3::DISKl"). But DAP providescommand transparency, not locationtransparency: Users must Imo at hichnode of the net ork (and on hich di kdrive) the data is located.
Location transparency is furnishedby DEC's Distributed File Service (DFS),the equivalent of Sun icrosystemInco's twork File System (NFS). WithDFS, all data can appear as a serle oflogical disk drives or ubdirectories independent of any specific physical host.
Given this capability, users can ditribute data throughout the ne ork. Forexample, help fit can be put on ODe m.chiDe, then made available to an uen on the network. H serverbreaks, the file can be put on anothermachine, and a name er notified,without modifying the logical umeknown by users and a . .
Thi kind of distributed file sy ternoffers the ability to all data a logi-cal hole. No matter which . onthe network a client· on, al asee the same files and logical identifiers.
This is especially important on largenetworks that mu t serve ten of thousands of u r. It's impossible to as ign aworkstation to each user-it' simply notcost-effective, and it' impossible to~diet on hich computer a given user .going to work. Services like DFS and NFSenable users to see their fil , no matterwhich computer they happen to be on.
(RMS), for instance, i the fil y tem onthe V S operating y tem. RMS i re-ponsible for accepting a request for a fil
operation from a client program u ing alogical id nillier ( uch as DISKl), mapping it to a ph ical disk drive ( uch asDUAO), and then fulfilling the request.
RMS al u a related program,Lock Manager, that decides there are DO
confticting operation under way. On asingle computer, there are thus t 0 modules used for acce sing data: the file ystem and the lock manager.
When remote machines (and resource) are in olved in the DECnet environment, the Data Access Protocol(DAP) i used to extend the local servicesof RMS across a DECnet. The servicesprovided by DAP are 'dentical to those
TIA A NCY 'ACTThere' no imple answer, but a
common thread run through all relevantdiscu ions-transparency. Any serviceavailable lOCally needs to be transparentlyavailable throughout the De ork.
Such tran parency com at two levels. The lower, command transparency,means the user hould be able to orkwith a familiar command tructure henaccessing local and remote data. The higher, location transparency, means the u rhould be unaware of the location of the
data (see figure). That's essentially thegoal of distributed applications. But thegoal i just beginning to be achieved, and itinvolves t 0 application-level rvicesthat are central to distributed applications:database and distributed file systems.
Let' tart with local file access.DEC's Record Management Service
ran pare ~y
e p CearUletwor g
ne of the la t thing I dobefore hipping a bookmanuscript to my publi her i send out drafts to expert in the networking indu try to make sure I
haven't made a total fool of myself.Last time around, one of my revie
er , a pre-eminent authority on computernetwork , penciled the following comment next to my chapter on databases:.. t a networking topic ... delete?"
My immediate response was to geton the phone to every other authoritywho e number I had to see if I wa as offthe mark as thi reader eemed to think.But while Iwas soliciting econd opinion ,I realized that if an indu try expert couldfail to e how database were a networ ing topic, then maybe the is ues were noas readily apparent a I first thought.
To be fair, the issue does not implyinvolve databases. What needs to be asse sed are the ways in which remote dataacce to file and databa involve networking concern .
------------ I\TI·H\I·v!'\\()Hhl\(, \ II'\\~ ----------- ---
e.t i a writer and con ultantbased in San Francisco and the author ofDEC Ntlworks a"d Arcltiltcl,.r,s(McGra -Hill, 1989) and IfIgm: ToolslorBuildi", an I"lorMalio" Arcltilecturt(Van ostrand Reinhold, 1989).
cy. AgaltJlJtlJ allo s a file ystem or databa to look like something else. The Ingre IdBa e Gateway product , forexample, make other ystem 100 like anIngre database. Hence, an IBM I Sda ba e or VSAM file, DEC RMS file, or relational y terns like DEC's ROB can an takepart in an Ingre distributed database.
A I said, there's no imple an wereBut di us ion like thi one help revealthat, viewed from a certain angl , evnything i a networking topic. In fact, uni n't far from the truth when it says uthen twork i the computer." But of course,when poorly implemented the application can re ult in a corollary to the Sunmotto: The network i the bottlenec •
herever th data i located. The repon e are then put back together to sat
i fy the u r requestWhil this architecture sound im
pie, there are some very difficult technical i ues-many of which are communication -related-that had to be addressedbefore distributed database became a rea1ity. Ju t deciding hat order to get theremote data is difficult. For one thing, thequery optimizer (the oftware that decid ho to rvic the reque t) ha totake into account the speed of differentmachine , the speed of net ork links, andhow much data will be returned u ing different processing trategi .
An equally difficult problem is ensuring the integrity of the data in a multitatement transaction. In a di tributed
database, locking bas to be extended toen ure the integrity of transactions thatmay be split across several machines.
There's one final level of databasefunctionality beyond location transparen-
tional databaand back end to be di tributed over thnet ork. Ingres! et, for in tance, I tfront and back ends be parated on networks running a variety of protocolsDECnet, TCP/IP, IBM' S ALU 6.2, tbios, and plain asynchronou lines.
Separating the front and back end termed client- erver databases-allowsu er to acce a remote databa e a longa they know which machine it' ph sicalI located on. with DEC' DAP, though,only command tran parency is deliver d.
But recent advance have yieldedthe di tributed database, which makemultiple database appear as if they erea ingle logical repo itory of data. In thecase of Ingre , that is accomplished by anan add-on program called Ingres/Star. Tothe application Ingres! tar 100 like onebig database server. The application request data using a tructured query language. Actually, th reque t is brokeninto a ries of maller requests and nt
world-wide. And llltacbrs to jncticaIlyany publk or pIme YIa RJ-lls orIII optiooI1lCOU1dc couplet
But «all, It glws you the 1dnI1~«speed and aa:uncy that come only111 modem: the~«coqxessioo for hJPr~ IDd theaxdidmcz« error corretUoo bdIta All in tbe palm «)QIfMod.
yoor data transmission requiremeoIsdon't haYe to ch2nBe Just becue you'~
00 the~. 'nle 1bddPort 24MJum.Cbss 5Modem giYes you high speed cbaacoqxessioo and error correctIoo in afullyporUbIe pacbae.
1be1bddPort 24OO1MNP 800IlQ5, battery lnduded. it's~to the pooIMting and..«life 00 thefOld. It adapIs to Bell and ccm staol:lIrds
CI'IIdemnd~ lac. W'O&DI'OIIT Iftd1'OUCHBAII
It's cmel~ for those. can'tIfford probImB.
Call us today for the dealer you:
800-541-0345.(In bt, 516-261-003.)
140DATA COMMUNICATIONS 0 MAY 1990
