Title: ClientServer
1Client/Server
- A Personal View
- Stuart Williams
- Practitioner
2The Version
- The Goal
- Applications that meet business needs
- The Way
- Use database technology to store the information
- Use TCP/IP Sockets to link up the clients and the
servers over the lan/wan/internet - Use the high level APIs so there is less code to
maintain - Use a variety of RAD/JAD N-Tier techniques to
knock out apps quickly
3N-Tier Implementations
User Interface
Visual Basic
IE 4
Client
IIS 4
Business Logic
MTS Business Objects
Stored Procedures
Stored Procedures
Data Storage
Microsoft SQLServer
Server
4Another View
5Which One?
- The "Horses for Courses" Rule.
- If the client wants a web app, the get a web app.
- If the client needs rich functionality, they get
an app in visual basic. - The "Fish" rule.
- If you want scalability you need more tiers.
- If you really want to scale you need pooling.
6Indispensable Technology - I
- Relational Database Technology.
- Theory Normalization, B-Trees, Statistics
- The 'Structured Query Language' (SQL)
- Defined by American National Standards Institute
(ANSI). - Variously implemented by various vendors.
- Serious emphasis on variously.
- The four most common verbs work in almost the
same way across vendors.
7Indispensable Technology - II
- Open Database Connectivity (ODBC)
- A programmers interface that hides the varied
implementation details of each of the database
drivers. Provides an abstraction layer with a
defined API. (A very complex one) - ActiveX data objects (ADO)
- Provides programmers with a set of objects that
provide an easy front to databases and drivers
(including ODBC).
8Indispensable Technology - III
- Stored procedures
- Script on the SQLServer that performs database
and business functions. - VBScript/Active Server Pages (ASP)
- Build Business logic via ASP. ASP technology
allows the creation of robust server side
applications. ASP is being ported to many
platforms (mostly Unix).
9Table Design For Performance
- 4 Byte Integer (Long) Primary Keys
- Do not use auto-incrementing primary keys for
tables whose primary key is the foreign key of
another table. - Avoid locking, consider the likelihood that a
record will need to be updated by more than one
user at a time. - Use surrogate keys rather than multi-part keys
but watch out for duplicate records! - Defer memo fields to their own tables
- When constructing SQL statements always put the
memo fields last in the list of fields.
10Optimization Vs. Normalization
- Generally, starting with a properly normalized
database is a good first step towards
performance. - Selective de-normalization via introduction of
addition foreign keys to selectively
de-normalize. - This is because these additional keys allows for
the reduction of the number of joins. - The trade off is that the additional foreign keys
take up storage (small deal) and the additional
indexes to maintain the referential integrity
and/or speed relationships take additional time
to maintain on insert/update and delete.
11Microsoft Transaction Server
- Performs pooling
- Connection and Instance
- Manages distributed transactions
- Even across non-Microsoft platforms
- Hosts middle tier business objects
- Middle tier objects are built in VB or C and
compiled to apartment threaded ActiveX DLLs.
12Connection Pooling
- Databases meter (price) by the number of
connections. Connections are expensive. - Share connections, save money
- Share connections, save time
- Instancing connections is expensive in terms of
time. By holding and reusing connections open to
the SQLServer the expense of instancing them is
reduced.
13Instance Pooling
- Creating objects is likewise expensive.
- By tracking object creation and holding objects
after they have been disposed, the next process
can re-use the held object instances. - The most common objects that are instanced are
ASP components and database connectors (ADO).
14Transaction Coordination
- MTS can coordinate transactions across multiple
platforms - SQLServer and other databases
- AS/400 and IBM mainframes
- Unix(s)
- Transactions can be nested or call other
transactions. - Bottom Line All Succeed or All Fail.
15General Design Principles - I
- Less traffic over the wire is good.
- Minimizing required bandwidth means there is more
left over to scale. - Use TCP/IP because it is a routable, scalable
protocol. - Do most of the application optimization at design
time, instead of trying to fix performance issues
at run time.
16General Design Principles - II
- Optimization strategies
- Do not allow users to scroll through records,
make them search and "drill down" to the detail. - Return only the rows absolutely needed
- Return only columns to be displayed
- Do calculations close to the data
- Use action queries not recordsets when possible
17Connection Use Strategies
- For VB apps on the client the technique is to use
a single connection object opened early (to avoid
time penalty or repeated openings and closings).
This connection instance will be used to connect
other objects to the SQLServer. The connection
is released at the last moment when the program
ends. (Persistent Connection) - For web apps, the exact opposite strategy is
used, because web pages are treated as MTS
applications the best practice is to grab a
connection as late as possible and dispose of it
as soon as you can. If possible creating as few
objects as you can. (Connectionless)
18New Choices - RDS - I
- The ability to create recordset objects that do
not require a persistent connection, can be
persistently stored on the client and yet still
can be used to update data on the server means
that you can have the benefit of a well
connection interface (rich functionality and
performance) with the benefits of a
connectionless implementation (low resource use,
scalability) - This Technology is called "Remote Data Services"
(RDS) - RDS implements an ADO recordset with the
properties of persistence and disconnection.
19New Choices - RDS - II
- RDS works across Port 80 so internet applications
are possible that work across the firewall. - RDS allows for the creation of other object
instances besides recordsets. Parameter passing
between the client and the server use the
recordset Meta-data format. - As it happens, passing parameters in a recordset
is one of the most efficient ways to pass
parameters in client/server systems.
20The case for parameter passing - I
- Properties are EVIL.
- Between objects in the same memory space the best
thing we can say about them is they are a chance
for involuntary type conversion and run time
errors - at worst (over the wire) every property let or
set involves marshalling and a round trip across
the wire. - Objects are forced to maintain state, hence don't
scale. (This is hard for programmers to grasp,
the traditional object oriented model is ideal,
but in practice, simply evil. Truth. Stateless
Components scale, objects don't.)
21The case for parameter passing - II
- Parameters are Good.
- Reduced marshalling, one round trip, possibly
(ideally) no state is kept at the object
(scalable). - Pooling all the parameters in to a recordset
means that the parameters are passed in an error
checked, compressed and optimized way. - Recordsets allow a single call to an component to
process multiple instances. Economical all the
way around. - Components that reside in MTS are better still.
22Record Change Management - I
- For executed action queries, databases only
create and hold locks for the duration of the
update to the database. A VERY short time
interval. This is optimal in most cases. - Less optimal but required or implemented,
persistent locking is invoked. Typically, due to
the creation of recordsets with explicit locking. - Locking, especially escalated over many records
(page or worse yet, table locks) can result in
deadlocks at worst (causing application failure)
or poor performance as threads are caused to wait.
23Record Change Management - II
- In most cases if updateable recordsets are
required or desired, optimistic batch locking is
the best practice. - Behind the scenes, ADO (with or without RDS)
maintains a local buffer (the size varies
depending on cursor type.) - When a record is updated on the client the record
is marked dirty. However, until explicitly asked
to do so, or if the record would be flushed from
the buffer the changes are not written to the
server. - If there is NO explicit collision management in
effect the "last in, wins" rule applies.
24Record Change Management - III
- If a timestamp field (a special column type) is
present in the record, it is automatically
included in the recordset, hence each record
contains the exact date/time the record was last
updated. - When a record in a recordset is changed and that
change is propagated to the server, the timestamp
field in the fetched recordset is compared to the
existing one. If they do not match someone has
modified the record since the original was
fetched.
25Record Change Management - IV
- In this case a error will be raised to the
client. The client has only one choice, to
discard the recordset, re-fetch the records and
then either abandon or re-apply the changes. - This choice is left up to the programmer, the ADO
API exposes the list of records that did not
successfully update. - In the case of an RDS recordset, this technique
is very important as by definition, the entire
recordset is on the client.
26Topics, topics, topics.
- More about database design.
- Nuts and Bolts implementation details.
- SQLServer
- ADO/RDS
- ASP
- MTS
- VB