EAS304 Designing WebBased Applications

1
EAS304 Designing Web-Based Applications
Amine Khechfe, PSI Systems, Inc.Vice
Presidenta_at_psi-systems.com, 650-321-2640
x104June 20, 2003
2
Conference Topic Summary

• Currently, many IS/IT teams are facing decision
  points on the future of their applications and
  their implementation methodology. This session
  overviews the approaches involved in
  transitioning to a Web-based system. Some
  decisions clearly must be made before a team can
  proceed with development, such as selecting a
  server, language, environment, and tools. But
  other decisions may easily be overlooked because
  they are particular to the environment or a
  revision of decisions taken for granted. Failure
  to look at these decisions can make maintenance
  and proper architecture difficult or even
  impossible. We provide examples that illustrate
  how to combine HTML, JSPs, and Servlets for easy
  code maintenance, and whether and how to develop
  new ancestor code and even new naming conventions.

3
Abstract
What is this presentation about.

• Have existing application or building new?
• Status of Application
• Need versus want a web application
• What does that mean?
• What do we end up with?
• What questions to ask?
• What decisions have to be made
• New or existing expertise
• What time and money do we have to do this
• Decisions and approaches
• Implementation Methodology

4
Decisions

• Some obvious.
• Server
• Environment
• Language
• Tools
• Others subtle but essential
• Code Maintenance Issues
• Base Objects and new Ancestor Code
• Naming Conventions
• Workload partitioning
• User access
• Talk will focus on these decisions

5
Client Point of View
No change here for existing customers, new
customers though.
User POV
Things happen
Store Information
6
General Approach
Well emphasize specifics for web application
development

• Establish system goals for new web site
• Make design decisions
• Identify implementation issues
• Weigh ease-of-maintenance against
  time-to-production

7
Goals
General questions that will always apply

• Establish system goals for new web site
• Ask questions that define goals
• General questions that will always apply
• What do you want to accomplish?
• What is your timeline?
• What is your budget?
• Questions specific to working in a whole new
  environment
• Do you need to retrain programmers?
• Do you need to hire a consulting service to get
  your team up and running?
• Do you need to select new development tools?
• Have you considered how book marking will
  affect your control over screen flow?
• Document requirements

8
Design Questions

• Make design decisions
• Develop architecture
• Who will have access to the site (security)?
• Separate presentation (in the HTML/JSP layer)
  from processing (server side)?
• This can work well with separate staff for
  presentation (graphics, HMTL) and processing
  programming
• Establish flow of web pages
• storyboard
• UI issues (users can jump around and lose state)
• Browser version issues
• What are source code inheritance issues?
• How use available ancestor objects?
• Or need to write object library?

9
Design Questions

• Setting Standards
• How important is maintainability versus
  time-to-production?
• What is the look and feel?
• Use Style Sheets to make it easy to change
• Use standard naming conventions?
• Variables
• Function Names, parameters
• File names, directory names
• How interact with existing source and naming
  conventions?
• How manage programming team?
• How big is the team?
• What level of expertise on your team?
• Can you have individuals working on specific
  modules?
• Presentation work versus process programming

10
Setting Standards

• Maintainability
• Team Responsibilities
• Naming conventions
• Variables
• Parameters
• Session Attributes
• Potentially Separate Roles
• Presentation developers (HTML/JSP)
• Server Side Processing (Servlets, etc.)
• Ancestor code and EJB programmers
• Allows you to spread the load between different
  expertise

11
Application Design

• Interface
• New Look and Feel for Web Customers
• Who are the customers of this new interface
• Every case is unique
• Map out Web Flow regardless of environment
• Complete (expected) page flow first - remember
  users can use the Back button and book marks!
• May need new Design Standards
• Application Type
• Mostly Reports
• Intensive or sporadic Data Entry
• Shared Components

12
Implementation

• Identify implementation issues
• Choosing the tools
• What operating system will you be working with?
• What application server? (EAServer)
• What web server? (EAServer, Apache, IIS)
• How develop web pages? (HTML, JSPs, ASPs,
  PowerDynamo)
• What programming language? (PowerBuilder, JAVA)
• Weigh ease-of-maintenance against
  time-to-production

13
Technical Overview
Simple..
Browser
DB
App Server
Desktop
Front End
14
Good Situation for EA Server

• Large Number of users
• Scalability
• Sharing of objects
• Leverage existing NVOs/Programmer Expertise
• Stability. Excellent track record
• Solves Distribution Problems
• Reaches outside the enterprise
• Can optimize new parts of a distributed
  application
• Great for sharing code from PowerBuilder and Web
• J2EE is nice too

15
Alternatives to App Servers

• Expensive for smaller clients
• For small loads could use other middleware
• Cold Fusion
• Apache Jakarta
• Still Build Distributed Objects
• You can have a distributed application and not be
  web based. They are not the same.
• Be aware of communications issues between the
  different parts of an n-tier app
• Performance
• Local users can be slower in a web interface
• Remote users expect a slower experience

16
Middle-tier Programming Options
EA Server Objects and Language used

• Middle Tier is App Server
• NVOs, PowerBuilder Objects
• Use existing PowerBuilder expertise
• Share with existing applications
• Java
• Take advantage of talent pool
• Allows existing developers to expand their
  toolkit
• Servlets
• JSP
• Can call beans
• A Web Application does not mean a Java
  application
• EAS does not mean Java

17
Front End

• Practical for Data Entry
• Efficient
• Transparent
• No more distribution headaches
• Look and Feel
• Color Design
• Menus Toolbars, buttons
• Screen management
• Develop object library and UI standards

18
User Interface Issues
Questions we ask

• Is the desktop known
• Windows, mixed
• Is this all browser based
• Types of users
• Local/Remote
• User Experience
• Data Entry vs. Reports vs. information gathering
• Navigation Requirements
• Always remember any design constraints
• Expanded toolkit
• PowerBuilder (and 3 GL), HTML, Java, JSP, XML
• You could use all on one project

19
Developer Expertise
Project Planning for Developers

• Who does the work
• Existing in-house developers know the business
  but do they have time?
• Outside consulting firm allows you to work in
  parallel and get started immediately
• Do your homework. Each can succeed, doing both
  can be ideal.
• Training
• Many resources but do they apply to your
  situation
• What is the skill level of current developer
  group
• Training is good for retention
• Deadlines in new environments can make people
  quit
• Need a balance
• We are modernizing the work force!!!
• Actually, only adding a few tools to the mix

20
Implementation Methodology

• Break Problem into manageable parts
• Dont try to take it all on at once
• Database
• User Interface
• Middle Tier Objects
• Ancestor Code
• Begin with good design documents.
• Its impossible to think of everything up front
  but the more thought-out the design is the less
  time youll spend revising
• Having the document helps when you need to
  remember why something was programmed a certain
  way
• This gives your programming team time to learn
  new skills while waiting for the design to be
  completed

21
Methodology

• Assign work to team members according to skills
• Some team members may concentrate on HTML and
  formatting while others work on the data retrieve
  and saving
• HTML can be a good place to start for
  non-technical employees who want to be involved
• Spend time up front designing and coding base
  objects
• Security
• Drop down lists
• Classes or EJBs for objects with complex business
  rules
• Header/footer that gets copied into each HTML/JSP
  (for instance, copy right information)
• Consider templates for JSPs and Servlets
• JSP template can have references to Style Sheet
  and header/footer files already
• Servlet template can have includes and security
  check built in

22
Methodology

• Familiarize your team with a wide variety of
  techniques
• Sometimes a technique comes in handy when you
  least expect it (HTML frames dont work in many
  browsers but may be just what your application
  needs).
• If you want more info specifically about frames
  see http//www.w3.org/TR/REC-html40/present/frames
  .html
• Learn when to use JavaScript versus straight HTML

23
Methodology

• Learn from others
• Use View --gt Source for a limitless supply of
  sample code

24
Methodology

• Spend time up front defining coding style rules
• Tabs/indentation
• Presentation should be done on the browser side
• Business rules on the server side
• Variable naming
• See http//java.sun.com/docs/codeconv/

25
Designing the Application

• Who will have access to the web site
• What is the look and feel
• Standards
• Review other Industry members/competition sites
• Use Style Sheets
• Navigation
• Very important to prototype the web-page flow

26
Case Studies

• MedWeb
• www.MedProSoftware.com
• Information Systems for Student Health Centers
• Stanford PGNet
• www.Stanford.edu
• Has anyone not heard of Leland Stanford Jr.
  University
• Other commercial and government projects that we
  will not get into

27
Case Study MedWeb
Incremental Change and outreach

• Existing C/S System MedPro
• Student Health Information System
• Integrated, serves entire Health Center Staff
  requirements
• Needed to reach out to students
• Allow appointments any time of day
• Allow for private reason for visit
• Inexpensive, secure
• Distributed databases at each campus
• Reduces phone traffic and becomes 24 x 7
• Marketing benefits
• Also Lobby Check-in component
• Allows students to check themselves in
• Allows for Privacy of reason for visit
• Reduces lines in lobby and allows for other
  check-in areas

28
Case Study - MedWeb
Results

• Desktop application
• Minor modifications to allow setting up of
  appointments for the web clients
• Set aside certain amount for the web
• Web Portion
• Surveyed Students and administrators
• Screen flow in Visio/Word
• Needed Legal Language
• Potential Linux deployment eventually
• Low Unix/Linux experience did not want to deal
  with extra O/S upfront

29
Case Study MedWeb

• What did we do
• Apache Tomcat Free
• Intranet JDBC Connection
• JSP Front End
• Servlets
• Security User Supplies ID information
• Limited Exposure based on appointment templates

30
Case Study - MedWeb
Technical Overview
Apache Java Servlets
JSP
ASA
HTTP
JDBC
PowerBuilder
TCP/IP
Front End
31
Case Study - MedWeb
Key Road Map Issues

• Goal inexpensive web app
• Constraint quick development cycle
• These determined choice of Apache Tomcat with JSP

32
Case Study - MedWeb
Example JSP Sign In
33
Case Study - MedWeb
Sample Dynamic JSP
34
Case Study - MedWeb
Sample Dynamic JSP
35
Case Study MedWeb
Code Maintenance Tips

• JSP and HTML Tips
• Come up with standard indentation format
• Keep business logic out of JSPs
• Keeps code re-useable
• Otherwise JSPS and HTML can get huge
• Servlet Tips
• Keep business logic in servlets
• Keep database queries in servlets
• Keep HTML formatting out of Java code (as much as
  possible)
• Allows for code reusability

36
Case Study MedWeb

• Base Object Tips
• If it will be reused continually, make it a base
  object
• Database connectivity
• Creation of drop down lists
• Security checking
• Naming Convention Tips
• Come up with naming convention rules for your
  project
• Share rules with all developers
• Hire a naming convention Terminator to enforce
  rules

37
Case Study MedWeb

• Security Tips
• Authentication HTTPS
• Authorization
• Database logon verification
• Session variable verification

38
Case Study MedWeb
Code Snippets

• Logon.html
• Clean looking code
• Appointment.java
• Database query
• Authenticate.java, getAppointmentList()
• HTML formatting inside a servlet

39
Case Study - Stanford

• Existing extensive C/S Application
• Alumni/Fund Raising
• High Profile
• Sybase Database
• PowerBuilder Application
• Need to
• Serve Alumni
• Project image to outside world
• Serve heterogeneous users
• Reach other campus departments
• Industry standards
• Server Windows Expertise

40
Case Study - Stanford

• Technology
• J2EE
• Servlets
• Would not use existing PB Code
• Would use existing dB Code
• Built Proof of Concept Application
• Using EA Server and BEA WebLogic
• Used to compare both environments
• Hit on several main functions
• Decided to use EA Server

41
Case Study - Stanford
.

• Desktop application
• Minor modifications - theyre really separate
  applications
• Web application
• Designed primarily for single user to view and
  maintain personal data
• Worked extensively with separate departments and
  alumni groups to enable flexible look and feel
• Designed plug-and-play modules so each department
  or group could customize their web site
• Centralized login to better integrate web
  applications running on two different web servers

42
Case Study - Stanford
Technical Overview
Java Servlets
JSP, HTML
SQL Server
HTTP
JDBC
PowerBuilder
TCP/IP
Front End
43
Case Study - Stanford
Key Road Map Issues

• Goals flexible, customizable modules that can be
  used as building blocks
• Constraint leverage current programmer skills,
  short timeline, competing against outside vendor
• Alumni association already had an extensive web
  site created and maintained by an outside vendor.
  We had to prove that we could integrate with
  their existing site.
• These determined choice EAServer, PowerJ
  (followed by Jbuilder)
• Ability to use PowerBuilder non-visual objects
• Option of using PowerBuilder datawindows
• Developer familiarity with Sybase products

44
Case Study - Stanford
Example 1 dynamic Style Sheets
45
Case Study - Stanford
Example 2 dynamic Style Sheets
46
Case Study - Stanford

• Howd you do that?!
• Each servlet runs a security method before
  sending the user on to the requested jsp. The
  security method checks the user has permission to
  see the requested web page (based on your
  companys rules), then retrieves the appropriate
  header and style information for the current user
  (probably from the database, though it could come
  from files). Set a session attribute with the
  information which will be accessed by the jsp
• request.getSession().setAttribute(userSytle,a
  bunch of style sheet information)
• Then the jsp gets the attribute as one of the
  first lines of code
• ltrequest.getSession().getAttribute(userStyle)
  gt

47
Case Study - Stanford
Example ?
48
Case Study - Stanford
Example ?
49
Case Study - Stanford
Code Snippets

• Dont repeat coding efforts
• DropDownListBox
• Security method
• Make sure users are in the correct area
• Find out their default style settings

50
Summary
Expanded Expertise

• Can now solve more problems
• Everything we have used in the past
• EA Server Admin and development
• Apache Jakarta
• Cold Fusion
• HTML/JSP
• Java Servlets
• XML
• Microsoft ASP
• Not over night but doable step by step
• Break problem down into small pieces
• Use the right tool for the job.
• Its not one size fits all

51
Remember the Decisions..

• Some obvious.
• Server
• Environment
• Language
• Tools
• Others subtle but essential
• Code Maintenance Issues
• Base Objects and new Ancestor Code
• Naming Conventions
• Workload partitioning
• User access
• Talk will focus on these decisions

52
A watch it slide
A lesson learned

• Time is spent learning
• New Languages
• New Environment
• New messaging systems
• Temptation to start coding
• When you return from training
• Pressure is on to apply what you have learned
• Schedules are always tight
• NO! Wait!
• Dont fall into the trap
• Take time to establish standards
• Base Classes are still very important
• Get it almost right the first time!

53
Conclusion

• We still had a desktop application in all cases
• Needed a Power User Interface
• Web Interface served new users and new functions
• Allowed us to expand the reach of our application
• Two environments side by side
• Open Discussion
• Round Table of questions and approaches

54
Helpful resources

• http//www.sybase.com/products/applicationservers/
  easerver/extend
• http//www.sybase.com/detail?id1020914
• I have PDF files and can email out

55
Done! Celebrate!
56
Contact Information

• Email or call me
• Amine Khechfe
• PSI Systems, Inc
• Palo Alto, CA
• A_at_psi-systems.com
• 650-321-2640 x104
• www.psi-systems.com
• Input is appreciated
• Critique
• Future Presentations or ideas
• Topics to cover
• Your Experiences

57
Why this topic

• We were faced with this problem
• Could not find good resources to assist us
• Four year ago, not many people had taken that
  path
• We were surrounded with failure stories
• Marketing hyped it up
• So many choices
• Needed to get started
• Needed to succeed the first time
• We still seem to face this problem with other
  clients
• Is it really this complex

58
Movin on up to the Web
Just for the heck of it?

• What are you trying to accomplish with the web
  site
• Who are you reaching
• Dont just replicate your current programs on the
  web
• Determine the new uses
• Determine a time line
• Proof of concept
• Develop some of the components to test extremes
• Determine a budget
• There is no magic