CS 483 Enterprise and Web Application Programming

1
CS 483 Enterprise and Web Application Programming

• Week 1

2
Welcome and Introduction

• Introductions
• Syllabus
• Introduction to the class
• Week 1 Topics
• Overview of Distributed Systems
• Distributed Systems Architectures
• Middleware
• Data Persistence Tier
• JDBC Java/MySQL API

3
Distributed Systems Overview

• What is a distributed system?
• Your textbook authors define a distributed system
  as one in which components located at networked
  computers communicate and coordinate their
  actions by passing messages
• Most enterprise and web applications fall under
  the umbrella of distributed systems
• For example, you use them when you use a Regis
  Online course
• WebAdvisor, Forum, Email

4
Distributed Systems Consequences

• Concurrency
• work is happening at the same time on different
  computers and share resources
• No global clock
• all computers on the network do NOT share the
  same clock or time no notion of correct time
• Independent failures
• faults in a network result in isolation of the
  computers that are connected to it
• each component can fail independently
• Motivation to construct a distributed system
• desire to share resources

5
Examples of Distributed Systems

• Internet WWW, email, file transfer
• Intranet firewalls, routers, servers
• Mobile and ubiquitous computing
• Laptops
• Handheld devices (PDAs, mobile phones, smart
  watches, smart appliances)

6
A Typical Portion of the Internet
7
A Typical Intranet
8
Portable and Handheld Devices in a Distributed
System
9
Web Servers and Web Browsers
10
Challenges of Distributed Systems

• Heterogeneity
• Variety and difference as applied to
• networks, computer hardware, operating systems,
  programming languages, implementations by
  different developers
• Middleware
• Software layer that provides a programming
  abstraction as well as masking the heterogeneity
  of the underlying networks, hardware, operating
  systems, and programming languages
• CORBA (Common Object Request Broker)
  (www.omg.org)
• RMI (Java Remote Invocation) covered in Week 2
  only supports single programming language
• Mobile code
• Code sent from one computer to another to run at
  the destination (Java applets)

11
Challenges of Distributed Systems

• Openness
• Determines whether the system can be extended and
  re-implemented in various ways
• Degree to which a new resource-sharing service
  can be added and be made available for use by a
  variety of client programs
• Open distributed systems
• have key interfaces published
• have a uniform communication mechanism and
  published interfaces to shared resources
• are constructed from heterogeneous hardware and
  software probably from different vendors but all
  vendors conform to a published standard

12
Challenges of Distributed Systems

• Security
• Information resources are of high intrinsic value
  to users security is vitally important!
• Must have
• confidentiality protection against disclosure
  to unauthorized individuals
• integrity protection against alteration or
  corruption
• availability protection against interference
  with the means to access the resources
• Denial of service attack, Trojan horse attachment

13
Challenges of Distributed Systems

• Scalability
• System is scalable if it will remain effective
  when there is a significant increase in the
  number of resources and the number of users
• i.e. The Internet
• Challenges
• Controlling the cost of physical resources
• Controlling the performance loss
• Preventing software resources from running out
• Avoiding performance bottlenecks

14
Computers in the Internet
15
Computers vs. Web servers in the Internet
Date
Computers
Web servers
Percentage
1,776,000
130
0.008
1993, July
1995, July
6,642,000
23,500
0.4
1997, July
19,540,000
1,203,096
6
1999, July
56,218,000
6,598,697
12
2001, July
125,888,197
31,299,592
25
42,298,371
16
Challenges of Distributed Systems

• Failure Handling
• More failure types can occur in processes and
  networks
• Failures are partial some components fail while
  others continue to function
• Techniques for handling failures
• Detecting failures (checksums)
• Masking failures (retransmit dropped messages)
• Tolerating failures (user keeps trying)
• Recovery from failures (rollback state of
  component)
• Redundancy (hardware)

17
Challenges of Distributed Systems

• Concurrency
• Several clients attempt to access a shared
  resource at the same time
• Program threads
• Distributed software must be responsible for
  ensuring that servers and applications operate
  correctly in a concurrent environment

18
Challenges of Distributed Systems

• Transparency
• Concealment from the user and the application
  programmer of the separation of components in a
  distributed system
• System is perceived as a whole rather than a
  collection of independent components
• Programmer only concerned with the design of
  their particular applications

19
Transparency Forms

• Access transparency enables local and remote
  resources to be accessed using identical
  operations.
• Location transparency enables resources to be
  accessed without knowledge of their physical or
  network location (for example, which building or
  IP address).
• Concurrency transparency enables several
  processes to operate concurrently using shared
  resources without interference between them.
• Replication transparency enables multiple
  instances of resources to be used to increase
  reliability and performance without knowledge of
  the replicas by users or application programmers.

20
Transparency Forms

• Failure transparency enables the concealment of
  faults, allowing users and application programs
  to complete their tasks despite the failure of
  hardware or software components.
• Mobility transparency allows the movement of
  resources and clients within a system without
  affecting the operation of users or programs.
• Performance transparency allows the system to be
  reconfigured to improve performance as loads
  vary.
• Scaling transparency allows the system and
  applications to expand in scale without change to
  the system structure or the application
  algorithms.

21
The Enterprise
22
Enterprise Framework

• Schema for classifying and organizing the topics
  related to managing the enterprise
• Assists the organization to become more
  accountable and responsive
• Shows how enterprise architecture considers the
  design and operation of an organization from many
  aspects, perspectives, and diciplines

23
Zachman Framework for Enterprise
Architecture (www.zifa.com)
24
Distributed System Architectures

• Architecture Model what is it?
• Defines the way in which the components of
  systems interact with one another
• Defines the way in which components are mapped
  onto the underlying network of computers
• Decompose architecture of a distributed system
  into both vertical and horizontal tiers

25
Layers

• Application, operating system, and hardware layers

26
Tiers Internet Example

• Three tiers client, web server, and persistence
• Each tier consists of one or more components that
  collectively fulfill a common purpose

27
Logical and Physical Tiers

• Physical tiers
• Based on the assumption that application software
  components found in the different tiers reside on
  different computers
• Or, on different processors
• Logical tiers
• If system deployed on a single computer but has
  the separate software tiers

28
Physical Tiers (3)
Logical Tiers (3)
29
Case Study Single Tier Architecture Student
Services Application (S3)
The simplicity of single-tier architectures
provides a convenient initial framework for
subsequently examining more sophisticated
multi-tier architectures.
Tiers based on common functionality
30
Case Study Two-Tier Physical Architecture (S3)
The simplified design given in the previous
figure can be transformed into a two-tier
physical architecture by deploying the classes
related to the client aspects of the design on a
different host computer from the classes related
to the server aspects of the design.
31
Case Study Three-Tier Physical Architecture (S3)
The simplified two tier architecture presented in
the previous figure can be transformed into a
three-tier physical architecture by separating
the handling of persistence in the server tier
into its own tier.
Database replaces file I/O
32
Case Study Multi-Tier Physical Architecture
Large Telecommunications
Company
The key feature of this architecture concerns the
fact that any client can communicate with any web
server, but these clients cannot directly
communicate with other tiers.
33
Middleware

• Software layer that provides an abstract
  programming interface that hides, via
  encapsulation, the details associated with
  heterogeneity in both the layers and tiers of
  distributed architecture

34
Case Study Student Services EJB as Middleware

• While contemplating the design of the new student
  services application, you realize that using a
  middleware platform will result in a more robust
  application that can be developed in a shorter
  time.
• A web survey identifies three major middleware
  contenders
• W3s Web Services (http//www.w3.org/)
• Microsofts .Net (http//www.microsoft.com)
• Suns EJB Application Server (http//java.sun.com)
  

35
Case Study (S3) Architecture
A multi-tier architecture for the student
services application utilizing a Java 2
Enterprise Edition (J2EE), Java Enterprise Bean
(EJB) corresponding EJB application server
middleware technologies
uses MySQL
483 Student uses XP
36
Component Transaction Monitor (CTM)

• Component Transaction Monitor (CTM)
• Server-side application that combines the
  features of a traditional Transaction Processing
  Monitors (TPMs) and more recent distributed
  Object Request Brokers (ORBs)
• TPM emerged in 1960s at IBM to handle large
  online transaction processing associated with
  large systems (i.e., airline reservation system)
• ORB emerged to support the deployment of
  objects across a network (i.e, RMI, in Week 2)

37
Object Life Cycle

• Life cycle of an object is the life of an
  object from creation, modification, and deletion
• Object instance not domain data associated with
  the application (saved data)
• Factory Design Pattern
• Often used to encapsulate the functionality
  associated with the life cycle maintenance of an
  object
• This pattern separates the business logic of the
  domain being modeled from the objects life cycle

38
Case Study Student Factory in a Distributed
System

• Student Factory contains methods for creating,
  finding, and removing a Student object

Student object contains operations associated
with the domain application (i.e., addCourse
(course))
39
Case Study Student Factory in a Distributed
System using Singleton

• Factory can be conveniently implemented using a
  Singleton design pattern as shown in this example
• Hides the actual location of the business object
  from the user (i.e., two Student objects located
  on different servers)

Given this singleton design, a new Student object
can be created using Java Student aStudent
StudentFactory.getSingleton().create()
40
Persistence Tier

• In multi-tier enterprise architectures, the
  persistence tier encapsulates the logic for
  saving data to, and loading data from, persistent
  storage
• Within a CTM (application) server, enterprise
  information in the business-logic tier is
  represented using remote objects.
• As with all objects, a remote object captures
  state by encapsulating local data as a set of
  attributes. Consequently, the long-term
  persistence of an object requires saving its
  attribute values to non-volatile storage.

41
Persistence Tier

• Examples
• Java serialized objects (CS 434)
• Local files using XML
• Databases
• Design patterns developed to capture the saving
  of data to files or database
• Data Access Object (DAO pattern)

42
Design Patterns

• What is a design pattern?
• Patterns provide generic, reusable designs that
  solve problems at the design level
• Provides a proven, tested solution for a class of
  similar design problems
• Lend common terminology that you can use to make
  your own designs easier to document and
  understand
• Provides a common language for developers to
  use in meetings and documentation

43
DAO Design Pattern
44
DAO Design Pattern

• DAO used to separate business logic aspects of an
  object from the code used to access persistent
  storage
• In a distributed system, using a factory to find
  a remote object does not always require loading
  the object from persistent storage it could
  have been previously loaded and found on the
  network
• S3 Case study example when the Student object
  is sent a message to save itself, the Student
  will delegate the request via a message sent to a
  corresponding data access object (DAO)
• DAO knows how to save the object (write it to
  a particular database system, i.e., MySQL) and
  where (location of DB)

45
DAO Factory Pattern
46
DAO Factory Pattern

• A DAO factory pattern is often used to further
  separate the application server from the
  persistence engine.
• For example, consider a situation in which data
  may be saved either to a relational MySQL
  database or to an XML file.
• Business object, such as student, would request a
  data access object from a data access object
  (DAO) factory.
• Since the factory knows which type of persistence
  is being used, it returns a data access object
  (DAO) corresponding to the appropriate
  persistence engine.
• Specifically, if the application is currently
  using a MySQL database for persistence, a
  MySqlDAO object will be returned.

47
Case StudyS3 Saving a Student
48
Case StudyS3 Saving a Student

• Having investigated the benefits of the DAO
  approach to persistence, you decide to update
  your Student persistence to utilize a DAO and an
  associated DAO factory.
• While developing your design, you realize that
  youre not exactly sure how the student data
  access object should be implemented, but remember
  that JDBC can be used to save Java objects to a
  relational database.
• So, you have your DAO use JDBC.

49
JDBC

• Java DataBase Connectivity (JDBC) consists of a
  set of interfaces whose methods can be used to
  connect to and access data within a relational
  database using SQL.
• The salient methods of these JDBC interfaces are
  defined in the following UML diagram.

50
(No Transcript)
51
Connecting to the Database

• The first step in using JDBC is to load the
  driver you are using into the JVM.
• The following code, which only needs to be
  executed once, will load the MySQL driver.
• Note Explicitly loading the driver in this
  fashion allows you to avoid errors that occur in
  certain JVMs

try Class.forName(com.mysql.jdbc.Driver).newInstance() catch (ClassNotFoundException e) // Class not on the CLASSPATH . . . catch (InstantiationException e) // Error in the instantiation . . . catch (IllegalAccessException e) // Security policy violation . . . // try
52
Connecting to the Database

• The next step is to obtain a connection to the
  database.
• JDBC uses a Uniform Resource Locator (URL) to
  specify the information required to establish
  this connection. The general form of this URL is
• jdbcltsubprotocolgtltsubnamegt
• For example, the URL establishing a connection
  between a Java application and a MySQL database
  executing on the same computer is
• "jdbcmysql//localhost/rubs?userrootpassworddb
  admin

53
Connecting to the Database

• The jdbc token designates that this URL uses the
  JDBC protocol.
• The mysql token indicates that the ltsubnamegt
  adheres to the mysql sub-protocol, which
  specifies that a MySQL database named rubs
  located on the localhost is to be used and that
  our Java application is logging into this
  database as the user root with a password of
  dbadmin.

String url "jdbcmysql//localhost/rubs?userrootpassworddbadmin" try Connection dbConn DriverManager.getConnection(connUrl) catch (SQLException e) . . . // Unknown db or login failed // try
54
Querying the Database

• Assume the following book table is exists the
  previous rubs database
• The SQL query required to obtain the name and
  price of the book with id 81763 is
• select name,price from Book where id 81763

Idint Namevarchar Pricefloat
12294 Pride and Prejudice 7.95
81763 The Little Prince 5.50
55
Querying the Database

• The JDBC code required to issue this query to the
  database begins by first declaring a prepared
  statement.
• In this prepared statement, the optional
  arguments of the query are indicated with a
  question mark (?).
• Once all of the parameters of the statement have
  been supplied values, the statement can be
  executed and the results of this execution will
  be returned in a result set.

int id 81763 try String sqlStmt select Name,Price from Book where id ? PreparedStatement stmt conn.prepareStatement(sqlStmt) stmt.setInt(1, id) ResultSet rs stmt.execute() . . . catch (SQLException e) . . . // try
56
Mapping Result Sets to Objects

• If one or more rows in the table were found, the
  ResultSets next() method returns true.
• As book ids are unique, a maximum of one row can
  be found for the previous query.
• Hence, success can be checked with a single if
  statement (as opposed to a while loop).
• Once the database row has been obtained from the
  database, it is necessary to map the data into an
  object.
• This can easily be accomplished by creating a new
  instance corresponding to the row and using
  mutator methods to assign the appropriate values

57
Mapping Result Sets to Objects
if (rs.next()) Book book new Book(id) book.setBook(rs.getString(Name)) book.setPrice(rs.getFloat(Price)) return book else System.out.printl(There is no book with id id) // if
Note There are a number of more generic ways to
accomplish this mapping, however, to keep things
simple, they are not be discussed in this course.
58
CRUD Operations

• Create, Update, and Delete operations
• Handled by constructing the appropriate SQL
  statement and using JDBC to execute the
  corresponding statement.
• Since no results are expected from these
  operations, the executeQuery method is not used.
• Instead, the executeUpdate method is used, which
  returns the number of rows that were successfully
  created, updated, or deleted.

59
CREATE Row in Table
try sqlStmt insert into Book (id, name, price) values (?, ?, ?) PreparedStatement stmt conn.prepareStatement(sqlStmt) stmt.setInt(1, book.getId()) stmt.setString(2, book.getName()) stmt.setFloat(1, book.getPrice()) int rowsInserted stmt.executeUpdate(sqlStmt) catch (SQLException e) . . . // try
60
DELETE Row in Table
try sqlStmt delete from into Book where is ? PreparedStatement stmt conn.prepareStatement(sqlStmt) stmt.setInt(1, book.getId()) int rowsDeleted stmt.executeUpdate(sqlStmt) catch (SQLException e) . . . // try
61
UPDATE Row in Table
try sqlStmt update Book set price ? where id ? PreparedStatement stmt conn.prepareStatement(sqlStmt) stmt.setPrice(1, newPrice) stmt.setInt(2, book.getId()) int rowsUpdated stmt.executeUpdate(sqlStmt) catch (SQLException e) . . . // try
62
JDBC Resources

• JDBC Tutorial - http//www.stardeveloper.com/artic
  les/display.html?article2003090401page1
• JDBC Basics - http//java.sun.com/docs/books/tutor
  ial/jdbc/basics/index.html
• JDBC Product Overview - http//java.sun.com/produc
  ts/jdbc/overview.html
• Getting Started with JDBC API
  http//java.sun.com/j2se/1.4.2/docs/guide/jdbc/get
  start/GettingStartedTOC.fm.html
• Duke's Bakery - A JDBC Order Entry Prototype -
  Part I - http//java.sun.com/developer/technicalA
  rticles/Database/dukesbakery/
• Duke's Bakery - A JDBC Order Entry Prototype -
  Part 2 - http//java.sun.com/developer/technicalAr
  ticles/Database/dukesbakery2/

63
SQL Resources

• SQL Tutorial - http//www.stardeveloper.com/articl
  es/display.html?article2002030801page1
• MySQL www.mysql.com

64
Other Resources

• J2EE Core Patterns (DAO especially)
• http//java.sun.com/blueprints/corej2eepatterns/in
  dex.html
• Middleware A History of Objects, Components, and
  the Web
• http//www.awprofessional.com/articles/article.asp
  ?p345781seqNum2rl1