View
213
Download
0
Category
Tags:
Preview:
Citation preview
© 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-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-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-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-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-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
Recommended