Thread View: comp.client-server
5 messages
5 total messages
Started by Keith J. Anderson
Thu, 08 Oct 1992 15:26
My personal ideas on Client/Server software architecture style
Author: Keith J. Anderson
Date: Thu, 08 Oct 1992 15:26
Date: Thu, 08 Oct 1992 15:26
553 lines
17241 bytes
17241 bytes
Based on some reading I did over a few months. I gave a similar paper at DECUS
Symposia in Australia and New Zealand.
Client/Server Technologies
Keith Anderson
Digital Equipment Corporation (Australia) P/L
August 1992 (extract for News Oct 92)
Marketplace and Client-Server
Trends*
. Client-server will grow at 3 times the rate of the
overall computer market
o C.A.G.R. of 27% over next 5 years
. Setup of client-server applications tends to add more
costs to IS
o additional complexity in GUI
o additional complexity in splitting the application
across systems
o complexity of systems management across large
numbers of heterogeneous platforms
. Result is significant gain for end-user department
o easier-to-use applications
o quicker access to data
o empowerment of end-user, do own programming
*5th Gartner Group Software Engineering Strategies
Conference 1992
Read-only applications
Significant area*
. Gartner Group says that 80% of todays application
backlog consists of read-only reporting applications
-which can be mainly developed and run by the
end-user department itself
3 Scenarios for Shift to Client-Server
by Gartner Group
. Bottoms-up Revolution
o PC LANs are the center of all future computing, even
mission-critical, enterprise-wide production work.
o Power to the (end-user) people.
o Mainframes and midrange systems are irrelevant (complex,
inaccessible, cost).
o p = 0.2
. Top-down Evolution
o Mainframe vendors and ISVs will transform mainframes into
enterprise servers.
o PCs for UI, mainframes for central control, and data and
application servers.
o Slow migration to ease pain.
o p = 0.2
. Middle-out Integration
o Mainframes overpriced, archaic; PCs unreliable and uncontrollable:
neither suitable focal point.
o C/S predicated on software interfaces, protocols, and network
services; with local server more powerful than PCs and
coordinating access to legacy mainframes and other network
services.
o p = 0.6
1. Bottom-Up Revolution
PC Scenario
. Premise
o Commodity makes PC least expensive.
o Replace big systems by spreading work across many clients and
servers.
. Ideology
o End users, not IS, should control computer
. Architectural Stress
o Client-dominated
o Applications run on desktop
o End-users and their PCs control data integration and access to
legacy systems and other servers
. Key Software Technologies
o Windows
o PC LANs
o Information At Your Fingertips
. Biggest Contributions
o GUIs
o demythologised computing
o normal people can use systems
. Blind Spots
o Production work demands formal system management: backup, central
data administration, cross-enterprise consistency and integration
o $/MIPS is a minor issue
. Directions
o Re-implementing traditional computer science technologies
o developing de-facto standards for cross-vendor interoperability
. Conclusion
o PC LAN applications will not prove scalable enough to replace
legacy systems as network computing applications and tools enter
the same market sectors (p = 0.7)
2. Top-down Evolution
Mainframe Scenario
. Premise
o Users cannot afford to throw away investments in existing
applications and databases
o Mainframe architectures can be extended to incorporate
client/server concepts
. Ideology
o Only IS and traditional mainframe vendors understand how to do
real computing
. Architectural Stress
o Mainframe-centric
o Desktop clients run just the front-end presentation
o applications, data, control remain on server
. Key Software Technologies
o IBM's APPC/MVS, CICS, SAA, SNA
. Biggest Contributions
o Forty years of learning about support, system management, change
control, backup and recovery, security, chargeback and central
data administration
. Blind Spots
o Overlooks role of
- local servers and LAN processing
- advantages of downsizing
- need of end-user involvement
- possibilities for faster adoption of new technology
- growing user intolerance for high vendor profit margins and
lock-ins
. Directions
o Adding standardised communication functions to existing operating
systems and middleware
o Developing centralised system/network management facilities
o flattening hierarchical networks with peer-to-peer communication
. Conclusion
o The gradual migration of data and processing off the traditional
mainframes is irreversible and permanent. In 1996, more than 98%
of *server* MIPS sold will be other systems (p = 0.8)
3. Middle-out Integration
Midrange Scenario
. Premise
o The local server must be a full-fledged computer, cheaper than a
traditional mainframe, but more functional than a traditional
Network operating system server (PC LAN server)
. Ideology
o Industry standards will make interoperability transparent,
seamless and easy
. Architectural Stress
o The network is the system. Only the software interface between
clients and servers ("glueware") really matters.
o Flexible regarding location of applications and data
. Key Software Technologies
o DEC's NAS, HP's NCS, OSF's DCE, USL's ATLAS
. Biggest Contributions
o The open systems movement as a means to formalise interfaces
o object-oriented programming
o technical workstation technology
o worldwide LANs!
. Blind Spots
o Has no champion with budget power in the user organisation (not
the end-user department or central IS)
o targets an "unobtainable" level of interoperability and consistency
. Directions
o Building bridges and gateways to integrate heterogeneous:
- operating systems
- DBMS
- windowing systems
- RPCs
- and other middleware
. Conclusion
o Software-based, middle-out, client/server principles will dominate
user architectural decisions from 1992 through 1996 because of the
need to integrate dissimilar desktops and servers. p = 0.6
Client/Server : basic concepts and categories
. Traditional Client/Server Models
(picture showing that networks can be placed in various places, leading
to a different piece of software taking on the role of the client/server
actions, and the handshaking required for 2 level communications.)
o Distributed and Remote Presentation
Examples: Motif, X, eXcursion
The presentation layer takes over the role of separating user desktop
from location of server. In common use now in X and Motif based
worlds.
o Remote Data Access, Distributed Database
Examples: Examples:
Dynamic SQL, the "STAR"
SAG & RDA products
With the standardisation of a SQL for use across
networks, this is the most rapid area of software product
growth at present. Many products now give desktop user ability to
build a frontend "application" that can access remote databases.
Historically products have been tied to proprietary implementations of
SQL, but the SAG/RDA work is major standards influence. Note ODBC.
o Distributed Function
Examples:
DEC ACA Services, DECmessageQ, OSF DCE
Biggest growth area for future : application talking to application.
. Range of Distributed Function
o Different levels of abstraction
. Remote Procedure Call
o invoke a remote procedure
-e.g. RPC in OSF DCE
. Message Passing
o Messages:
-transfer of information between processes
-processes may be separated by time
-some common support needs include store-and-forward, queuing
models, synchronous or asynchronous sending
. Distributed Objects
o Messaging using an object-oriented paradigm
o A major area of software innovation
Distributed Function - Remote Procedure Call
. Mechanism for transfer of control and data on a heterogeneous
network
. Provides the "look and feel" of a local procedure call
. Hides network complexity
. One component of OSF's DCE
. DCE Starter kit available now for ULTRIX, DEC OSF/1
. Huge number of vendors likely to provide DCE support
. Many other APIs for RPC style applications: eg MIA STDL for
transaction processing
Distributed Function - Message-based Applications
. Implement a message queuing bus
. Wider functionality than the standard RPC possible (may layer on
RPC):
o file transfers
o message queues
o peer-to-peer communication
o store-and-forward
o conversations/dialogues
o multiple broadcast
o asynchronous nature
o priority queuing
o selective reception
. Higher level of abstraction than RPC, but still high speed
. Example: DECmessageQ provides support for messaging applications on
VMS, ULTRIX, MS-DOS, MacIntosh, HP-UX, SunOS, System V, and LU6.2
support.
Distributed Function - Object Request Broker
. More generalised messaging - applications services are Objects
. Typical demands for an Object Request Broker:
o Interprocess communication
- transparent location of servers, selection of transport, and
management of communication sessions
- complete data abstraction services
o Abstraction
- Clients view application in terms of functional interfaces which
are independent of implementation technology
o Encapsulation
- Application interface is separated from implementation
- Implementation details are hidden and can be changed independent
of interface
o Reuse
- Interface or implementation elements
. Define applications/objects known, and broker "takes care" of
finding and invoking
o Static or Dynamic "linking/binding" of independently developed
applications and services
o Use concepts of inheritance, encapsulation, information-hiding -
so client does not know what server is, how server does function,
or server data format
o Can use legacy applications
o Higher level of abstraction than traditional messaging systems
- can layer on RPC and messaging systems
Distributed Function - Object Request Broker: ACA Services
. Digital's set of products : ACA Services V2.1
o Initial Digital work was ACA Services V1, known as "LiveLinks"
(DECwrite, DECdecision)
o Object Management Group CORBA specification
o DEC ACA Services V2 received award from Digital Review for "Best
Software"
o Now supports clients on servers on VMS, ULTRIX, SunOS, and clients
on MS Windows 3.
o Integration via DEC @aGlance with Excel and other PC products, for
Computer Integrated Manufacturing data collection and analysis
. Can be used with existing applications
o Four methods of invoking objects/applications:
-application invocation
-application command line invocation
-application API integration
-application source code modification
o Can define objects that use server shell (e.g. DCL or UN*X shell
commands or procedures), pass parameters
o Provides location transparency to programmer
o Provides seamless data interchange
o Independence from hardware/software platform, networking protocol
Traditional Client/Server Distributed Applications
Summary of Traditional Models
(picture showing various 2 level models, placing network in different places:
between presentation, data, applications). Note that the client and the server
see each other and handshaking is required. Also note that the definition of
what is a client and what is a server is relative to where the work requestor
is.
Another Model - A Three-level Client-Server Model*
. "Glueware" becomes a level
o Messaging and distribution management
o Often, clients and servers cannot see each other
. The three levels
o Client
o Message management
o Server
. Benefits:
o Decoupling of client and server systems possible
o Scalability of systems
o Parallel servers, transparent to clients
*"The Three-level Client/Server Model", W. Melling, Gartner Group
Midrange Computing Strategies, Reseach Note T-290-1155, March 13,
1992.
*"How to Grow Reliable Systems (Without Buying Bigger and BIGGER
Computers)", DECUS Paper 1990, Chris Thornhill, Australian Stock
Exchange Ltd
Message Management Level Functions
. Message switching
o Traditional address-based or Content-based switching
o Synchronous or asynchronous
. Security authentication
o Additional level of security above that of OS's, DBMS's
o Can be invisible to applications programmers
. Transaction-integrity control
o permits heterogeneous platform transaction management
o control transactions between client and server, across multiple
operating systems, databases, non-database resources
. Distributed-database transparency management
o Client does not know if data is partitioned or where partitions
are located
o Can partition database arbitrarily across multiple servers
. Recovery management
o Journalling and Resubmission of transactions
o resychronisation of databases after server failure
. Fault Tolerance
o Transparent support for multiple networks
o multiple message managGlue
o shadow and standby servers
o standard hardware and operating system components
Example of Message Manager :
DEC Reliable Transaction Router
. VMS server available
. Clients for VMS, ULTRIX, MS-DOS available
. Reference site Australian Stock Exchange
o See Chris Thornhill's DECUS papers
NAS Services
Software Architecture
. Network Application Support architecture consists of:
o Middleware Services
o Frameworks
o Applications & Tools
o User Interfaces
. Middleware Services:
o Presentation Services
-user interface
o Communication and Control Services
-application and network control
o Information Services
-data and information across network
o Computation Services
-network wide services
o Management Services
-common management
-------------------------------------------------------------------------------
EM: anderson@bigun.enet.dec.com Keith J. Anderson
or anderson%bigun.enet@decwrl.dec.com CASE and Information Management
Phone: (+61 6) 2754800 Digital Equipment Corp (Aust) P/L
FAX : (+61 6) 2473654 7 Barry Drive, Turner ACT 2601 AUSTRALIA
X.400: c=au;a=otc;p=digital;o=digital;ou=sno;s=anderson;g=keith
***** My words are not those of my employer *****
Re: My personal ideas on Client/Server
Author: Lawrence D'Oliveiro, Waikato Uni...
Date: Thu, 08 Oct 1992 02:50
Date: Thu, 08 Oct 1992 02:50
29 lines
1868 bytes
1868 bytes
In article <1992Oct8.013106.21116@ryn.mro4.dec.com>, anderson@bigun.enet.dec.com (Keith J. Anderson) writes: > > o Applications run on desktop This would tend to rule out X Windows, wouldn't it? > > o Distributed Function > Examples: > DEC ACA Services, DECmessageQ, OSF DCE > Biggest growth area for future : application talking to application. Is anybody working on a scheme for breaking down the seams between applications? That is, not only can they share data, but they can share it in a transparent fashion by directly invoking each other's services when appropriate, without the user having to remember which application to use to perform which function. Apple's AppleEvent Object Model seems to me to be one step on this road, which has already garnered a significant degree of vendor support. The only other idea I can think of that sounds remotely similar is Sun's ToolTalk (assuming I haven't got a completely wrong idea of what ToolTalk is all about). Or is this what the Object Request Broker idea is all about? Lawrence D'Oliveiro fone: +64-7-856-2889 Computer Services Dept fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
Re: My personal ideas on Client/Server
Author: Todd P. Whitesel
Date: Thu, 08 Oct 1992 08:22
Date: Thu, 08 Oct 1992 08:22
24 lines
1804 bytes
1804 bytes
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >Is anybody working on a scheme for breaking down the seams between applications? >That is, not only can they share data, but they can share it in a transparent >fashion by directly invoking each other's services when appropriate, without >the user having to remember which application to use to perform which function. Microsoft's OLE is targeted specifically at this. Assuming they can overcome the ill will that's accumulated and convince the industry that they ought to be trusted on this one, I think that OLE could do really well. I am no expert on it, but I did have to get familiar with some of the guts of OLE as part of a summer internship I worked at Microsoft last year. >Apple's AppleEvent Object Model seems to me to be one step on this road, which Yes, but it's only a step. I would love to be wrong on this, but AppleEvents seems to be more of a kludge based on the existing Event architecture that is inherent in the Mac GUI. I have not been keeping current on this but as of last summer I was not too impressed by AppleEvents. I hope it has improved since, or that I did not get to see the whole story, because what I did see looked quite lacking when compared to OLE. Todd Whitesel toddpw @ cco.caltech.edu
Re: My personal ideas on Client/Server
Author: Lawrence D'Oliveiro, Waikato Uni...
Date: Thu, 08 Oct 1992 21:56
Date: Thu, 08 Oct 1992 21:56
41 lines
2998 bytes
2998 bytes
In article <1b0r3eINNne5@gap.caltech.edu>, toddpw@cco.caltech.edu (Todd P. Whitesel) writes: > ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > >>Apple's AppleEvent Object Model seems to me to be one step on this road, which > > Yes, but it's only a step. I would love to be wrong on this, but AppleEvents > seems to be more of a kludge based on the existing Event architecture that is > inherent in the Mac GUI. I have not been keeping current on this but as of last > summer I was not too impressed by AppleEvents. I hope it has improved since, or > that I did not get to see the whole story, because what I did see looked quite > lacking when compared to OLE. That's strange. I thought of OLE as being roughly equivalent to Publish/ Subscribe under Macintosh System 7, only without the network transparency. That is, it allows you to embed a data object in one document, that actually comes from another document (possibly another application). Any updates in the original document are automatically propagated to subscribers, and the subscriber can also invoke a "Go To Publisher" function (which relies heavily on the AppleEvent infrastructure in order to work), which automatically brings up the publisher document (perhaps launching the corresponding application if it isn't already running), and autoscrolls it to the portion that was published. AppleEvents do more than this. The Object Model, in particular, gives a way to reference objects like windows, documents and files, and parts thereof, eg "find all the bold text on pages 2 to 4 of document Fred and make it blue". This allows applications to call on the services of other applications, eg a word processing program doesn't need to provide drawing tools to manipulate graphics, it can make use of the services of an existing drawing program. AppleEvents aren't a scripting language per se, but they do provide the basis on which you can build a scripting system to coordinate tasks involving a whole bunch of applications working in concert. Lawrence D'Oliveiro fone: +64-7-856-2889 Computer Services Dept fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 Actually, of course, they were right within the circumstances of their study, but most of us can't afford such expensive circumstances. -- Bruce Tognazzini, "Tog on Interface"
Re: My personal ideas on Client/Server
Author: Todd P. Whitesel
Date: Fri, 09 Oct 1992 13:18
Date: Fri, 09 Oct 1992 13:18
36 lines
2521 bytes
2521 bytes
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >That's strange. I thought of OLE as being roughly equivalent to Publish/ >Subscribe under Macintosh System 7, only without the network transparency. This is probably true of OLE 1.0. I am no expert on OLE but 2.0 was supposed to have network transparency and a considerably more powerful object model. >This allows applications to call on the services of other applications, eg a >word processing program doesn't need to provide drawing tools to manipulate >graphics, it can make use of the services of an existing drawing program. OLE does this also. The stuff I worked on was definitely for OLE 2.0, and it was intended to be a toolkit in a DLL that would help third-parties retool their apps for OLE 2.0 compatibility. >AppleEvents aren't a scripting language per se, but they do provide the >basis on which you can build a scripting system to coordinate tasks involving >a whole bunch of applications working in concert. OLE 2.0 is a more fundamental protocol that defines common app operations and allows apps to speak to each other with a more powerful language that includes both direct, pre-defined standard messages and more macro-like scripting. The key difference is that with AppleEvents you _have_ to build the system -- and Microsoft has implemented OLE on top of AppleEvents -- but with OLE you have a lot of things built in. It seems to me to have a much broader scope than AppleEvents. It's been a year, so I'm pushing my recollection of OLE somewhat. I'll leave it to somebody else who knows more to expound on the details. The only stuff I know more about is basic architecture of the communications path between OLE compliant apps, and what the common messages would be like. This has all been handed out to developers so I _think_ it's safe for me to talk about it... Todd Whitesel toddpw @ cco.caltech.edu
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads