ITY276 presentation 3

Download Report

Transcript ITY276 presentation 3

E-Business Technologies
Richard Henson
University of Worcester
October 2013
Week 3 – Early Web Applications,
ActiveX, and Database connectivity
 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
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
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
 a client application then had to be written to use
the proprietary API Even then, there was a
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:
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
» easy database path connectivity string management
Limitations of
Still far from the “Universal Data Access” (UDA)
 only relational databases can work with ODBC
Other types of data needs to be displayed on web
EDI data
Other web data...
Next stage in evolution towards UDA...
 sexy name for OLE v2.0
 made up of…
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
Scripts compiled into executable versions so
source language is irrelevant
More about VB ActiveX
Data Objects (ADO)
Applied client-side ActiveX principles to
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
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:
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
 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
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
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
 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
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
 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
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 :
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
How Server Scripts can
Interact with Databases
SQL code that
can extract
data from or
send data to a
How Server Scripts can
Interact with Databases
Whenever a
database is
» 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
» then stored in
specified database
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
Can result in v. long URLs…
Variable Passing between
Dynamic Web Pages
Alternative: “POST”
within form definition...
e.g. post /thetest.jsp
And now for the practical…
Thanks for listening!
And for next week: