62
Copyright 1997, The University of New Mexico L-1 Computing Architecture Standards and Products

© Copyright 1997, The University of New Mexico L-1 Computing Architecture Standards and Products

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

© Copyright 1997, The University of New Mexico L-1

Computing Architecture

• Standards and Products

© Copyright 1997, The University of New Mexico L-2

Operating System:

• MVS• Unix• Netware• MS Windows3.1, 3.11, 95

© Copyright 1997, The University of New Mexico L-3

Transaction Processing System

• IDMS/DC

© Copyright 1997, The University of New Mexico L-4

DBMS

• IDMS• Oracle?• NDBM• MS Access• Paradox

© Copyright 1997, The University of New Mexico L-5

Application Development Tools

• ADS• SAS• Visual Basic• Cobol• Developer 2000

© Copyright 1997, The University of New Mexico L-6

Ad Hoc Reporting Tools

• SAS• Discoverer 2000?• Culprit• Visual Express?

© Copyright 1997, The University of New Mexico L-7

Query Language

• SQL

© Copyright 1997, The University of New Mexico L-8

Transport

• CAICCI• SQL Net

© Copyright 1997, The University of New Mexico L-9

Security

• ACF2• NIS• Netware

© Copyright 1997, The University of New Mexico L-10

Public Information Server

• FTP• Gopher• WWW

© Copyright 1997, The University of New Mexico L-11

Data Replication

• DB API• ODBC• OLE

© Copyright 1997, The University of New Mexico L-12

Network Printing

• LPR/LPD• Netware

© Copyright 1997, The University of New Mexico L-13

Network Mgt.

• SNMP

© Copyright 1997, The University of New Mexico L-14

Network Protocol

• TCP/IP• IPX

© Copyright 1997, The University of New Mexico L-15

Physical Network

• FDDI• Enet

© Copyright 1997, The University of New Mexico L-16

Client / Server Applications

© Copyright 1997, The University of New Mexico L-17

Client – user side application

Handles presentation

© Copyright 1997, The University of New Mexico L-18

Server – host side

• Stores persistent data• Provides processing

© Copyright 1997, The University of New Mexico L-19

Procedural

• RPC remote procedure calls• Named Pipes

© Copyright 1997, The University of New Mexico L-20

Object Oriented

• Classes, Inheritance, encapsulation, methods• Smalltalk• Java

© Copyright 1997, The University of New Mexico L-21

GUI

• Web Browser• Windows• Macintosh• Motif

© Copyright 1997, The University of New Mexico L-22

Logic

• Server side• Client-side

© Copyright 1997, The University of New Mexico L-23

Database

• Relational• Network• Transaction Processing• Data Warehousing

© Copyright 1997, The University of New Mexico L-24

OSF DCE

• DFS – file service• Time• CDS – Naming• DSF – Security (Kerberos)

© Copyright 1997, The University of New Mexico L-25

OSF DCE

• POSIX Threads• DME – Management• Transaction Processing

© Copyright 1997, The University of New Mexico L-26

SQL

• middleware

© Copyright 1997, The University of New Mexico L-27

Distributed Database

• Application uses data from multiple databases on different servers.

• 2 phase commit

© Copyright 1997, The University of New Mexico L-28

Thick Client

• Runs some or all of the application logic

© Copyright 1997, The University of New Mexico L-29

Thin client

• Does primarily or only display functions

© Copyright 1997, The University of New Mexico L-30

Partitioned Processing

• Both the server and the client have parts of the application processing

© Copyright 1997, The University of New Mexico L-31

CASE Tools

• Visual Development Tools– Paint objects from toolboxes

– Event driven languages

– SQL Database access

© Copyright 1997, The University of New Mexico L-32

End User Tools

• Personal DBs– Access, Paradox, FoxPRO, etc.

• Spreadsheets– Excel, Lotus, etc.

• DSS and EIS tools– Crystal. Gupta, Focus, Informix, Oracle, PowerSoft

• Analysis Tools– SAS, etc.

© Copyright 1997, The University of New Mexico L-33

CLIENT-SERVER COMPUTING

© Copyright 1997, The University of New Mexico L-34

CLIENT-SERVER COMPUTING

• A relatively new “buzz-word” for an old concept.• To many vendors, any system that uses personal

computers networked to a larger server is a “client-server” system.

• Even systems where the personal computer works solely in the terminal emulation are called client-server by some vendors. Such systems look exactly like the old mainframe-terminal systems except that the personal computer has replaced the terminal.

© Copyright 1997, The University of New Mexico L-35

CLIENT-SERVER COMPUTING (cont.)

• A true client-server application is one in which a complex application is decomposed into a part that runs on a server and one which runs on personal computers (the clients). Besides doing part of the computing for the application, the PC client provides a natural point and click graphical interface to the application.

© Copyright 1997, The University of New Mexico L-36

CLIENT-SERVER COMPUTING (cont.)

• Advances in networking and personal computers allows client-server applications to be more widely deployed today than has been possible in the past.

© Copyright 1997, The University of New Mexico L-37

SUBROUTINES AND CO-ROUTINES

Y

X

Call Y

Call X

Call X

Application

mainsubroutines

Co-routines Co-routinesUses subroutine calls Uses co-routine calls

Application

© Copyright 1997, The University of New Mexico L-38

CLIENT-SERVER APPLICATIONApplication

Server Network Clients

Server

Appl.Client Appl.

Remote Procedure Calls

Responses

users

Server Network Remote ClientsUse Remote Procedure Calls (RPC’s) to communicate requests and

pass responses.

© Copyright 1997, The University of New Mexico L-39

RPC’s

• Remote Procedure Calls are much more complex than subroutine or co-routine calls.

• Subroutine and co-routine calls are generally made within an application or between co-applications that run on a single system where the assumption can be made that data and command transfers will be error free.

© Copyright 1997, The University of New Mexico L-40

RPC’s (cont.)

• RPC’s, on the the other hand, are made between systems that are interconnected by means of an error-prone network. The server also must handle simultaneous requests from many clients. This also implies a need for synchronization among requests. All this makes RPC’s complex.

© Copyright 1997, The University of New Mexico L-41

ADVANTAGES OF CLIENT-SERVER

• Advantages often cited include:– Centralization - access, resources, and data security are

controlled through the server

– Scalability - any element can be upgraded when needed

– Flexibility - new technology can be easily integrated into the system

– Interoperability - all components (clients, network, servers) work together

© Copyright 1997, The University of New Mexico L-42

ADVANTAGES OF CLIENT-SERVER (cont.)

• Advantages often cited include:– Accessibility - server can be accessed remotely and across

multiple platforms

– Ease of application development

– Lower total costs than “mainframe legacy systems”.

– User friendly - familiar point and click interface

© Copyright 1997, The University of New Mexico L-43

DISADVANTAGES OF CLIENT-SERVER

• Disadvantages often cited include:– Dependability - when the server goes down, operations cease

– Lack of mature tools - it is a relatively new technology and needed tools are lacking

• e.g.. Automated client software distribution

– Lack of scalability - network operating systems (e.g.. Novell Netware, Windows NT Server) are not very scalable.

– Higher than anticipated costs

– Can cause network congestion

© Copyright 1997, The University of New Mexico L-44

DISADVANTAGES OF CLIENT-SERVER (cont.)

• NOTE– What some call advantages, others call disadvantages.

© Copyright 1997, The University of New Mexico L-45

THE REALITY OF CLIENT-SERVER

• Not a panacea - some successes, many early failures.• More difficult to implement and more costly to

maintain than originally thought.• Technology relatively immature, but getting better• Bottom line is you have to beware of vendor hype

and analyze the suitability of client-server systems for a particular project on a case by case basis.

© Copyright 1997, The University of New Mexico L-46

CLIENT-SERVER ARCHITECTURES

• There are basically two types of client-server architectures– Two tier architectures

– Three tier architectures

• The choice between the two should be made based on combination of:– Schedule for project implementation

– Expected system changes and enhancements

© Copyright 1997, The University of New Mexico L-47

TWO-TIER ARCHITECTURES

• Application components are distributed between the server and client software

• In addition to part of the application software, the server also stores the data, and all data accesses are through the server.

• The presentation (to the user) is handled strictly by the client software.

Server

Network

PC PC PC

Clients

© Copyright 1997, The University of New Mexico L-48

TWO-TIER ARCHITECTURES (cont.)

• The PC clients assume the bulk of the responsibility for the application logic.

• The server assumes the bulk of the responsibility for data integrity checks, query capabilities, data extraction and most of the data intensive tasks, including sending the appropriate data to the appropriate clients.

© Copyright 1997, The University of New Mexico L-49

TWO-TIER ARCHITECTURES (cont.)

• SQL is a standard used on the clients to request appropriate subsets of data from the server.

• Data returned from the server to the clients is manipulated by the client software for reporting, business analysis, and “what if” analysis.

© Copyright 1997, The University of New Mexico L-50

TWO-TIER ARCHITECTURES, ADVANTAGES

• The commonly cited advantages of two-tier systems include:– Fast application development time

– Available tools are robust and lend themselves to fast prototyping to insure user needs a met accurately and completely.

– Conducive to environments with homogeneous clients, homogeneous applications, and static business rules.

© Copyright 1997, The University of New Mexico L-51

TWO-TIER ARCHITECTURES, DISADVANTAGES

• The commonly cited disadvantages of two-tier systems include:– Not suitable for dispersed, heterogeneous environments

with rapidly changing business rules.

– Because the bulk of the application logic is on the client, there is the problem of client software version control and new version redistribution.

– Security can be complicated because a user may require separate passwords for each SQL server accessed.

© Copyright 1997, The University of New Mexico L-52

TWO-TIER ARCHITECTURES, DISADVANTAGES (cont.)

• The commonly cited disadvantages of two-tier systems include:– Client tools and SQL middleware in two-tier environments

tend to be proprietary. The volatility of the client /server tool market raises questions about the long-term viability of any proprietary tool. Organizations should be wary about committing to proprietary tools.

© Copyright 1997, The University of New Mexico L-53

THREE-TIER ARCHITECTURES

• 3-tier architectures attempt to overcome some of the limitations of the 2-tier architecture by separating presentation, processing, and data into 3 separate and distinct entities.

• The software in the client handles the presentation (to the user) using similar tools as in the 2-tier architecture.

Server

Network

PC PC PC

Clients

Server

© Copyright 1997, The University of New Mexico L-54

THREE-TIER ARCHITECTURES (cont.)

• When data or processing are required by the presentation client, a call is made to the middle-tier functionality server.

• This tier performs calculations, does reports, and makes any needed client calls to other servers (e.g.. a data base server).

© Copyright 1997, The University of New Mexico L-55

THREE-TIER ARCHITECTURES (cont.)

• Middle tier servers are usually coded in a highly portable, non-proprietary language such as C or C++.

• Middle tier servers may be multithreaded and can be accessed by multiple clients.

• The calling mechanism from client to server and from server to server is by means of RPC’s.

© Copyright 1997, The University of New Mexico L-56

THREE-TIER ARCHITECTURES (cont.)

• Because the bulk of 3-tier implementations use RPC’s and 2-tier implementations use SQL messaging, a careful examination of the merits of these respective request/response mechanisms is warranted.

© Copyright 1997, The University of New Mexico L-57

THREE-TIER ARCHITECTURES, ADVANTAGES

• Commonly cited advantages include:– RPC calls from the presentation client to the middle tier

provide greater generality (i.e. flexibility) than the SQL calls usually used in the 2-tier architecture.

– The 3-tier clients do not have to understand SQL. This allows the organization, names, or even the overall structure of back end data to changes without requiring changes in the PC-based presentation clients. This allows clients to access even non-relational databases and greatly simplifies introduction of new database technologies.

© Copyright 1997, The University of New Mexico L-58

THREE-TIER ARCHITECTURES, ADVANTAGES (cont.)

• Commonly cited advantages include:– Having separate functionality servers allows for the

parallel development of individual tiers by application specialists.

– Provides for more flexible resource allocation. Can reduce network traffic by having the functionality servers strip data to the precise structure needed before sending it to the clients.

© Copyright 1997, The University of New Mexico L-59

THREE-TIER ARCHITECTURES, ADVANTAGES (cont.)

• Commonly cited advantages include:– Can use reusable program modules for different

applications, thus reducing development and migration costs.

– 3-tier standards such as OSF/DCE (Open Software Foundation Distributed Computing Environment) offers a variety of features to support distributed application development.

© Copyright 1997, The University of New Mexico L-60

THREE-TIER ARCHITECTURES, DISADVANTAGES

• Often cited disadvantages of 3-tier architectures include:– Creates an increased need for network traffic management,

server load balancing, and fault tolerance.

– Current tools are relatively immature and are more complex.

– Maintenance tools are currently inadequate for maintaining server libraries. This is a potential obstacle for simplifying maintenance and promoting code reuse throughout the organization.

© Copyright 1997, The University of New Mexico L-61

CLIENT-SERVER BUZZWORDS

• Common client-server buzzwords include:– Thin clients

– Fat clients

– Message Server

– Object Server

– Fat Server

– Middleware

– 3GL, 4GL

© Copyright 1997, The University of New Mexico L-62

CLIENT-SERVER BUZZWORDS (cont.)

• Since it is not unusual to get n different definitions of buzzwords from n different vendors, always ask what is meant by these “buzzwords”.