Transcript ITY276 presentation 3

COMP3241
E-Business Technologies
Richard Henson
University of Worcester
October 2013
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
organised according to “fields”
 retrieval of search strings or numerical data can
take a looonnnggg time

Database proper logically links the 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 remote data access
components for web server
» components for IIS-based scripts downloaded from
Microsoft (as MDAC)
“datasets” need to be defined using a
programming language & embedded SQL
connectivity link needed to remote
database, including path to/on web server
Database Design (1)

Same principles apply as with any other
relational database management
system (RDBMS)…
identify entities & attributes
produce entity relationship
define logic relationships between
entities
Database Design (2)
 Same principles... any RDBMS:
 make sure data is fully normalised
 create tables & links
 SQL statements need to communicate with the
data to:
» extract data from specific fields in particular tables
» put data into specific fields in particular tables

Some “self-taught” dynamic web developers
are unaware of this... build the data round
the processing… and often get it wrong
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!
Microsoft Solutions:
(1) 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
Limitations of
ODBC

Still far from the “Universal Data Access” (UDA)
model
 only relational databases can work with ODBC
model

Other types of data needs to be displayed on web
pages:




Spreadsheets
Graphics
EDI data
Other web data...
ActiveX

Next stage in evolution towards UDA...
 sexy name for OLE v2.0
 made up of…
» OLE

Object Linking and Embedding…
» Combined with COM (VB source code)


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 client-side invention…
(first move away from VB)
Run-time code (became known as “controls”)
 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

Scripts compiled into executable versions so
source language is irrelevant
More about VB ActiveX
Data Objects (ADO)


Applied client-side ActiveX principles to
server-side
Simplified writing client applications to access
data sources through replacement of ODBC
with OLE DB providers
 more flexible than DSN strings used with ODBC
Data sources could indeed now include:
 spreadsheets
 graphics
 web pages…
Microsoft Solution (2) 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 achieved!
System Connection
to the Database using OLE DB

Provided by Microsoft Data Access
Components (MDAC)
easily downloaded:
» http://www.microsoft.com/enus/download/details.aspx?id=5793
covers wide 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 component(s) have been
chosen…
 a logical 'connection' can be set up with the
database – wherever it is on the Internet!
 if OLE DB connection isn’t correct, scripts on 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 – some still use “legacy” .asp scripting
 OLE DB – .aspx connectivity

Whichever is used…
 essential to get connectivity working correctly
» RAD tools like Visual Studio very helpful in achieving this…

Once connectivity achieved, server-script can
use embedded SQL commands to link to and
communicate smoothly with database tables
 RAD tool can save a lot of time…
Databases interacting
with web pages
Some early e-commerce applications
used embedded local code (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?
Local databases and
local web pages (why not?)

Some 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?... without changing the
programming?
 not possible!
 massive security risk in any case!
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
 app 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 multi-use requirement:
– large, regularly updated centralised data store that
needs to be accessed through many connections
– database downloaded every time the application is
to be used!
 Conclusion (re client app):
»
»
»
»
client not powerful enough?
or enough storage capacity?
not sufficient bandwidth?
anyway, downloading databases can compromise security
Secure remote database
used with local web page...

Accepted solution 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 must be :
secure
readily accessible from all clients
queried remotely
alterable only by specific persons

Only achievable through a
client-server model
Server Scripts
Run only on the web server
 Very different from client-side
embedded code...
 Only interact with client & HTML
browser 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 in e-commerce for

product selection
passing data into a remote SQL query
sound horrendous?
» you’ll be eased into this gently
Mechanism for variable passing
between Dynamic Web Pages
Use HTML “forms” <form>..... </form>
 with “GET” or “POST”
 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”
within form definition...
e.g. post /thetest.jsp
firstname=richard&password=holiday
s&lastname=henson&action=transfer
bankfunds
And now for the practical…
Thanks for listening!

And for next week:
 http://csharpdotnetfreak.blogspot.com/2009/05/as
pnet-creating-shopping-cart-example.html