TITLE GOES HERE
Download
Report
Transcript TITLE GOES HERE
WEB BASED DATA TRANSFORMATION
USING XML, JAVA
Group members:
Darius Balarashti &
Matt Smith
Idea
Web application that acts as an intermediary
among several databases in exchanging data
• highly customizable
• dynamic
• platform independent
Background – technology used
XML
SOAP
HTTP
Java Server Pages (JSP)
XML - eXtensible Markup Language
called extensible since it is not a fixed format
e.g. HTML
XML is a ‘meta-language’ – a language for
describing other languages
- e.g. Wireless Markup Language (WML)
designed to describe any structured data
“universal format for structured data on the
Web” – W3C web site
When should I use XML? When you need a buzzword in your resume.
W3SCHOOLS.COM
XML
vs.
designed to describe
data & focus on what
data is
No predefined tags
No inherit structure of
your tags
used for data
manipulation and transfer
HTML
designed to display data & focus
on how it looks
Predefined tags
Inherit structure built into tags
e.g. <h1>
used for displaying that same
data
XML is not a replacement for HTML
XML
Simple Example
HTML
<?xml version="1.0"?>
<CATALOG>
<CD>
<TITLE>EmpireBurlesque</TI
TLE>
<ARTIST>Bob
Dylan</ARTIST>
<COUNTRY>USA</COUNTR
Y>
<COMPANY>Columbia</COM
PANY>
<PRICE>10.90</PRICE>
<YEAR>1985</YEAR>
</CD>
</CATALOG>
<html>
<h2>Catalog</h2>
<body>
<table width=“100%”>
<tr>
<td>EmpireBurl</td>
<td>Bob Dylan</td>
<td>USA</td>
</tr>
<tr>
<td>Columbia</td>
<td>10.90</td>
<td>1985</td>
</tr>
</table>
</body></html>
Advantages of XML
data exchange between incomparable systems
–
Software independent
–
Hardware independent
–
plain text files
• data is stored outside of HTML
• can code documents more precisely
- reflects structure and semantics of that document
Transforming XML
DTD – document type definition
- defines tags in XML
- number, sequence, attributes,
and values of those tags
XSL – eXtensible Style Sheet
- browsers can’t display XML
- transforms XML into HTML
CSS – Cascading Style Sheet
- less control than XSL
SOAP – Simple Object Access Protocol
XML and HTTP based Protocol
- protocol for exchange of information
decentralized environment
- defines a framework for describing
what is in a message & how to
process it
All SOAP messages encoded in XML
Java Server Pages (JSP)
servlet = server side applet
- Java’s answer to CGI
- no GUI
static HTML with dynamic content from servlets
and/or JavaBeans
some Java advantages
–
–
Platform independent
Can utilize Java API for XML Processing (JAXP),
Java API for XML Messaging (JAXM), and Simple
Access API for XML (SAX).
XML & Java Application
XML document is parsed, data becomes
available to application
DOM (Document Object Model)
–
–
represents elements as tree nodes
use if need random access to data
SAX (Simple API for XML)
- fires events based on what it encounters
- write code to make sense of these events
XML & Java
Java is portable code, XML portable data
Applications completely portable
Java provides most robust set of
- API’s
- processors
- parsers
Why XML & JSP ?
can use SAX
3 main steps
Create object model
Create parser
Create handler
1.
2.
3.
Overall Approach
Web app. that is intermediary between 2
databases
•User can select source data and transfer it to
different database(s)
• 2 distinct process
- configuration
- transformation
System Overview
System Overview and Environments
User
Client Side
XHTML THIN
CLIENT
Third Party Server
System Server
Source DB
(Oracle,
MySQL, SQL
Server)
Third Party Server
Microsoft Internet Information Server
Target
(Destination)
DBS
Internet
HTTP Protocol
XML DATA
HTTP Protocol
Configuration Process
User driven
- user selects source data
- user selects destination database
User select transformation options, if any
- direct mapping of data
- string manipulations
- simple calculations
Configuration Process
Describe Transformations
<<include>>
Use Case Model
Configure Data Mapping
Third Party Administrat
<<include>>
<<include>>
No Access Allowed
<<include>>
<<extend>>
<<extend>>
Database not Available
User
Configure Source Database
<<include>>
Set User Priveleges
Source Database
<<include>>
Configure Target Database(s)
<<include>>
Target Database[0]
<<extend>>
Target Database[1]
Load Source Schema
Load Target Schema(s)
Database not Available
Example Interface
Transformation Process
System driven
- takes user specified configurations and performs actual data
transformation
How?
- System sends SOAP request to the module controlling the source
database.
- Module connects to database and receives the data tuple.
- System sends data to the interpreter which transforms the data.
- Data is sent to the module controlling the destination database.
- Module loads the data into the database.
Use Case Model
Data Transformation Process
User
Initiate Transformation
<<include>>
<<include>>
Target Database
Request/Receive Data Process
Send Data Process
<<include>>
System
Transform Data
<<include>>
Source Database
Costs
Time
- done by April 2002
Money – can vary greatly
1.
2.
Software
- currently, none
Hardware
- none other than available on campus
Performance Requirements
• handle large
databases 10,000+
records
• less than 1 sec per
record
Constraints
Environmental
• Unknown bandwidth between system and
source/destination
• Unknown database optimizations
System
• Bandwidth
• Processor power
• Code optimization
Constraints [cont’d]
User
• Access Privileges
• Security
Maintenance
• Basic code/server maintenance
• Updating database specific modules
• Optimization
Alternative Designs
1.
Application server using Enterprise Java Beans
2.
Adv: any application environment, direct
transformations
Dis: complex, expensive, unreliable
Microsoft .NET platform
Adv: based on XML, any language
Dis: documentation, Beta version
Testing Methods
Testing Methodology: Rational Unified Process
User Interface Testing
Testing the user interface against necessary functionality.
Unit Testing
Testing the classes as individual components.
Development and implementation of test cases.
System Testing
Testing the classes as components in the system.
Development and implementation of test scenarios.
Scheduling Diagram [First Semester]
ID
Task Name
Start
End
Duration
Resource
Name
Percent
Complete
1
First Semester Design
10/1/2001
12/12/2001
53d
Team
30%
2
Business Modeling Phase
10/1/2001
10/10/2001
8d
Team
100%
3
MILESTONE: Problem
Definition[1]
10/1/2001
10/1/2001
0d
Team
100%
4
MILESTONE: Problem
Definition[2]
10/10/2001
10/10/2001
0d
Team
100%
5
Requirements Phase
10/11/2001
11/7/2001
20d
Team
50%
6
MILESTONE: Req Analysis[1]
10/22/2001
10/22/2001
0d
Team
100%
7
MILESTONE: Req Analysis[2]
11/7/2001
11/7/2001
0d
Team
0%
8
Analysis and Design Phase
11/8/2001
11/26/2001
13d
Team
0%
9
MILESTONE: Design
Specs[1]
11/26/2001
11/26/2001
0d
Team
0%
Sep 2001
9/2
9/9
9/16
Oct 2001
9/23
9/30
Nov 2001
10/7 10/14 10/21 10/28 11/4 11/11 11/18 11/25 12/2
Dec 2001
12/9 12/16 12/23 12/30
Scheduling Diagram (Second Semester)
ID
Task Name
Start
End
Duration
Resource Percent
Name
Complete
1
Second Semester Design
1/1/2002
5/22/2002
102d
Team
0%
2
Implementation Phase
1/1/2002
4/5/2002
69d
Team
0%
3
MILESTONE: User Interface
Prototype
1/10/2002
1/10/2002
0d
Team
0%
4
MILESTONE: Configuration
Process Functionality
2/18/2002
2/18/2002
0d
Team
0%
5
MILESTONE: Transformation
Process Functionality
3/18/2002
3/18/2002
0d
Team
0%
6
Testing Phase
4/8/2002
5/3/2002
20d
Team
0%
7
MILESTONE: Development
of Test Cases
3/25/2002
3/25/2002
0d
Team
0%
8
MILESTONE: Verification of
Test Cases
4/12/2002
4/12/2002
0d
Team
0%
9
Deployment Phase
4/16/2002
4/25/2002
8d
Team
0%
10
MILESTONE: Working
System Deployed
4/25/2002
4/25/2002
0d
0%
Jan 2002
1/6
1/13 1/20
Feb 2002
1/27
2/3
2/10 2/17
Mar 2002
2/24
3/3
3/10 3/17
Apr 2002
3/24 3/31
4/7
4/14
May 2002
4/21 4/28
5/5
5/12
5/19 5/26