🚀 go-pugleaf

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 *****