EAS304 Designing Web-Based Applications

indexadjustmentInternet and Web Development

Nov 13, 2013 (3 years and 11 months ago)

80 views

EAS304 Designing Web
-
Based Applications

Amine Khechfe, PSI Systems, Inc.

Vice President

a@psi
-
systems.com
, 650
-
321
-
2640 x104

June 20, 2003

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.

Abstract


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

What is this presentation about.

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


Client Point of View


No change here for
existing

customers,
new

customers though….

User POV

Things happen

Store Information

General Approach


Establish system goals for new web site


Make design decisions


Identify implementation issues


Weigh ease
-
of
-
maintenance against time
-
to
-
production


We’ll emphasize specifics for web application development

Goals


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

General questions that will always apply

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?

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

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


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

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

Technical Overview

DB

App

Server

Browser

Desktop



Front End

Simple…..

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

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


Middle
-
tier Programming Options


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


EA Server Objects and Language used

Front End


Practical for Data Entry


Efficient


Transparent


No more distribution headaches


Look and Feel


Color & Design


Menu’s Toolbars, buttons


Screen management


Develop object library and UI standards


User Interface Issues


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


Questions we ask

Developer Expertise


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


Project Planning for Developers

Implementation Methodology


Break Problem into manageable parts


Don’t try to take it all on at once


Database


User Interface


Middle Tier Objects


Ancestor Code


Begin with good design documents.


It’s impossible to think of
everything

up front but the more thought
-
out the
design is the less time you’ll 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

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

Methodology


Familiarize your team with a wide variety of techniques


Sometimes a technique comes in handy when you least expect it (HTML
frames don’t 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



Methodology


Learn from others


Use View
--
> Source for a limitless supply of sample code


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/

Class

Noun, first letter of each word
capitalized.

Address, Person,
EmploymentDetail

Package

All lower case. Domain name is in
reverse order.

com.psi.service

Interface

Adjective. First letter of each word is
capitalized.

Runnable,
ActionListener

Meth
od

Verb. First word lowercase, additional
words should have first letter
capitalized.

loadData,
decodeReceipt

Variable

First letter lower case. Adiitional
words should have first letter
acpitalized.

k, idNumber

Constant

All uppercase. All words separa
ted by
underscores

MAX_WIDTH,
DEBUG_ON


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


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


Case Study


MedWeb


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

Incremental Change and outreach

Case Study
-

MedWeb


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

Results

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

Case Study
-

MedWeb


Technical Overview

ASA

Apache

Java

Servlets

JSP

PowerBuilder



Front End

JDBC

HTTP

TCP/IP

Case Study
-

MedWeb


Goal: inexpensive web app


Constraint: quick development cycle


These determined choice of Apache Tomcat with JSP

Key Road Map Issues

Case Study
-

MedWeb

Example JSP Sign In

Case Study
-

MedWeb

Sample Dynamic JSP

Case Study
-

MedWeb

Sample Dynamic JSP

Case Study


MedWeb


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

Code Maintenance Tips

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



Case Study


MedWeb


Security Tips


Authentication


HTTPS


Authorization


Database logon verification


Session variable verification

Case Study


MedWeb


Logon.html:


Clean looking code


Appointment.java:


Database query


Authenticate.java, getAppointmentList():


HTML formatting inside a servlet


Code Snippets

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



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

Case Study
-

Stanford


Desktop application


Minor modifications
-

they’re 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


.

Case Study
-

Stanford


Technical Overview

SQL

Server

Java

Servlets

JSP,

HTML

PowerBuilder



Front End

JDBC

HTTP

TCP/IP

Case Study
-

Stanford


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


Key Road Map Issues

Case Study
-

Stanford

Example 1 dynamic Style Sheets

Case Study
-

Stanford

Example 2 dynamic Style Sheets

Case Study
-

Stanford


How’d 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 company’s 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:


<%=request.getSession().getAttribute(“userStyle”)%>



Case Study
-

Stanford

Example ?

Case Study
-

Stanford

Example ?

Case Study
-

Stanford


Don’t repeat coding efforts


DropDownListBox


Security method


Make sure users are in the correct area


Find out their default style settings


Code Snippets

Summary


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


Expanded Expertise

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


A watch it slide


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!


Don’t fall into the trap


Take time to establish standards


Base Classes are still very important


Get it almost right the first time!


A lesson learned

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

Helpful resources


http://www.sybase.com/products/applicationservers/easerver/extend


http://www.sybase.com/detail?id=1020914


I have PDF files and can email out


Done! Celebrate!

Contact Information


Email or call me


Amine Khechfe


PSI Systems, Inc


Palo Alto, CA


A@psi
-
systems.com


650
-
321
-
2640 x104


www.psi
-
systems.com


Input is appreciated


Critique


Future Presentations or ideas


Topics to cover


Your Experiences

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



Movin’ on up to the Web


What are you trying to accomplish with the web site


Who are you reaching


Don’t 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


Just for the heck of it?