SharePoint RFP Tech - Standards Web Services .doc

PAGE

CONTENTS

21.0 Introduction

21.1 Purpose

21.2 Benefits

21.3 Conventions

21.3.1 Typography

21.3.2 Instructions

21.4 Acronyms and Abbreviations

21.5 Document References

21.6 Points of Contact

22.0 Infrastructure

22.1 Hardware

22.2 Software

22.3 Web Sub-site Guidelines

22.4 Directory Structure

22.4.1 Internet

22.4.2 E-Gov Architecture

22.4.3 Intranet Application Cluster

22.5 Infrastructure Summary

23.0 content

23.1 Process for Publishing Web Sub-site Static Content

23.2 Browsers and HTML Standards

23.2.1 Intranet

23.2.2 Internet

23.3 Static Content Development

23.4 Web Design for Persons with Disabilities—Section 508

23.5 HTML Editors

23.6 Page Sizing

23.7 Downloadable Documents

23.8 Graphics and Images

23.9 Content Summary

24.0 Applications

24.1 Active Server Pages Dynamic Pages

24.2 Servlets and JavaServer Pages

24.3 Enterprise JavaBeans

24.4 File Input/Output

24.5 Application Logging

24.6 Simple Mail Transfer Protocol Access

24.7 Browser Detection

24.8 Page Branching

24.9 Server-side Components

24.9.1 ActiveX Components

24.9.2 Java Classes

24.10 Mobile Code (Client-side components)

24.10.1 ActixeX Controls

24.10.2 Java Applets

24.11 Database Access

24.11.1 Active Service Page

24.11.2 Servlets and JSP

24.12 Third-Party Components

24.12.1 Active Server Page

24.12.2 Java 2.0 Enterprise Edition

24.13 Client-Side (In-Browser) Processing

24.14 JavaScript

24.15 Style Sheets and Layering

24.16 Dynamic Fonts

24.17 Distributed Processing

24.17.1 ASP Application State

24.17.2 J2EE Application State

24.18 Application Development

24.18.1 Browser Compatibility

24.18.2 User-Specific Applications

24.18.3 General (ICE Enterprise-wide) Applications—Intranet

24.18.4 Designing for the Common Denominator

24.19 Development Environments

24.19.1 Development Environment

24.19.2 Environment Options for Visual Basic V6.0 (ActiveX Components)

24.19.3 Report Development

24.20 Application Deployment

24.21 Application Documentation

Appendix A—Acronyms and Abbreviations Appendix B—Web Development Best Practices Appendix C—Use of the Notedata.dll Utility Appendix D—White Paper for the Use and Performance Considerations of Session Variables for the Internet/Intranet Web Services Appendix E—Quick Reference Guide for Activereports for the Internet/Intranet Web Services

EXHIBITS

2Exhibit 1: Typographical Conventions

2Exhibit 2: Sources Used in S&G

2Exhibit 3: ICE OCIO AI&I Team Contact Information

2Exhibit 4: Web Sub-site Guidelines

2Exhibit 5: USCIS and ICE Internet Directories

2Exhibit 6: eGov HTTP Server Directory

2Exhibit 7: eGov Application Server Directory

2Exhibit 8: Intranet Application Cluster Directory

2Exhibit 9: OCIO AI&I Production Hardware Tools

2Exhibit 10: OCIO AI&I Approved Software List

2Exhibit 11: ICE Intranet Web site HTML Elements

2Exhibit 12: Content Development Technologies

2Exhibit 13: Approved Versions of DLLS

2Exhibit 14: Approved Version of JAR Libraries

2Exhibit B-1: Function and Variable Format B-

2Exhibit B-2: Variable Name Prefixes B-

2Exhibit B-3: Variable and Routine Qualifiers B-

2Exhibit B-4: Variable Scope B-

2Exhibit B-5: Scope and Usage Prefixes B-

2Exhibit B-6: Object Naming Convention for Database Objects B-

REVISION HISTORY

Note:

This Revision History was not used prior to Version 3.6. Revision details before then are unavailable.

4.5 Application Logging

4.18.1 Development Environment

Updated Sections:

2.4.3 Intranet Application Cluster, Exhibit 6

3.8 Graphics and Images

4.2 Servlets and JavaServer Pages

4.4 File Input/Output

4.10.2 Servlets and JSP

4.11.1 ASP

4.16.2 J2EE Application State

4.18 Development Environments

Renumbered sections:

4.5—4.20

HTY00.30014-00.UBO-EDS

2.2 Software

2.5 Infrastructure Summary, Exhibit 8.

HTY00.30014-00.UA0-EDS

4.3 Enterprise JavaBeans

4.10, Third party components

4.10.1 ASP

4.10.2 J2EE

4.15.2 J2EE Application State

Updated Sections:

2.2 Software

2.5 Infrastructure Summary

4.4 File Input/Output

4.9.2 Database Access—Servlets and JSP

4.18 Application deployment

Renumbered sections

4.3—4.8 to 4.4—4.9 and 4.9—4.17 to 4.11—4.19

HTY00.30014-00.UAO-EDS

4.6, JavaServer Pages to 4.2, Servlets and JavaServer Pages

Added Sections:

4.4, SMTP Access

4.7, Database Access—Details pertaining to the uses of databases from within Web applications

4.7.1, ASP

4.7.2, Servlets and JSP

Appendix B—ActiveReports Quick Reference Guide

Updated Sections:

Note: Each section was reviewed and modified for accuracy and grammar

2.2, Added MDAC V2.6 and Crystal Reports V8.0

2.5, Added Java 2 SDK, MDAC v2.6 and ActiveReports

4.2, Added paragraph pertaining to the Java SDK version

4.3, File Input and Output—Added information pertaining to Java development

4.5, Page Branching—Removed reference to Appendix D

4.14.1, Added Disable Session State Command

Renumbered sections 4.2—4.16 to 4.3—4.17

HTY00.30014-00.F*0-EDS

2.2, 2.5, & 4.6, Updated Resin Version to 2.1.1

HTY00.30003-00.F*0-EDS

2.4, Directory Structure

2.4.1, Internet

2.4.2, eGov Architecture

Appendix C. Use of NoteData DLL

Updated Sections:

1.4.2, Points of Contact—Updated

2.2, Software—Added RESIN reference

2.5, Infrastructure Summary—Added references to TeamSite, Windows Script 5.5, and RESIN

Appendix B, Session Variables

Development Environment—added “directory” to bullet pertaining to lowercase characters.

JavaServer Pages—added session variables paragraph.

HTML Editors—replaced entire text with current text.

Added Sections:

Appendix B

Updated Sections:

Application State—added session variables paragraph and bullets.

Development Environments—added Oracle reports paragraph.

1.0 Introduction

1.1 Purpose

The Standards and Guidelines for the ICE Internet/Intranet Web Services (hereafter referred to as the S&G) has the following objectives:

· Provides a basis for a consistent look and feel for Web design across U.S. Immigration and Customs Enforcement (ICE) Web sites

· Provides a common reference for the development of ICE Web pages and integrates research and experience on Web design with the standards and expectations of ICE

· Incorporates reuse strategies of Web development to expedite the design process

· Documents expectations for application development in order to enable the Application Integration and Infrastructure (AI&I) team to support Web applications

To achieve these goals, this S&G document defines requirements, guidelines, best practices, and restrictions for creating and maintaining Web pages and Web applications.

1.2 Benefits

Defined standards and guidelines for designing ICE Web sites benefit the ICE application owners, developers, and the various users. Standards promote consistency that enables users to navigate more easily, applications to operate more reliably, and application owners and developers to design more efficiently. These standards result in time and cost savings for ICE, while ensuring the production of quality Web pages and Web applications. However, these standards and guidelines will evolve with technology. The S&G serves as a guide for Web design standards but cannot be considered inclusive or complete because of the fast pace of evolving technology. The information contained in the S&G will be updated as ICE Office of the Chief Information Officer (OCIO) AI&I team members identify a need. ICE application developers and users should always verify the most current requirements with a member of the ICE AI&I team when developing a Web site or Web application. Names and contact information for the ICE OIRM AI&I team are listed in Section 1.6.

Note:

The Office of Information Resources Management (OIRM) has been reorganized into the OCIO.

1.3 Conventions

1.3.1 Typography

The typographical conventions used in this document are explained in Exhibit 1.

Exhibit 1: Typographical Conventions

1.3.2 Instructions

The following primary standards defined in this guide are used to promote good Web design:

· Standards are directions provided to a development effort that must be closely followed in order for the Web site or Web application to be hosted by the AI&I team.

· Guidelines are directions provided to a development effort that must be followed unless the implementation of specific business requirements would be precluded.

· Best practices are directions provided to a development effort that should be followed to either reduce operational requirements, improve application availability, or better the end user experience.

· Restrictions are prohibitions against design elements or implementation details that, while possibly considered standard within the IT industry, are not consistent with ICE standards and the use of which would prevent the AI&I team from hosting the application.

1.4 Acronyms and Abbreviations

Appendix A lists and defines the acronyms and abbreviations used in this document.

1.5 Document References

Exhibit 2 lists the sources referenced in this document.

Exhibit 2: Sources Used in S&G

ICE Systems Development Life Cycle Manual, Version 6.0, Volume I, April 5, 2002 (CFY00.90063-01.F*0-SAI), and Volume II, April 19, 2002

(CFY00.90063-02.F*0-SAI)

http://powerport.ice.dhs.gov/tapweb/

1.6 Points of Contact

ICE project managers and Web site or Web application owners or developers who intend to publish a Web site or Web application should contact either the ICE Public Affairs Office (PAO) or the U.S. Citizenship and Immigration Services (USCIS) Office of Web Management (OWM); and the OCIO AI&I team as early as possible. Two agency offices are noted here because the AI&I team currently hosts Web sites and Web applications for both agencies. Project Managers should contact the content manager for their respective agency. They should be prepared to provide general content information and the cooperation needed to develop the Web site or Web application in accordance with current OCIO standards and guidelines, which includes the current Systems Development Life Cycle (SDLC) process. To ensure a smooth implementation with minimal impact on the Web sub-site design, please contact the OCIO AI&I team before beginning development.

Exhibit 3 lists the key contacts for the ICE OCIO AI&I team.

Exhibit 3: ICE OCIO AI&I Team Contact Information

USCIS OWM

ICE PAO

ICE OCIO AI&I Team

2.0 Infrastructure

Infrastructure, in this context, is the hardware environment that supports Web-based technologies. This section provides basic information about the configuration of OCIO Web servers and other related infrastructure issues. For detailed information about specific Web sites and Web applications, contact a member of the OCIO AI&I team (see Exhibit 3 for contact information). For more information about required documentation for the development and maintenance of approved Web sites and Web applications, refer to Section 4.20.

2.1 Hardware

By prior agreement with the OIRM (including agreements on required service levels as embodied in a service level agreement [SLA]), content may be published on the OCIO-maintained Web servers. For further definition of the SLA, information about where it may be obtained, and how it should be completed, contact the OCIO AI&I team.

OCIO guidelines for ICE Web servers include the following:

· The server must have sufficient power to support applications and users.

· The server must maintain an adequate level (close to 10 percent) of average CPU utilization during periods of average Web access demand.

· Disk space must be adequate to support static content that is published.

· For those Web sites or Web applications that are deemed excessively large (according to the OCIO AI&I team’s assessment), special provisions may need to be made to increase the available disk space, which is done at the expense of the ICE Web site or Web application owner.

· The OCIO AI&I team must have access to remote data sources, if required.

· There should be redundancy and fail over for mission-critical material.

Note:

The ICE Web site or Web application owner may be required to purchase additional hardware to augment the OCIO Web environment.

2.2 Software

The OCIO production and development servers are generally constructed according to Microsoft Web server methodology. ICE Web servers utilize the following components:

· Microsoft Windows 2000 Service Pack (SP) 4

· Microsoft Internet Information Server

· Microsoft Index Server

· Microsoft ActiveServer Pages (ASP)

· Live Publish

· Resin

· ActiveReports

· ASPMail

· Microsoft Data Access Components (MDAC)

· Java 2.0 Standard Edition (J2SE) Java 2 Software Development Kit (SDK) (Standard Edition)

· Java 2.0 Enterprise Edition (J2EE) Java 2 SDK (Enterprise Edition)

To verify current software versions for server components, refer to the ICE OCIO AI&I Approved Software List (see Exhibit 10). Software components not included in this list may be approved for use on a case-by-case basis through the Information Technology Change Request (ITCR) process. In such a case, the requesting party must justify the need for the unapproved version(s) of component(s), purchase any necessary licenses, and contact the ICE OCIO Technical Architecture Branch to request approval for the component(s) use and implementation.

The ICE OCIO Technical Architecture Branch will then evaluate the new version(s) of component(s) and consider comparable products. If the new version(s) of component(s) are approved, they will be added to the ICE OCIO AI&I Approved Software List.

In the interest of security, additional restrictions to normal access controls have been applied. These restrictions affect files and directories, as well as registry keys, and may cause some technology implementations to function incorrectly. Web site or Web application owners should submit their Web sites or Web applications to the OCIO AI&I team as soon as possible to ensure that such problems are addressed and resolved.

Any Web site or Web application owner who plans to develop content for deployment in the ICE Application Infrastructure environment should contact the OCIO AI&I team early in the design process. Early notification will help establish effective communication between the two groups and prevent potential deviations from standard development practices. In addition, the OCIO AI&I team may have already determined solutions for potential issues.

Web sub-site developers who intend to have their Web content hosted on an ICE Web server must contact the OCIO AI&I team for full IIS configuration instructions.

Note:

The application owner may be required to purchase additional software to augment the ICE Application Infrastructure environment.

2.3 Web Sub-site Guidelines

Web sub-sites should adhere to the guidelines listed in Exhibit 4.

Exhibit 4: Web Sub-site Guidelines

(Note: For Oracle databases, Microsoft drivers are preferable to the native Oracle drivers.)

(Note: Because the application will be deployed in a clustered environment, the files may need to be accessible from every server.)

2.4 Directory Structure

Each Web site and Web application supported by the OCIO AI&I team must be organized within specific directory structures. In addition, Web sites and Web applications should be developed in a manner that is conducive to relocating the application in the future. This includes using relative links wherever possible and avoiding the use of hard-coded physical paths. ICE Web sites and Web applications currently hosted in the ICE Application Infrastructure environment are stored in a subdirectory located within a directory folder that is labeled web, which is located within the root of the second logical drive (the D:\ drive).

The following sections provide detailed information related to the directory structure of ICE Web applications. Questions regarding the ICE Web infrastructure should be directed to the OCIO AI&I team (see Exhibit 3 for contact information).

2.4.1 Internet

The USCIS and ICE Internet Web sites are located in directories labeled uscis and ice respectively, within the web directory folder. Both folders contain the following subfolders (directories):

· root–root of the Web site plus other documents that do not logically belong in either graphics or text

· text–text-only version of the Web site

· graphics–standard version of the Web site

The virtual directory labeled /graphics is mapped to a physical directory labeled /content within the graphics Web site. A second physical directory labeled /exec, which is located under the graphics directory, contains all of the executable files used on the Web site. It is referenced through the virtual directory labeled /graphics/exec. Similar directory structures are automatically created for the text-only Web site, creating /text and /text/exec virtual directories. Exhibit 5 outlines the ICE Internet directory and assigned permissions.

Exhibit 5: USCIS and ICE Internet Directories

2.4.2 E-Gov Architecture

The eGov architecture consists of hypertext transfer protocol (HTTP) servers and application servers. The HTTP servers generate responses to client requests, support static content, and forward requests for JavaServer Pages (JSP) and servlets to the application servers. The application servers manage requests for JSPs and servlets and send the results back to the HTTP servers.

2.4.2.1 E-Gov HTTP Servers

Similar to the Internet configuration, all content located on the HTTP servers is contained in a directory folder labeled egov within the Web directory. The Web directory contains directory subfolders labeled root, graphics, and text. The graphics and text directories are each map points for the virtual directories that are labeled /graphics and /text. Because all content located on the HTTP servers should be static, no exec or content directories are required. Requests for dynamic content are filtered by the Resin Internet Server Application Programming Interface (ISAPI) filter and forwarded to the application server. A virtual directory labeled scripts is created at the root of the Web site to store the Resin ISAPI filter. The OCIO AI&I team creates a directory for each application under the graphics and text directories, and may also create further subdirectories within the application directory, as determined by the application developers.

To ensure logical separations between static and dynamic content, Web applications should not exist in duplicate directories on the HTTP and application servers. In other words, if an application is using a directory labeled jsps on the application server to store files with a .jsp extension, this directory should not exist on the HTTP server.

Exhibit 6 outlines the (Electronic Government) E-Gov HTTP server directory and the assigned permissions.

Exhibit 6: eGov HTTP Server Directory

2.4.2.2 E-Gov Application Servers

To maintain consistency between the application servers and the HTTP servers, both servers maintain the same basic directory structure. The Web folder contains a folder labeled egov, which in turn contains folders labeled text and graphics. The graphics folder contains subfolders (directories) designated for each application.

All associations with virtual paths are performed through the <web-app> section of the Resin configuration. Applications requiring specific additional <web-app> information may include this information using a web.xml file, which is located in the web-inf directory under the application directory. In addition, necessary application files that are separate from actual scripts stored within the directory structure of the Web site are installed in a specific application directory created under D:\apps.

Exhibit 7 outlines the eGov application server directory and the assigned permissions.

Exhibit 7: eGov Application Server Directory

2.4.3 Intranet Application Cluster

On the Intranet application server, files are located in directories labeled ice_apps and cis_apps within the Web directory. These directories contain a single directory labeled root, which stores all files available through the Web servers. Each application will be given a directory within root that is unique to that application and referred to as <app-dir>. Application content that requires script permissions should be separated from content that does not require script permissions. Content that does not require script access should reside in directories labeled content and images, depending on the type of content. If any file input/output is required by the application, such files should be in a directory labeled data, which is located within <app-dir>. Necessary application files that are separate from actual scripts stored within the structure of the Web site will be installed in a specific application directory created under D:\apps.

Exhibit 8 outlines the Intranet application cluster directory and the assigned permissions.

Exhibit 8: Intranet Application Cluster Directory

2.5 Infrastructure Summary

Exhibit 9 lists the OCIO AI&I production hardware tools.

Exhibit 9: OCIO AI&I Production Hardware Tools

Exhibit 10 lists the OCIO AI&I approved software list. For the most recent version of the Approved Software List, please consult the Electronic Library (Approved Software List).

Exhibit 10: OCIO AI&I Approved Software List

3.0 content

General Web content is broadly defined as a collection of text, images, hypertext links, and multimedia elements intended for all Web site users. Developers should become familiar with the requirements, restrictions, and good practices found in this document, as well as various Web site development books and online resources, before designing Web pages for ICE Web sites.

3.1 Process for Publishing Web Sub-site Static Content

Static content is information that requires no additional server processing or user interaction for it to be generated and displayed. The steps listed below outline the procedure for publishing new static Web sites on the OCIO Internet or Intranet Web servers. For additional information regarding publishing dynamic content Web sites, refer to Section 4.0, Applications.

The following steps outline the process for publishing static content:

1. The Web site or Web application owner contacts the OWM/PAO and OCIO AI&I team to express an interest in publishing static information on the ICE Internet or Intranet Web site or Web application. This notification should occur early in the Web application development cycle to ensure that the Web site or Web application is designed according to OCIO Web standards.

2. The OCIO AI&I team evaluates the technical feasibility of hosting the proposed Web site or Web application (based on infrastructure and technologies supported at the time of the request). If a technology is not supported at the time of the request, the Web site or Web application owner should contact the ICE OCIO Technical Architecture Branch for further information. (See Exhibit 2 for a link to the ICE OCIO Technical Architecture Branch Approved Software List.)

3. The involved parties—the OWM/PAO, the OCIO AI&I team, and the ICE Web site or Web application owner—coordinate to fulfill necessary requirements to establish and maintain the new Web site or Web application. The Web site or Web application owner is required to submit Form G-1019 to the OWM/PAO. (Contact the OWM/PAO to obtain a Form G-1019. See Exhibit 3 for contact information.)

4. The Web site or Web application owners and developers deliver the Web site or Web application to the OCIO AI&I team for technical evaluation.

5. The OCIO AI&I team, in coordination with the Web site or Web application owner and developers, installs the Web site or Web application in the appropriate OCIO Internet or Intranet Web environment.

6. The OWM, in coordination with the Web site or Web application owner, approves the publishing of the Web site or Web application to production.

3.2 Browsers and HTML Standards

Sections 3.2.1 and 3.2.2 define Web development standards established by the OCIO.

3.2.1 Intranet

The OCIO has determined that Internet Explorer V5.5 or higher and Netscape V4.79 are the standard Web browsers that support content developed for the ICE Intranet Web site. Designers who develop static content must be familiar with, and adhere to, the Internet Explorer V5.5 Browser/Netscape V4.79 Object model and the features supported therein. However, because a large number of ICE users still use older versions of Internet Explorer or Netscape Navigator, every effort should be made to enable Web pages to function correctly in these environments as well.

Exhibit 11 lists some basic HTML elements used on the ICE Intranet Web site.

Exhibit 11: ICE Intranet Web site HTML Elements

3.2.2 Internet

All Internet content must conform to the standard look and feel of the ICE Web site. In addition, as of May 2001, Web pages for the ICE Internet Web site must be compatible with the current browser standard: MS Internet Explorer V5.5 (or higher) and Netscape V7.0. Contact the OWM/PAO or the OCIO AI&I team for updates to these standards.

3.3 Static Content Development

The following defines standards and guidelines for static content development as determined by the OCIO, as well as outlining good practices that will guide effective Web site development. Contact the OCIO AI&I team for additional guidance.

· Page and directory names: Must be in lowercase characters and must not contain spaces.

· Folder and file names: Must be alphanumeric. DO NOT use punctuation or special characters of any kind other than the underscore.

· HTML suffix: Avoid this suffix and use .htm instead.

· File and folder names: Limit to no more than 15 characters in length, excluding the file name extension.

· <p>, <br>, <blockquote>, <table> tags, and corresponding end tags: Place on individual lines to increase readability and enable editing by the OCIO staff.

· Meaningful <title> tags: Place on every page; Index Server displays the title of each document on the search results page.

· All Web site-entry pages: Should be named index.htm or index.asp. If the Web site warrants multiple directories, then each directory should contain a page with the default name of index.htm, index.asp, or index.jsp.

· All links to content outside the ICE Web site: Must use the OCIO “leaving ICE” page function. For example, perform the following to link to www.abc.com:

· From the Internet, use: <a href=”/graphics/exec/leaving.asp?http://www.abc.com”>

· From the Intranet, use: <a href=”/exec/leaving.asp?http://www.abc.com”>

· Pages that present the same subject: Should be placed in a separate, designated subdirectory.

· Relative links: Should be used to ensure links between pages in a Web sub-site will work properly, regardless of the absolute placement of the Web sub-site directory tree.

· Standard HTML content: Place in a virtual directory off the root. Refer to Section 2.4, Directory Structure, for details.

· Pages that require script execution: Must be isolated in directories that are separate from standard HTML pages. Refer to Section 2.4, Directory Structure, for details.

· All executable files for download: Must reside in directories without script-execute permission. (Otherwise, the user will not be able to download the file, and the program will try to execute on the server.)

· Files that require write permission: Must be isolated in directories that are separate from standard HTML pages. These files should be placed in a virtual directory under the data directory. Refer to Section 2.4 for details.

· Animated Graphics Interchange Formats (GIF or .gif): Should not be used because they are not compliant with Section 508 of the Rehabilitation Act of 1973. Refer to Section 3.4 for details.

· Images: Place in a centralized location, for example, /yourapp/images.

· Duplicate graphic files: Should not be placed in different subdirectories, for example, /yourapp/sub1/button.gif, and /yourapp/sub2/button.gif.

· Section 508 regulations: Comply with all Section 508 regulations. Refer to Section 3.4 for further information. Examples of compliance with Section 508 include the following:

· Use row/column headers or scope HTML attributes within tables

· Use meaningful alt key words in the <image> tag for all images that have informational content, for example, alt=“Picture of Commissioner”

· Use alt=”” for spacer images

3.4 Web Design for Persons with Disabilities—Section 508

Section 508 is an amendment to the Rehabilitation Act of 1973. Section 508 establishes requirements for all electronic and information technology developed, maintained, procured, or used by the Federal government. All Web sites developed within the ICE Application Infrastructure environment must be designed to be used by people with disabilities. Some examples of common Section 508-compliant design practices are listed below:

· Provide text equivalents for all non-text elements.

· Provide summaries of graphs and charts.

· Provide alternative content for features (for example, applets or plug-ins) that may not be supported by accessibility interfaces.

This list is not intended to be inclusive. Refer to http://section508.gov/ published by the GSA for more information about Section 508 regulations.

3.5 HTML Editors

Numerous commercial off-the-shelf (COTS) HTML editors are available that feature a “what you see is what you get” environment. Any HTML editor is acceptable for Web sites within the ICE Application Infrastructure environment as long as the resulting HTML content adheres to all OCIO standards. Web site and Web application developers and owners must review all HTML generated by the HTML editor to ensure that the code is compliant with all OWM and OCIO Web standards. For example, Microsoft FrontPage defaults to using FrontPage Webbots automatically. FrontPage Server Extensions are required for Webbots, but are not installed as part of the standard ICE Web server configuration. This means that pages developed in FrontPage using Webbots will not function on the ICE Internet and Intranet Web sites. Other editors transparently incorporate JavaScript tags and other elements into pages that may or may not be compliant with OWM and OCIO standards. Section 4.13 provides details for JavaScript development.

3.6 Page Sizing

Visitors to a Web site should be able to quickly see information and options. Web pages should load in less than 10 seconds. If the Web page takes longer to load, the audience might become impatient and report performance issues. Web site developers should keep in mind that some areas of the ICE are still connected through much slower networks than those commonly found in larger offices. Web pages will download more slowly for users in those areas.

· Requirements for Web page file sizes are as follows:

· The average page size on an ICE Web site should be less than 70KB. If, at any time, a large graphic must be included, the ICE Web site or Web application owner must include a warning to the user, along with a link to the image specifying the image size and how long it will take to download.

· Ideally, all pages should dynamically resize to use all of the horizontal monitor space available. The pages should be configured to view at a screen resolution of 800 x 600 with no horizontal scrolling.

· Guidelines for Web page file sizes are as follows:

· Web pages should be a reasonable size; they should not take longer than average to download. Efficient download time is particularly important for users who connect at lower speeds to access the Web site. If the file size for the Web page is too large, break the page into smaller files and provide links to each one through a table of contents.

· The layout of each page should be clear enough for Web site visitors to grasp the navigation scheme and understand how to select a “next step” option at a glance.

3.7 Downloadable Documents

The OCIO recommends using a portable document file (PDF or .pdf) format for downloadable documents instead of proprietary formats, such as Microsoft Word or Corel WordPerfect formats. The latter formats require users to purchase and install additional software. PDF files may be viewed in Adobe Acrobat Reader, which is a free, downloadable browser plug-in for viewing .pdf files. When linking to a document on an ICE Web site, developers should always include explanatory text that demonstrates how to obtain appropriate browser plug-in (reader) for the document. PDFs should be viewable in Adobe Reader V4.x and higher.

3.8 Graphics and Images

Web page download times are contingent on the size and number of graphics on the page. Guidelines for adding graphics and images to a Web sub-site are listed below:

· Limit the use of large images, so that users are not frustrated by long download times and leave the Web site prematurely.

· Use browser-safe color palettes to minimize file saves and create images with maximum color consistently on most browsers. Refer to the World Wide Web Consortium Web site (http://www.w3c.org) for more information.

· Place width and height attributes within all <img> tags to ensure page formatting is consistent while a page loads. However, do not use these attributes to change the size of an image. Web browsers do scale images effectively while maintaining their appearance. In addition, shrinking the dimensions of an image file will reduce its size and download time, while adjusting the size in HTML will not.

· Use Graphic Interchange Format (GIF or .gif) compressed image files for drawings and other graphics. This format is preferred because it is the most widely supported image type and produces images that look the same from machine to machine. Files that use less than 16 colors and use flat areas of color should be in .gif format. However, .gif files can become large and slow to download. Also, animated gif files are incompatible with Section 508 requirements.

· Use Joint Photographic Experts Group (JPEG, JPG, or .jpg) compressed image files when the Web sub-site file size needs to be minimized. This file type is preferred for photographs and other images because it is widely supported and because it allows images to be compressed at various rates to produce attractive graphics within size constraints. A file that uses more than 16 colors and uses color gradations should be in .jpg format. However, .jpg files require machines to have greater graphic capabilities and images tend to lose detail the more the images are compressed.

· Use Portable Network Graphics (PNG or .png) files when the Web sub-site size needs to be minimized and image transparency is desired. Unlike .gif and .jpg formats, .png provides for full alpha transparency and gamma correction between Macintosh and PC monitors. However, .png files require Netscape V4.x and Internet Explorer V4.x (with the exception of Internet Explorer V4.5 for the Macintosh) to display properly, and even then, gamma correction and alpha transparency are not consistently implemented.

· Avoid using graphic file types not mentioned above.

· Employ client-side image maps to divide images into separate links. Although this technology is supported, ICE Web application owners should provide alternate text on the image and separate textual links elsewhere on the page. The alternate links would allow users with adaptive technology easier access to the material on the page.

3.9 Content Summary

Exhibit 12 lists various content development technologies the OCIO AI&I team uses to create static Web pages.

Exhibit 12: Content Development Technologies

4.0 Applications

Specific standards and guidelines are provided as a baseline reference to aid in the development of Web-based applications that will be accessible from the ICE Web sites. The objective of these standards is to achieve higher quality applications, increase productivity, and simplify future maintenance efforts. Refer to the SDLC Manual for more information (see Section 1.5 in this document for a list of referenced documents).

4.1 Active Server Pages Dynamic Pages

The standard ASP environment is provided as part of the ICE/OCIO Web-hosted environment. ASP runs under IIS on the Web server as an Internet Server Application Programming Interface (ISAPI) filter. Whenever a Web client makes an HTTP request for an ASP file, ASP takes over from IIS, parses the entire file from top to bottom, processes the server-side script, and returns an HTML output file to IIS. IIS then sends this data stream to the requesting Web client or browser.

Currently, the scripting languages provided are VBScript and JavaScript, the default, out-of-the-box IIS scripting languages. Custom language plug-ins may be considered as the need arises. The most common language in use is VBScript. The choice of a scripting language is probably best based on familiarity with the language and the availability of code already done in a specific language.

4.2 Servlets and JavaServer Pages

· The JSP V1.1 and Servlet V2.0 specification provides ICE Web developers with a framework to create dynamic content on the server using HTML and Java code.

· The approved version of J2SE is Java 2 SDK (Standard Edition) V1.4.2_01. The approved version of J2EE is Java 2 SDK (Enterprise Edition) V1.3.1. All Java development should be performed using these versions and any deprecated classes should be avoided.

· After a comprehensive product evaluation, the ICE OCIO Technical Architecture Branch selected Caucho’s Resin V2.1.11 to incorporate JSP and JavaServlet technologies into the current ICE Web environment. Application developers should avoid using Resin-specific code wherever possible to allow for future changes to the J2EE application server.

· While IIS will continue to serve the HTTP requests for JSP pages, Resin V2.1.11 will serve all JSP and servlets. The resulting HTML is returned to IIS and forwarded to the client. Resin’s ISAPI filter is loaded within IIS and determines those requests for which Resin is responsible and forwards them to the Resin engine. The JSP page is then translated into a Java class, which is compiled into a servlet. This translation and compilation phase occurs only when the JSP file is first labeled, or when it subsequently changes (such as, Just in Time compilation). Thus, the programming of Java within Resin involves editing Java classes and JSPs and reloading the page without having to explicitly recompile the Java files.

· JSPs are text files that combine standard HTML and new scripting tags. These new tags can be divided primarily into directives, declaratives, scriptlets, and expressions. JSP directives, enclosed by the “<%@” and “%>” special tags, provide information about the JSP itself, such as the language and import statements. Declaratives that are enclosed by the “<%!” and “%>” tags are used to declare variables or functions used throughout the JSP. The scriptlet tags, “<%” and “%>”, enclose any valid Java code, which will be compiled and executed. JSP expressions, denoted by “<%=” and “%>”, provide a convenient method for embedding values with HTML.

The following is a short example of a simple JSP page combining HTML, JSP directives, and Java code.

<%@ page language=”java” %>

<html>

<head>

<title>Sample JSP Page</title>

</head>

<body>

<p>

<%! int numTimes; %> numTimes =5;

for (int i = 0; i < numTimes; i++) {

Hello World - <%= i %> <br>

</p>

</body>

</html>

· JSP directives serve as messages to the JSP container from the JSP. They are used to set global values, and they do not produce any output to the client. All directives have scope of the entire JSP file. Code within a directive tag is placed outside of the service method so potential threading issues must be taken into account for any variables declared.

· Scriptlet tags (<% %>) denote the start and end points for Java code that is directly written in the JSP, and standard actions are specific tags that affect the runtime behavior of the JSP and the response sent back to the client. This code is then incorporated within the service method of the generated servlet.

· Additional JSP functionality can be created using taglibs. Taglibs are sets of custom JSP tags and associated Java classes capable of processing those tags. As with all third-party code libraries, using Taglibs may require the submission of an ITCR. The use of Taglibs that provide functionality not suited for the presentation layer of an application, such as Jakarta DBTags, is discouraged.

· One of the most powerful aspects of using JSP is the ability to use the JavaBeans component architecture. JSP pages tend to rely on JavaBeans technology to separate content from style. While JavaBeans and servlets focus on computation, the JSP (or the HTML embedded in it) handles the formatting.

JavaBeans are nothing more than specialized Java classes that can be re-used throughout the application. In the particular case of Resin V2.1.11, all Java classes must be placed either in the \WEB‑INF\classes directory, or in a Java Archive (JAR or .jar) file within the \WEB-INF\lib folder. Otherwise, Resin will be unable to locate those classes when the JSP or Servlet is served. Resin will automatically compile Java source into Java classes when .java files are placed in the classes folder.

It is important to note that although JavaBeans are supported under the current ICE Web infrastructure, Enterprise JavaBeans (EJB) are not. As the need for these types of components are identified and validated, then further evaluation would be required to guarantee their stability in the current Web environment. A special exception is required from the ICE OCIO Technical Architecture Branch prior to any development using EJB technologies.

As explained in Section 4.16.1, the use of ASP and JSP session variables is strongly discouraged. Because of the “stateful” nature of session variables, their use may potentially cause conflicts in the current clustered-server environment. Refer to Appendix D.

4.3 Enterprise JavaBeans

Enterprise JavaBeans (EJB) technology has not received blanket approval from the ICE OCIO Technical Architecture Branch. To take advantage of EJB, application developers must receive prior approval. To date, only portions of the EJB V2.0 architecture have been approved for use in certain circumstances. This primarily includes Container-Managed Persistence (CMP) Entity Beans and Stateless Session Beans. Message-Driven Beans may be acceptable but must be approved on a per-use basis; however, the messaging infrastructure available is limited. Stateful Session Beans and Bean-Managed Persistence (BMP) Entity Beans shall not be used for ICE applications. The use of remote interfaces has been explicitly disallowed. The corresponding EJB V2.0 local interfaces should suffice, because each instance of Resin is used as both the servlet and EJB container.

To acquire permission to use EJB for a particular application, the developers must demonstrate sufficient cause through an ITCR. Although EJB has numerous advantages, the limitations of the current ICE enterprise architecture force their use to be strongly discouraged by the OCIO AI&I team.

An important consideration for application developers receiving this approval is that the ICE uses Resin as the EJB container. Resin’s limited EJB implementation causes difficulties in EJB development. These limitations must be considered at all times during development, because Resin is the only approved production J2EE container for the immediate future.

4.4 File Input/Output

Some Web-based applications will need to read/write to the hard drive on the server to access information stored in text files. The virtual directory, /data, or <app-name>/data, has been defined to facilitate this procedure.

ASP applications should use the Server.Mappath function to access the file by its virtual location.

Example:

Dim sFileName sFileName = Server.Mappath("/data/techtrain/courses/eeo/adrposh/Adr/adrfile.txt")

Set myTextStream = myFileSystem.OpenTextFile(sFileName,…

JSP applications should use the getRealPath method of the ServletContext object to access the file by its virtual location.

Example:

String sFileName;

SFileName = this.getServletContext().getRealPath(request.getRequestURI().substring(this .getServletContext().getServletContextName().length()));

BufferedWriter bw = new BufferedWriter(new FileWriter(sFileName));

Do not use absolute drive names to reference such files. This location may change and application updates may be numerous and time consuming. For J2EE applications, if a relative path is specified, such as ./webapps/appname/somefile.ext, Resin will assume a path relative to the Resin home directory. Since the server environment specifies that applications not be installed within the Resin directory structure, this approach will not work.

The use of a distributed environment means that files written by one client session may not be available to others that access different servers. Prior coordination with the OCIO AI&I team is necessary for applications that require files to be available across all servers in a cluster.