Transcript ITY276 presentation 3 - University Of Worcester

COMP3241
E-Business Technologies
Richard Henson
University of Worcester
October 2012
Week 3 – Early Web Applications,
ActiveX, and Database connectivity

Objectives:
 Contrast between client-end applications and
client-server applications
 Explain the architecture of web-based database
connection with server-scripting
 Create a presentable shopping page using data
from a database
Flatfiles and Databases

Many so-called databases are just lists of data
 retrieval of data can take a looonnnggg time

Database proper links logically data:
 hierarchically
 relationally
 object-oriented

Relational still popular mainly because of SQL
Relational Databases
Tight data structure means existing data
can be more rapidly located…
 Real advantage of a true relational
database is that SQL can be used for
read/write & query database operations

Linking Server Script code
with a relational database

To make a two-way link with a relational
database:
need relevant data access components
» components for IIS-based scripts available from
Microsoft (MDAC)
“datasets” need to be defined using a
programming language & embedded SQL
connectivity link needed to database
pathname
Database Design

Same principles apply as with any other relational
database management system (RDBMS)…
 identify entities & attributes
 produce entity relationship
» define logic relationships between entities
 make sure data is fully normalised
» create tables & links
 use embedded SQL statements in the server script to
communicate with the data:
» extract data from specific fields in particular tables
» put data into specific fields in particular tables

Some “self-taught” developers are unaware of this,
and try to build the data round the processing…
Evolution of Application
- RDBMS connectivity

In the early web development days…
 the connection of an application to a particular
relational database would be hard coded and
made available as an API (application program
interface)
 a client application then had to be written to use
the proprietary API Even then, there was a
problem:

If more than one RDBMS needed to be used?
 several different APIs would be used
 each needed a client application…
 added greatly to the complexity of the task!
The Microsoft Solution:
the ODBC API

Ideal: the “Universal Data Access” (UDA) model
 all data consumers interact with all data providers…
 response to the “API for each application” problem

First stage: ODBC = Open Database Connectivity
 developed in early 1990s:
» common API for writing applications to access ANY relational
DBMS for which an ODBC driver had been written
 Once the APIs had all been written, tried, and tested…
» any relational database with an ODBC compliant interface could use
them
» easy database path connectivity string management
ActiveX

The next stage in evolution of Microsoft’s data
objects model
 sexy name for OLE v2.0
 made up of…
» OLE

Object Linking and Embedding…
» Combined with COM


Common Object Model
ActiveX Data Objects make up a series of
modular components called ADO
 used for “run-time” web applications
 basis of .net controls
What is ActiveX®?


V. successful Microsoft invention…
Run-time code became known as a “control”
 NO source code so can’t be embedded in HTML,
but can be called from a HTML file
» Runs on any Browser (not interpreted…)
 allows compiled (i.e. executable) code to talk to
host applications
 difficult to “hack” the code if source code not
available

As the scripts are compiled into executable
versions the source language is irrelevant
 languages other than VB used…
More about VB ActiveX
Data Objects (ADO)


Use a common, easy-to-use object model
Designed to simplify the writing of client
applications to access data sources
through OLE DB providers
 more flexible than DSN
» had to be specified on the local machine and limited to
using the ODBC providers on that machine

Data sources could now also include:
 spreadsheets
 graphics
 web pages…
OLE DB

Application of OLE/ActiveX principles to
connectivity between applications and
databases
to be more precise, relational database
management systems!

Interface specification that provides a
layer of abstraction between:
a data provider e.g. relational DBMS
a data consumer e.g. business object or
client application
Universal Data Access in practice
System Connection
to the Database

Provided by Microsoft Data Access
Components (MDAC)
easily downloaded:
» http://www.microsoft.com/enus/download/details.aspx?id=5793
covers of range of databases
need most up-to-date version of MDAC (2.8
SP1) to work with latest database versions…
Use of MDAC with “path”

Once the correct components have been
chosen…
 a logical 'connection' can be set up with the
database – wherever it is!
 If this isn’t correct, scripts on a web server can’t even
link with, let alone interact with, a relational database

“Database Path” must include:
 a definition of where the database is
 a few simple rules on how the database should be
treated
Making a connection to a
database on the web server

Two systems still used:
 ODBC – “legacy” .asp scripting
 OLE DB – .aspx connectivity

Whichever is used…
 essential to get connectivity working correctly
» RAD tools like VWD very helpful in achieving this…

Once connectivity achieved, server-script can
use embedded SQL commands to link to and
communicate smoothly with database tables
 again… RAD tool like VWD can save a lot of time…
Databases & web pages
Some early e-commerce applications
used embedded JavaScript and a small
local database
 Problems:

database took a long while to download &
could be tampered with!
if database ran locally how could data be
updated… prices changed, new products
added?
Early online shopping
example : Shop@ssistant

Came out of the early “wow, Java” revolution in
web development
 http://staffweb.worc.ac.uk/hensonr/shop@ssistant

Whole system (30kb) written in Java Script, runs
on the client machine (!)
 stores & presents product data
 shows all the components and functionality expected
of a shopping cart system
 interfaces with merchant systems that can be used to
handle online payment

TAKE A LOOK!!! Or download and run it yourself
Critical Look at
Client-end “apps”
 Absolutely
fantastic!
 Even better on a mobile…
 BUT usually for entertainment only…
only small data sources, or infrequently
changed data sources are used
usually “single user”
Whatever happened to
“client only” web shopping?

In an ideal (Internet) world everything would be
able to run via the browser on the client
machine. Result:
 faster
 all data local
 more controlled

The “Java+client-end HTML” model is fine…
 until you need to store and change data… securely!!
Applications requiring
multi-client use & shared data

Specific requirement:
 Large, regularly updated centralised data store that
needs to be accessed by a number of clients
 Requirements for client-end solution?
» database updated centrally
» database downloaded every time the application is to be used!
 Feasibility of client-end solution?
»
»
»
»
not powerful enough?
client not enough storage capacity?
not sufficient bandwidth?
downloading databases can compromise security
Using a remote database
with a web page

Compelling reason for client-server web
applications…
data held in a secure place
product data easily updated
database processing can happen at a
powerful server
Demands of Applications based
on centralised data storage!

Typically… the database is :
secure
readily accessible from all clients
queried remotely
alterable only by specific persons

Only achievable through a
client-server model
How Server Scripts can
Interact with Databases

Contain
embedded
SQL code that
can extract
data from or
send data to a
database
How Server Scripts can
Interact with Databases
Whenever a
database is
updated…
» updated data picked
up by server-script
when it runs
» updated data
displayed on client
How Server Scripts can
Interact with Databases
Whenever a
browser form
captures data…
» data transferred
directly to relevant
server
» then stored in
specified database
field(s)
How Server Scripts
Interact with Databases

Whenever database
information needs to
be presented:
 database fields and
records taken into
server memory
 data sent to local
machine to be
displayed within a
HTML format
Parameter Passing
between Programs
Essential to programming
 Coding can rapidly get quite complex…
 Essential for

product selection
passing data into a remote SQL query
sound horrendous?
» you’ll be eased into this gently…
» Starting NEXT week.
Mechanism for variable passing
between Dynamic Web Pages

HTML “GET” function:
parameter/s tagged on to the URL e.g.
» Get <www
address>/thetest.jsp?firstname=richard&password=holidays&la
stname=henson&action=transferbankfunds
Can result in v. long URLs…
Variable Passing between
Dynamic Web Pages

Alternative: “POST”
 designed to be used within HTML forms…

Example of syntax, added to HTML
coding within <FORM>…
post /thetest.jsp
firstname=richard&password=holiday
s&lastname=henson&action=transfer
bankfunds
And now for the practical…
Thanks for listening!

 http://csharpdotnetfreak.blogspot.com/2009/05/as
pnet-creating-shopping-cart-example.html