Xref: utzoo comp.databases:4265 comp.infosystems:32 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!xyzzy!aquila.DG.COM!harrism From: harrism@aquila.DG.COM (Mike Harris) Newsgroups: comp.databases,comp.infosystems Subject: Re: Client/Server processes and implementations Message-ID: <724@xyzzy.UUCP> Date: 28 Nov 89 15:16:47 GMT References: <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> Sender: usenet@xyzzy.UUCP Distribution: comp Lines: 100 In article , hargrove@harlie.sgi.com (Mark Hargrove) writes: > In-reply-to: harrism@aquila.DG.COM's message of 20 Nov 89 18:36:07 GMT > In article <510@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes: > >In article <7114@sybase.sybase.com>, forrest@phobos.sybase.com (Jon Forrest) writes: [edited.... ] > > Accounting, payroll, order entry, etc. aren't servers, they're *clients* of > a database server! > > > [harris's stuff about Airline reservation systems, Bank Tellers, etc] > > [Stuff about these being both servers [to users] [& clients of dbs ] > >I believe that people, all too often, think of a database server as the only > >type of server. Airline reservation systems, and Bank Teller applications are > >other examples of services that can (and do) benefit from the client-server > >architecture. They (not seen to you at the terminal) also will act as clients > >to a database server. > > What are you trying to get across here? Your first sentence puts forth a > proposition which is completely unconnected to the following sentences. > Open your eyes and look at the marketplace! My point is EXACTLY what I said and I will quote again: "I believe that people, all too often, think of a database server as the only type of server." Coonsider how the Airlines reservation system operates. (a CLASSIC high volume TP application). Bank Card & Credit Card validations systems are other similar examples. There are about 50,000 terminals out there. They are connected via complex com networks into the computing complex. The terminals are CLIENTS of [a heterogenous mix of] forms handling SERVERS. These packetize the requests and forward them to the reservations SERVERS suite of processes. These are managed by a TP manager. These in turn, are CLIENTS of the database, and also CLIENTS of the TICKET printers, etc. Theses systems provide not only database integrity,but that of ticket printing, screen recovery, etc. The database is but ONE of MANY parties to the commit. They are but ONE of MANY resources managed & corrdinated. Consider teller applications. The banks are VERY serious about being sure that you don't get $ from the machine unless they debit your account. The primary parties here are 1) the database, and 2) a process or service which guarantees delivery of the cash dispensing. Theses two participate in a JOINT commit protocal. Yes, often a database is ONE of the SERVERS consulted. Ever consider a nested heirarchy? We have a client server manager which doesn't force pure clients and pure servers. The applications which run under it can act as both clients and servers as required to get the job done. A database server is typically just one of many other servers participating in a unit of work. The servers (before the data managers) run very well, but they take advantage of our automatic load balancing. The application often needs more front end servers running than database servers. > > > > [Harris's comments about heterogenous server process mix] > > Huh? A server is just a process. Don't make the problem more difficult > than it is. There are facilities in all real OS's to allow an administrator > to schedule/prioritize a process. I agree that real OSs allow an administrator to do this. I have worked on several "real" OSs, & now, unfortunately, I am being paid to make some of the same stuff run on UNIX. I also heartily support threads (os especially). Unfortunately, we have applications that we want to sell on the UNIX platform. There is a considerable amount of $$ there & people want to spend it. If you want to sell into a marketplace you must meet it's immediate, or at worst, it's needs in the immediate future. The market isn't waiting for threads or powerful schedulers in UNIX. IT WANTS UNIX. This pains me also! So, for my target environment, I must do Multi servers, etc. A second point is that even if you have a powerful scheduler, It MIGHT be able to help on an MP HDW IFF the application mix is sufficiently balanced that the scheduler could be told to run servers on different CPUs, etc. Otherwise it commonly happens that a processor is idle (often >10% of the time even on a busy system) because there wasn't a second server to schedule against that cpu. You can't play the game if you don't have the equipment. [edited....; stuff from everybody about "This is one of the rudements of a client/server architecture."] & [a comment about my vision relative to the future, etc] Touchy, Touchy, Touchy! I heartily agree with distributed processing, threads, RPCS, multi's, pcs, heterogenous environments. I am not a stodgy old fart who wants to buy a bigg'n from IBM! I just take issue with people who aren't open enough or don't (but claim to) know enough about the marketplace to consider applications other then their own! Learn something about the common High Volume TP applications. Learn something about other peoples applications. Think about multi level CLIENT/SERVER applications. Imagine a world where everything was a PC. Somebody would say "You know, there are situations where a bigger machine which could hold more of (or all of) my application would be faster & more cost effective" And he would buy it from the people who could supply them. The proper machine environment depends upon the specific APPLICATION, not some general theories! "Money talks & bullshit walks." > hargrove regards, Mike Harris - KM4UL harrism@dg-rtp.dg.com Data General Corporation {world}!mcnc!rti!dg-rtp!harrism Research Triangle Park, NC Brought to you by Super Global Mega Corp .com