IST-2000-26211 Project IRIS D0401 Recommendations for ... · IST-2000-26211 Project IRIS D0401 Recommendations for Design Aid Approaches and Technologies Contractual Date of Delivery

IST-2000-26211 Project IRISD0401

Recommendations for Design Aid Approaches and Technologies

Contractual Date of Delivery to theCEC:

31/06/01

Actual Date of Delivery to the CEC: (Slipped one month later, according tocontingency plan submitted to EC)

Editor (s): Vladica Stojic, Nikos Floratos (ED)

Contributor (s): Elias Lizardos, Nikitas Tsopelas(ED), JohnDarzentas, Thomas Spyrou, Jenny Darzentas,Panayiotis Koutsabasis (Aegean), CarlosVelasco, Yehya Mohamad (FIT), Myriam Arroe(EHU)

Workpackage: 4

Est. person months: 3

Security: Public

Nature: Report

Version: F

Total number of pages: 92

Abstract:Deliverable D0401 presents and justifies the IRIS approach to the Design Support Environment(DSE) and provides a first view of its conceptual, functional and technical architectural elements.In order to justify this approach, there is a need to review a wide range of work related to ‘Designfor All’ (‘DfA’). This task is still work in progress for the project; however, an overview of this workis given in order to position the IRIS DSE into the landscape of other relevant initiatives. The IRISapproach for identifying and formulating the designer support architecture is described at threelevels: conceptual, functional and technical. The IRIS conceptual architecture presents the basicconcepts of the IRIS design support environment including the basic entities acting in the systemand the purpose of their participation. The IRIS functional architecture presents the basicfunctions of the design support environment in manner independent of technology. The IRIStechnical architecture presents the technological design of the design support environmentaccording to the constraints imposed by the conceptual and functional analysis, as well as fromthe current state of the art on Internet technologies, recommendations and tools.

Keyword list:IRIS, Design support environment, architecture, concepts, functions, technology

IRIS Project IST-2000-26211

Deliverable number : D0401Title of Deliverable: Recommendations for Design Aid Approaches and Technologies

IST-2000-26211 Project IRISRecommendations for

Design Aid Approaches and Technologies

VERSION DETAILSVersion: F

Date: 15/08/01

Circulation: Consortium

Status: Final

DOCUMENT HISTORYVersion Version

dateRespon-sible

Description

A 15/05/01 ED A first extended draft was provided.

B 25/07/01 ED A final draft of the deliverable was provided after extendeddiscussion in face-to-face and audio conference meetings.

C 31/07/01 FIT Some comments added

D 13/08/01 ED Editing

E 15/08/01 FIT Editorial remarks

F 16/08/01 ED Final Editing

DELIVERABLE REVIEWVersion Review date Reviewed by Conclusion*A 14/06/01 ALL Develop

B 31/07/01 FIT Update

D 15/08/01 FIT Update

F 15/08/01 ALL Accept* e.g. Accept, Develop, Modify, Rework, Update

2



Executive SummaryDeliverable D0401 presents and justifies the IRIS approach for the Design SupportEnvironment design (DSE) aid and provides a first view of the conceptual, functionaland technical architectural elements of the IRIS design support environment (IRISDSE). In order to justify this approach for design aid, there is a need to review a widerange of work related to ‘Design for All’ (‘DfA’). This task is still in progress for theproject; however, an overview of this work is given in order to position the IRIS DSEwork into the landscape of other relevant initiatives. The IRIS approach for identifyingand formulating the designer support architecture is described at three levels:conceptual, functional and technical. The IRIS conceptual architecture presents thebasic concepts of the IRIS design support environment including the basic entitiesacting in the system and the purpose of their participation. The IRIS functionalarchitecture presents the basic functions of the design support environment inmanner independent of technology. The IRIS technical architecture presents thetechnological design of the design support environment according to the constraintsimposed by the conceptual and functional analysis, as well as from the current stateof the art on Internet technologies, recommendations and tools. D0401 provides afirst view on these multifarious issues: the work in terms of other workpackages isnot yet finished and their input is not finalized. The final view of these issues will bedocumented in D0402 (Architectural design of design aid environment). However thisfirst view is a very important step in the project, as it will provide the initiating point ofwork on the IRIS approach for design aid, architecture and technology.

3



Table of Contents

IST-2000-26211 PROJECT IRIS.......................................................................................1

D0401......................................................................................................................... 1

RECOMMENDATIONS FOR DESIGN AID APPROACHES AND TECHNOLOGIES......................................................................... 1

CONTRACTUAL DATE OF DELIVERY TO THE CEC:..................................................................... 1

ACTUAL DATE OF DELIVERY TO THE CEC:..............................................................................1

EDITOR (S):......................................................................................................................1

CONTRIBUTOR (S):............................................................................................................. 1

WORKPACKAGE:.................................................................................................................1

EST. PERSON MONTHS:........................................................................................................ 1

SECURITY:........................................................................................................................ 1

NATURE:.......................................................................................................................... 1

VERSION:......................................................................................................................... 1

TOTAL NUMBER OF PAGES:....................................................................................................1

ABSTRACT:....................................................................................................................... 1

KEYWORD LIST:................................................................................................................. 1

IST-2000-26211 PROJECT IRIS.......................................................................................2

RECOMMENDATIONS FOR DESIGN AID APPROACHES AND TECHNOLOGIES......................................................................... 2

VERSION DETAILS.................................................................................................... 2

VERSION:......................................................................................................................... 2

DATE:............................................................................................................................. 2

CIRCULATION:....................................................................................................................2

STATUS:.......................................................................................................................... 2

DOCUMENT HISTORY.............................................................................................. 2

VERSION.......................................................................................................................... 2

VERSION DATE................................................................................................................... 2

RESPONSIBLE.................................................................................................................... 2

DESCRIPTION.....................................................................................................................2

DELIVERABLE REVIEW............................................................................................ 2

VERSION.......................................................................................................................... 2

REVIEW DATE.................................................................................................................... 2

REVIEWED BY.................................................................................................................... 2

4



CONCLUSION*....................................................................................................................2

TABLE OF CONTENTS.......................................................................................................... 4

1INTRODUCTION................................................................................................................. 8

2APPROACHES FOR DESIGN AID: PENETRATION TO 'DESIGN FOR ALL' CONCEPTS.......................... 10

2.1Design for all in ICT - Basic concepts............................................................... 10

2.2Design for all recommendations for Internet-based services............................11

2.3Emerging Specifications Reflecting User Needs...............................................13

2.4Approach for User Requirements in IRIS..........................................................15

2.5Positioning IRIS in the Current Landscape for Design for All Aid .................... 15

2.6Describing the Architectural Design of the IRIS Design Support Environment.16

1THE IRIS DESIGN SUPPORT ENVIRONMENT CONCEPT........................................................... 18

1.1The IRIS Project Concept..................................................................................18

1.2Conceptual Views of the IRIS Design Support Environment............................ 20

1.2.1The Context of the IRIS Design Support Environment...............................20

1.2.2Basic concepts of the IRIS Design Support Environment.......................... 22

2THE IRIS DESIGN SUPPORT ENVIRONMENT FUNCTIONAL ARCHITECTURE................................... 24

2.1IRIS DSE Functional Architecture - Domains....................................................24

2.7IRIS DSE Functional Architecture - Functional Components............................25

2.7.1Interaction domain...................................................................................... 26

2.7.1.1User interface...................................................................................... 26

2.7.1.2Software interface................................................................................27

2.7.1.3Interaction support...............................................................................27

2.7.2DfA Support Domain.................................................................................. 27

2.7.2.1Training................................................................................................27

2.7.2.2Online Design Support........................................................................ 28

2.7.2.3Evaluation............................................................................................ 28

2.7.3DfA Knowledge Domain............................................................................. 29

2.7.3.1Methodologies, Recommendations, Guidelines and Practices........... 29

2.7.3.2User Profiles........................................................................................ 29

2.7.3.3DfA Tools.............................................................................................29

3IRIS DESIGN SUPPORT ENVIRONMENT TECHNICAL ARCHITECTURE............................................31

3.1 Platform architectures under consideration......................................................33

3.1.1Java 2 Enterprise Edition............................................................................33

3.1.2Microsoft Windows DNA ............................................................................34

3.1.3Java 2 Enterprise edition with COM support ............................................. 35

5



3.1.4Criteria for the selection of final IRIS system architecture......................... 38

3.2Examination of Technologies to Support Deployment of IRIS DSE functionalmodules.................................................................................................................. 40

3.2.1Interaction Interface....................................................................................40

3.2.1.1User Interface Technologies............................................................... 40

THE JAVA FOUNDATION CLASS (JFC) SWING........................................................................43

3.2.1.2Ranking of relevant technologies........................................................ 44

3.2.1.3Interaction Support.............................................................................. 45

JAVA ACCESSIBILITY API................................................................................................... 45

JAVA ACCESSIBILITY UTILITIES.............................................................................................46

JAVA ACCESS BRIDGE.......................................................................................................46

3.2.1.4Ranking of relevant technologies........................................................ 46

3.2.1.5Software interface................................................................................47

SIMPLE OBJECT ACCESS PROTOCOL (SOAP).......................................................................49

3.2.1.6Ranking of Technologies.....................................................................50

3.2.2DfA Support................................................................................................ 51


3.2.3 DfA Knowledge (Knowledge Repository).................................................. 54


3.2.4Comparison of JavaServer Pages (JSP) and Microsoft Active ServerPages (ASP) Technologies................................................................................ 58

3.2.5Comparison between CORBA and Microsoft Distributed (DCOM)Technologies...................................................................................................... 60

3.2.6Comparison of Microsoft Transaction Server (MTS) and EJB................... 61

4CONCLUSIONS............................................................................................................... 64

5APPENDIX A: AN IN DEPTH EXAMINATION OF TECHNICAL COMPONENTS CONSIDERED FOR IRIS DSESYSTEM.......................................................................................................................... 67

5.1J2EE Platform Overview....................................................................................67

5.1.1Container-Based Component Management ..............................................67

5.1.2Support for Client Components ................................................................. 67

5.1.3Support for Business Logic Components ..................................................68

5.1.4Support for the J2EE Standard ................................................................. 68

5.1.5J2EE Platform Benefits ............................................................................. 69

5.1.6Simplified Architecture and Development ................................................. 69

5.1.7Scales Easily ............................................................................................. 70

5.1.8Integrating Existing Enterprise Information Systems ................................ 70

5.1.9Choice of Servers, Tools, and Components ............................................. 71

6



5.1.10Simplified, Unified Security Model ........................................................... 71

5.2Web Server....................................................................................................... 72

5.2.1Introduction.................................................................................................72

5.2.2Apache Project........................................................................................... 72

5.2.3Apache HTTP Server................................................................................. 72

5.2.4Features and performances....................................................................... 73

5.3Web Applications and Web Containers............................................................ 74

5.3.1Introduction.................................................................................................74

5.3.2JavaServer Pages (JSP) and Java Servlet Technologies..........................74

5.3.3Tomcat as JSP/Servlet Container.............................................................. 74

5.3.4Conjunction With Apache........................................................................... 75

5.4XML Processing................................................................................................ 76

5.4.1Introduction.................................................................................................76

5.4.2Java API for XML Parsing (JAXP) 1.1 Requirements................................ 76

5.4.3Apache XML Project...................................................................................76

5.4.4Cocoon: XML-based Web Publishing........................................................ 76

5.4.5Cocoon and Apache Tomcat......................................................................77

5.5Enterprise JavaBeans (EJB) Container.............................................................79

5.5.1Introduction.................................................................................................79

5.5.2EJB container............................................................................................. 79

5.5.3JBoss/Server As EJB Container.................................................................79

5.5.4Modular Server Design...............................................................................80

5.5.5Features That Speed Development........................................................... 80

5.5.6Tomcat and JBoss - A Full J2EE Stack..................................................... 81

5.5.7Data Sources..............................................................................................81

5.6Interoperability Assurance................................................................................. 82

5.6.1SOAP..........................................................................................................82

5.6.2Apache SOAP............................................................................................ 83

5.6.2.1Requirements & Limitations................................................................ 84

5.7Web Services Description Language (WSDL) / Web services......................... 84

5.7.1WSDL......................................................................................................... 85

5.7.2UDDI (Universal Description, Discovery, and Integration)......................... 85

6REFERENCES.................................................................................................................87

7



1 IntroductionAs described at the IRIS technical annex, the objectives of workpackage 4 (WP4)are to:

• Define at the conceptual and functional levels, the architecture of the designsupport environment for assisting designers to design-for-all;

• Develop the underlying infrastructure for the design aid environment;

• Integrate basic components of such an environment into a homogeneous, widelyaccessible system;

In order to achieve those objectives the work in WP4 will be informed by the findingsof a number of WPs (Figure 1).

Wp1: Project Management

Wp2: Requirements of people with special needs

for Internet Services

Wp3: User and System Models Specifications

Wp4: Design Support Environment

Wp5: Design & Development Directory Services

Wp6: Design & Develop-ment: Intelligent Agents

Wp7: Recommendations for Enhancements of Internet Services

Wp8: Electronic Commerce service Enhancement and

Demonstration

Wp9: Teleworking / On-line Learning service Enhancement and

Demonstration

Wp10: Evaluation and Assessment

Wp11: Exploitation and Dissemination

: Output : Feedback

Figure 1: Graphical presentation of IRIS work areas.

WP2 (Requirements of people with special needs for Internet services) will provideinformation on the accessibility and usability problems of existing services in theareas of electronic commerce and teleworking for people with special needs, whichcan contribute to the work of WP4 by identifying areas where specific focus can begiven regarding knowledge that will be incorporated into the design supportenvironment. WP3 (User and System Models Specifications) will provide insightconsidering existing recommendations, standards and tools in the areas ofaccessibility, usability, user profiles and modeling. WP4 will incorporate all this workin its knowledge base and present it to designers of Internet-based services in amanner suitable to the problem areas they are faced with. WP5 (Design andDevelopment: Directory Services) and WP6 (Design and Development: IntelligentAgents) will provide the design of components of the design support environmentwhile WP7 (Recommendations for Enhancements of Internet-based Services) willcontinuously provide external feedback of the work carried out in terms of WP4.

8



Deliverable D0401 (Design Support Approaches and Technologies) provides a firstview on architectural issues of the IRIS design support environment (IRIS DSE). Itformulates the problem space where IRIS attempts to provide solutions and to whichit is applicable and also elaborates on the entities involved and their correspondingviews and business opportunities (conceptual level); it demonstrates the manner bywhich support to designers will be pursued in terms of functional - independent oftechnology – design; and also sketches the technical design, that elaborates onspecific technologies and recommendations that will be used. D0401 is a first viewon these multifarious issues: the work in terms of other workpackages is not yetfinished and their input is not finalized. The final view of these issues will bedocumented in D0402 (Architectural design of design aid environment). However thisfirst view is a very important step in the project, as it will provide the baseline of workon the IRIS approach for design aid, architecture and technology.

Thus, the objectives of this deliverable (D0401) are to:

• Present and justify the IRIS approach for design aid;

• Provide a first view of the conceptual, functional and technical levels of the IRISdesign aid architecture;

In order to justify the IRIS approach for design aid, there is a need to review a widerange of work related to ‘Design for All’ (‘DfA’). This task is still work in progress forthe project and is being carried out mainly by workpackages 3 (User and systemmodels specifications), 5 (Directory Services) and 6 (Software Agents).

The IRIS approach for identifying and formulating the designer support architectureis described at three levels: conceptual, functional and technical. The IRISconceptual architecture presents the basic concepts of the IRIS design supportenvironment including the basic entities acting in the system and the purpose of theirparticipation. The IRIS functional architecture presents the basic functions of thedesign support environment. These functions explain how the system achieves thegoals revealed from the conceptual level. The functional architecture is presented ina manner, which is independent of technology. Finally,the IRIS technical architecturepresents the technological design of the design support environment. The technicalarchitecture attempts to provide an implementable solution to the constraintsimposed by the conceptual and functional analysis, as well as from the current stateof the art on Internet technologies, recommendations and tools.

9



2 Approaches for Design Aid: Penetration to 'Designfor All' Concepts

This section briefly presents the need for IRIS DSE and positions the IRIS DSE inthe landscape of current design aid tools, in reference to end-user and designerneeds. In order to demonstrate the need for the IRIS DSE it is important to presentthe breadth of related work and illustrate the aspects and the manner by which thiswork is to be implemented and extended. Furthermore it is important to position IRISdevelopment in the context of other relevant initiatives originating from other fora.

2.1 Design for all in ICT - Basic conceptsThe term ‘Design for All’ has been widely used in a number of contexts. AsStephanidis et al (1999) summarise ‘for some individuals, it is considered as a newpolitically correct term, referring to efforts intended to introduce “special features” for“special users” during the design of a product. To others, universal design is adeeply meaningful and rich topic that elevates what designers like to call “good user-based design” to a more encompassing concept of addressing the needs of allpotential users’. Notwithstanding, the fact that there might be dangers inherent inexamining concepts, methods, tools, techniques etc. under such a generic spectrum,the inclusive, user-centred approach towards product and systems design isespecially appropriate to the context of the IRIS project.

A key element in approaches for design for all is active user participation andengagement in every phase of product and systems design (Velasco and Verelst,1999, 2001a, 2001b). However, the achievement of such an engagement andproductive participation is a difficult task to plan, organize and conduct, especiallytaking into account that products, systems and services, when referring to theInternet, are very wide in scope, covering a very large number of user preferences,abilities and constraints.

Taking into consideration a wide range of user requirements leads to newcircumstances and interesting challenges for the designer. A major challenge to befaced arises from the fact that the incorporation of requirements by diverse usergroups most often results in conflicting or simultaneously interoperable technicalsolutions. For example the use of small fonts is not appropriate for users with sightimpairments, thus, in order to design for all, it is important that the system canprovide alternative options and modalities, which are often related to human sensorycues and modalities.

Furthermore, even if a system supports multiple states and can cover a wide rangeof requirements, a given system state may not be at all accessible by users whoserequirements seriously conflict with the given system state, with the consequencethat these users cannot change the given system state at all. For example, a default‘small fonts’ setting cannot be altered by users with vision impairments, even if thesystem is configurable regarding its font size, because it is not accessible by them tobegin with, at the given default state. Therefore, besides supporting multimodality, ithas been realised that an approach towards achieving design for all is that of

10



designing for system adaptivity, i.e. the system inherent property to trace andautomatically adapt/respond to user requirements.

The IRIS project takes an approach towards user-participatory and adaptive designof systems and services, which includes diverse user groups from a large number ofEuropean countries. Furthermore within the perspective of active user participationand adaptive design, emphasis is given in areas relevant to this approach such asuser modelling, accessibility and usability.

User modelling investigates issues related to the identification of methodologies,methods and techniques, that aim at including in a system-adaptive manner, usercharacteristics, preferences, abilities and constraints into product and system design.This interdisciplinary area of research has produced results both at the level ofconceptual representations and processes and at the level of knowledge and datarepresentations.

Accessibility has traditionally been associated with disabled and elderly people. Thisarea has often focused too narrowly on the requirements of disabled and elderlypeople, producing solutions that are much customised to the needs of those groupsof people and thus with constrained impact. These types of solutions are often calledassistive technologies. However, the range of different categories of users that may,at a given time or gradually, be confronted with accessibility problems is far greaterthan the population of disabled and elderly users. For example a driver who wants toaccess the Web while driving a car has also sensory and cognitive limitations, thathave to be considered when designing the usability, i.e. accessibility, ergonomics,etc. of devices that can provide such access.

Furthermore, often disabled and elderly people are not too interested in products thatare very specific to their needs. This is because these products may be expensive,or unpleasant to use, in the sense that frequently they have been designed withemphasis on functionality rather than aesthetics, making them psychologicallyunattractive. Most of all, in the area of ICT, assistive technology solutions have oftenfallen behind, becoming obsolete, when mainstream technology moves on. Instead,disabled and elderly people are interested to ensure that mainstream products arewidely accessible, incorporating their requirements, as much as possible. That is tosay, it is understood that some disabilities may need special equipment to accesstechnology, but once this is achieved, there should not be further accessibilityproblems (Koutsabasis et al, 2001; Velasco, 2001a, 2001b).

Thus, in the context of the IRIS project accessibility is viewed in its widestperspective. That is, recommendations and tools that are examined are not onlyspecific to accessibility by people with disabilities. Specifically in the area of Internet-based electronic services, recommendations related to usability are also discussed.In order to capture as much as possible in this review, all relevant work, thisdeliverable is not limited to technical and development issues but reviews workrelated to the lifecycle of Internet-based systems design including phases such asuser requirements and evaluation.

2.2 Design for all recommendations for Internet-basedservices

The ‘Design for all’ concept attempts to cover a wide range of requirements for user-based design, access and use of computer-based applications. This general

11



perspective requires that a wide range of methodologies, methods,recommendations, techniques and tools that can provide aid at various phases of thedesign process should be taken into account in an approach towards aidingdesigners to design for all.

For IRIS, the identification, and critical review of these methodologies, methods,recommendations, techniques and tools is an essential step towards the selectionand interpretation of significant strands of work that can be incorporated into the IRISdesign support environment. This view is presented in many phases of the project.

An enumeration that represents the empirical, broad and disparate nature of work inthe area of Internet-based services, that is relevant to ‘Design for all’ concepts,includes work and tools relevant to: accessibility, usability, user profiling,semantics/metadata of content and media, cognitive/reactive models of perception,action and models of interaction. These strands of work, although some of them arenot constrained only to these types of systems, can provide useful references todesigners of Internet-based services at various phases of the design process, suchas requirements, design, development, evaluation – not necessarily in this order, asshown in (Koutsabasis et al, 2001). Unfortunately designers rarely take into accountthe breadth of issues regarding the incorporation of work related to ‘Design for All’concepts. Most often, designers focus on work that contributes directly to thedevelopment and prototyping phases of the design process (Velasco and Verelst,1999, 2001a, 2001b).

Phases of the Design Process

Requirements Design Development / prototyping

Evaluation … … … … …

Recommendations (e.g. Guidelines, Standards)

for accessibility

Work relevant to ‘Design for All’ concepts


for usability


for user profiles

Recommendations (e.g. Guidelines, Standards) for metadata/semantics

Models of perception, and action

Interaction models

Contribution of work relevant to ‘Design

for All’ to the design process

Decreased, implicit user involvement

Increased, explicit user involvement

Level of abstraction

Designer Tools at the Technical

level

Designer Tools at the Methodology

level

Figure 2 Contributions of work relevant to 'Design for All' to major phases of the design process

12



For example, despite the fact that most of the work on W3C.WAI1 recommendationsfor accessibility can be taken up at the development and evaluation phases of adesign process or methodology, naturally there are aspects of these guidelines thatcannot be automatically implemented by a software compliance test program, butare left to the designer to decide how they are met. These aspects are usuallyignored. Similar examples can easily be found for all types of methods,recommendations, techniques and tools.

There is much room left to designers for interpretation in some aspects of this work;this is natural, but there is a need for support to aid the designer in summarising anddeciding upon which recommendations and tools to select and apply. For example,Stephanidis and Akoumianakis (1999) demonstrate that different engineeringperspectives in the implementation of guidelines can lead to different interpretationsand can influence the quality of the final products.

The effect of this existing, relevant to ‘Design for all’ concepts, work cannot bestrictly bound to specific phases of a particular methodology or design process (thus,in figure 2, we use small dots to reflect this vagueness). Generally, whenever thesetools cannot provide formal solutions to assist designer in an automatic manner, userinvolvement is usually more explicit and increased.

The elaboration of work relevant to the ‘Design for all’ concepts, methodologies,methods, recommendations, techniques and tools is a major objective of the IRISproject. This task is the starting point for the development of a framework for aidingdesigners to incorporate this work into their methodologies and design processes.This work, which will be conducted in terms of specific activities and deliverables, willgradually form a rich picture of the current situation on Design for all for Internet-based services. The scope of this work is as critical as possible aiming at producingproposals for recommendations and enhancements, both in terms of specificcommercial IRIS Internet services and demonstrators in the areas of electroniccommerce and teleworking/ education, as well as part of other initiatives. This willrequire selections and interpretations, for example in terms of technology,recommendations, existing tools, etc. These interpretations may beprovided/updated by the industry directly into the IRIS designer aid environment, byaccessing its knowledge base.

2.3 Emerging Specifications Reflecting User NeedsUser needs are reflected in a number of specifications / recommendations that haverecently appeared, despite the fact that in some cases the methodology for userinvolvement is not clearly provided. In some areas related to ‘Design for All’,problems have been dealt with specifications that are easily interpretable to technicalsolutions, while in other areas further interpretations are required by Internetdesigners. In any case, it is true that most of these specifications are quite new andhave not been implemented and tested extensively.

IRIS will make use of emerging recommendations / specifications wheneverpossible, while in other cases the project will follow well-established research anddevelopment practices. The criteria for the selection of recommendations /specifications are techno-economic and range from suitability of these selections to‘Design for All’ concepts to partners’ experiences and participation and support in

1 http://www.w3.org/WAI/

13



fora that currently work on these selections (see also section 3 IRIS Design SupportEnvironment Technical Architecture). The purpose of listing these selections ismostly informational and should not be treated as definitive of plans for IRISdevelopments. On the contrary, experience shows that in a 30-month project it ishighly probable that some of the selections listed below may become obsolete.

Accessibility. IRIS will apply the W3C WAI guidelines for accessibility of WebContent and Authoring Tools (Chisholm et al 1999; Treviranus et al, 2000) intoproject developments and thereby contribute to further adaptation / extension of thiswork. The WAI Web Content Accessibility Guidelines will be applied in alldevelopments of Internet content: IRIS Website, enhancements of Internet servicesand development of the IRIS DSE. The WAI Authoring Tools Accessibility Guidelineswill be applied during the development of the IRIS DSE and the enhancement of theselected e-commerce service, which includes automated, online design of electronicshops.

Usability. IRIS will apply well-known methodological approaches for usability testingand evaluation in terms of user requirements capture and evaluation of selectedInternet services. Furthermore, IRIS will consider the application of related standardsto this work (for a review see D0301int, Review of guidelines and standards foraccessibility to Internet-based services), however, it seems that the application ofusability standards requires extended allocation of resources and requires furtherelaborations for the case of Internet usability (D0301int).

User profiling / modeling: IRIS will implement specifications for personalinformation profiles that stem out of the LDAP Person specification (for a review seeD0302int (User models for accessibility and enrolment of people with special needs),thereby contributing to further adaptation and extension towards accessibility issues.IRIS will also consider the application of W3C CC/PP for device profile informationand is closely watching this area by partners’ participation to W3C and othercollaborative European R&D projects that work on the implementation of CC/PP (e.g.IST Project GUARDIANS). This work will be performed in terms of the IRIS DSEdevelopment. The study of the current user profile infrastructure of selected Internetservices is also work in progress and it is possible that this infrastructure may beextended to implement the above specifications.

Metadata: IRIS will make use of XML, which is a standard that is general in scopefor metadata design. Furthermore, IRIS will consider the use of other XML-relatedspecifications such as XSL and XSLT. In addition well-known metadata schematasuch as RDF and Dublin Core will be considered for the metadata design of specificcomponents of the IRIS DSE, such as the knowledge repository. The suitability ofthese recommendations to aspects of ‘Design for All’ (such as promotingaccessibility) is currently investigated by the IRIS partners (e.g. Velasco, 2001c).

Models of perception and action: In this area of work there is not widely used workin terms of concrete specifications / recommendations / standards. However, IRISwill base its developments on emerging findings from the area of software agents.This work has been introduced in D0302int (User models for accessibility andenrolment of people with special needs) and will be analytically presented inD0601int (Review of directory services design approaches and technologies).

14



2.4 Approach for User Requirements in IRISAs noted above, IRIS will implement, adapt and extend a number of emergingspecifications and recommendations related to Internet accessibility, usability, userprofiles and metadata design. Besides the purposeful synthesis of existing work interms of project activities (mainly under workpackages 3, 5 and 6) another importantproject activity that influences those adaptations / extensions is that of userrequirements analysis. Currently IRIS WP2 is working on the development of userrequirements that is targeted towards specifying the requirements for accessibilityand enrolment of users with special needs in selected Internet services and therebyidentifying areas of focus for the design and development phases including theevaluation criteria against which the design aid environment and the enhancedInternet services will be judged.

The IRIS work on user requirements analysis is guided by the USERFITmethodological framework which can organise and record information about userrequirements in an operational way and has been developed in terms of TIDE 1062USER project. The application of the framework will be enhanced by usability andaccessibility evaluations of existing IRIS services in the areas of teleworking andelectronic commerce. This will enable IRIS to have a first set of specific test items interms of the Internet services to be enhanced. The usability evaluation is based onrelated methods that have been also used for the usability evaluation of GMD’sBSCW teleworking platform. The accessibility evaluation will be based on W3C’sWAI accessibility guidelines for both authoring tools and Web content.

2.5 Positioning IRIS in the Current Landscape for Design forAll Aid

Before formulating and discussing the architecture of the IRIS design supportenvironment, it is important to provide a note on current trends and practices towards‘Design for all’. An empirical enumeration of the main players/entities involved inapproaches for designer support may consist of: large IT vendors, IT SMEs, theopen software community, specific organizations in the areas of accessibility,independent consortia and academia. Each player approaches designer support in adifferent manner, but of course in some cases these approaches have somecommon elements. The approaches taken by each of the above players are differentto their objectives and the degree by which ‘Design for all’ concepts are of interest.

IRIS identifies the need for an approach that is complementary with the aboveapproaches and attempts to synthesize their findings. The purposeful synthesis ofthe wide range of results in the area of ‘Design for all’ is a task at least of the sameimportance to the design of another technical solution that would address an aspectof a specific problem. IRIS contributes to both, by synthesizing and elaborating oncurrent work on design for all and by adapting/extending this work to selectedInternet services in emerging application areas.

However, it has to be noted that at the business level IRIS will not directly competewith large IT vendors of Web development software (e.g. such as Microsoft, orMacromedia) and tools because IRIS is not building a classical Web developmentenvironment or tool, although there is some degree of overlapping. The IRIS designsupport environment focuses on functionalities that are not typical of classicdevelopment tools and therefore can act synergistically with existing Web

15



development environments and tools in order to provide ‘design for all’ assistance toInternet designers.

2.6 Describing the Architectural Design of the IRIS DesignSupport Environment

The approach for describing the architectural design of the IRIS DSE is borrowedfrom classical information systems analysis and design approaches. The basiccharacteristic of those approaches is that they include models, which may operate atdifferent levels of abstraction. The selection of levels by which a system is defineddepends on the purpose of the investigation and design, however, there is a wideconsensus that there are some ‘natural’ or ‘inherent’ levels upon which a system canbe defined (Avison and Fitzerald, 1994). These are the ‘conceptual’, the ‘logical’ (or‘functional’) and the ‘physical’ (or, for cases of computer-based information systems,the ‘technical’) level (Figure 3).

Real Word Universe of discourse

Conceptual Model

Logical Model

Physical Model

Levels of Abstraction

Figure 3 Natural’ or ‘inherent’ levels upon which a system can be defined.

The conceptual level presents the basic concepts of an information system includingthe basic entities acting in the system and the purpose of their participation (e.g.business goals) as well as the purpose of the system as a whole. The conceptualarchitecture explains what the system composes of at a high level of abstraction.The conceptual architecture may be presented in different levels from general tospecific.

16



The functional level presents the basic functions of the system. These functionsexplain how the system achieves the goals revealed from the conceptual level. Thefunctional architecture is independent of technology. In a similar way with theconceptual level, the functional level may be presented in different levels fromgeneral to specific.

The technical level presents the technological design of the system. The technicallevel attempts to provide an implementable solution to the constraints imposed bythe conceptual and functional analysis, as well as from the current state of the art ontechnologies, recommendations and tools.

Regarding the form of presentation of models, these have been categorized into fourdistinct types (Shubic 1979): (1) verbal; (2) analytic / mathematical; (3) iconic /pictorial / schematic and (4) simulation. Avison and Fitzerald (1994) note that ‘themodels of concern in information systems methodologies are almost exclusively ofthe third type’, (i.e. iconic / pictorial / schematic) because of the importance of usingmodels as a means of communication.

IRIS will follow the afore-outlined model for the definition and description of the IRISdesign support environment. The architectural design of the IRIS design supportenvironment will be discussed at these three levels of abstraction: conceptualfunctional and technical. The strength of this approach is that it can enable us tostudy a broad range of issues/questions such as: what is the IRIS Design SupportEnvironment (i.e. conceptual level); who uses it (i.e. conceptual level); in whatcontexts may it be used (i.e. conceptual level); what are its basic parts (i.e. functionallevel); what are the basic technologies employed (i.e. technical level); how does itwork (i.e. functional and technical level). These issues are discussed in theremainder of this deliverable.

17



1 The IRIS Design Support Environment ConceptThis section presents the basic concepts around the IRIS design supportenvironment. The discussion on the conceptual issues of the IRIS DSE addressesconcerns related to the essence of the IRIS DSE such as: what is the IRIS DesignSupport Environment for? what does it do? whom does it serve? The discussion isstructured as follows: firstly the IRIS project concept is overviewed, and secondlyconceptual issues within the IRIS DSE are discussed.

1.1 The IRIS Project ConceptThe objectives of the IRIS project are to:

• Encapsulate into a design aid environment, work on design-for-all tools andmethods; user modelling theories and methods, including users with specialneeds; guidelines, recommendations and results from work about hypermedia,enrolment and accessibility; and

• Use this environment to redesign and enhance existing services in the areas ofteleworking / on-line learning and electronic commerce, guided by rigorous usertesting and evaluation.

IRIS aims to genuinely advance the current scientific and technological state of theart in the area of accessibility by ensuring that current design-for-all tools andmethods, user modeling theories and methods, design guidelines, recommendationsand results from work about hypermedia, enrolment and accessibility areencapsulated into a homogeneous design aid environment. The project will formulateexisting knowledge and experience in the area under a generic integrated design aidenvironment that supports the designers of Internet services; combine state of theart technologies (like directory services, metadata and intelligent agents) forimplementing this environment considering and contributing to relevant standards;validate the concept of the design aid environment by using this to enhance existingInternet applications and services tested by different groups of users with specialneeds.

The basic elements of the IRIS project approach and tasks are showndiagrammatically in Figure 4 and are discussed in the remainder of this section.

18



Figure 4 The IRIS project concept.

Designing for all implies a user centred approach in design and starts from theidentification, modelling, specification and automated utilisation of usercharacteristics. User characteristics may include a variety of information such as:preferences, attitudes, sensory capabilities or impairments, user access features(related to both software and hardware). IRIS will take into account design for allmethods, recommendations, results of relevant previous projects and insightprovided by large groups of people with special needs to develop models of users,which will incorporate the requirements related to human impairments. Furthermore,there is a need to elaborate models of user requirements, involving large andinternational groups of users with special needs, relevant to media and translatethese models into technical characteristics of communication channels so thatservices may be configured to these characteristics.

19



The IRIS design support environment also takes into account existing work in areasrelated to design for all such as usability, accessibility, content metadata and usermodelling and profiles. IRIS will identify the suitability of a range of tools andmethods, such as metadata for delivering media and alternating content formats. Byidentifying the suitability of such methods and tools, IRIS will have formed a broaddesign space, where the aforementioned user models can be translated to a rangeof possible selections regarding the design of accessible services. The specificationof user models takes into account relevant recommendations and emergingstandards and specifications in the areas of user enrolment and accessibility inaccordance to the application domains.

The IRIS design support environment will be used by designers in order to enhanceexisting Internet services and applications in the selected areas of electroniccommerce and telework / on-line learning. This will be achieved by furtherdeveloping existing Internet services in these areas according to the specificationsthat will be consolidated mainly by workpackage 4.

During the enhancement of existing services, IT designers will assess the support ofthe design aid environment and the extensibility and customisability of design for alltools. Designers will use those tools to assess the re-engineering effort for adding‘design for all’ principles to their software products, and to employ them directly totheir developments.

The evaluation of enhanced Internet services will be user-centered, involvinginternational associations of people with special needs, who are familiar with ICT andwho will provide insight to various usability and accessibility issues.

1.2 Conceptual Views of the IRIS Design SupportEnvironment

This section refers to conceptual views of the IRIS design support environment interms of two perspectives. The first is related to the view of the IRIS design supportenvironment in terms of other basic entities, which form its environment (i.e.context). It is important to clarify from this level of analysis the role of the IRIS designsupport environment relative to other entities either human or artificial. The secondview is related to the basic concepts within the IRIS design support environment,which is the starting point for the functional analysis, which will be presented insection 5.

1.2.1 The Context of the IRIS Design Support EnvironmentThe IRIS design support environment aims at supporting all designers to design webapplications / services for all users based on user modelling. A first abstract view ofthe IRIS design support environment situated within its environment is shown inFigure SEQ Figure \* ARABIC 5.

20



DESIGNER

Design a Web product for

All IRIS “DESIGN for ALL” (DfA)

SUPPORT ENVIRONMENT

WEB DEVELOPMENT TOOL (S)

WEB PRODUCT

ALL USERS

Access and Use

Figure SEQ Figure \* ARABIC 5 A first abstract view of the IRIS design support environment.

The IRIS design support environment is a new element in a typical design process,where a designer aims to understand a design problem and produce a Web productwith the use of a (set of) Web development tool(s). The need for the design supportenvironment is created from the observation that the designer is engaged to solve adesign problem that requires a ‘Design for All’ approach, which cannot be offered byexisting Web development tools.

The design problem may be formed in a manner that is independent of the IRISdesign support environment or the Web development tool(s) and that the designer isfamiliar with and normally uses for design and development (e.g. in terms of ageneric methodology). The design problem may be communicated with the IRISdesign support environment (via suitable mechanisms and rules) and/or the Webdevelopment tools according to the communication language(s) used.

The ultimate aim of the designer is to produce a Web product, e.g. an Internetservice. For the purposes of the IRIS project there will be developments anddemonstrators in Internet services in the selected areas of teleworking and electroniccommerce. However, the scope of the IRIS design support environment is to provideassistance to designers at a generic level and support the design process beyondthese domains of application.

The IRIS design support environment may also communicate with Web developmenttool(s) and with the Web product that is in design and development phase. This mayhappen with various technical solutions, however, it is important that these solutionsare generic and extensible so that they can be taken up and used by vendors ofthese development tools. The link between the IRIS design support environment withWeb development tool(s) can enable the IRIS design support environment to monitorthe design process proactively and possibly act in this manner in order to provideassistance to the designer.

As can be seen from this conceptual level of analysis, the IRIS design supportenvironment could act synergistically with existing Web development tools with thepurpose of supporting the designer in a generic manner and scope, covering the full

21



lifecycle of the design process from problem understanding until development andtesting, to apply ‘Design for All’ concepts to the analysis, design and development ofInternet services. Thus, the IRIS design aid environment is not just another Webdevelopment tool, but instead allows self-produced interfaces and/or elementsrelevant to ‘Design for All’ to existing development tools. From the perspective of thedesigner the IRIS design aid environment can be used either via their preferred Webdevelopment tool or via its own interaction module in order to support the designer inphases of the design process. However, the technical issues for the latter type ofuse are further refined in terms of the technical architecture.

1.2.2 Basic concepts of the IRIS Design Support EnvironmentFurther to this first conceptual view, it is important to see the basic concepts withinthe IRIS design support environment. The IRIS Design Support Environment can bedefined as an structured set of methods, tools, guidelines, software applications,provided via the Internet to all designers in order to support the design of webapplications / services for all users based on user modelling. This definition (whichwas agreed by project partners at our first project meeting) identifies a number ofissues ranging from conceptual to technical. At a first level of analysis, the followingbasic concepts of the IRIS Design Support Environment can be identified:Interaction, Design Support and ‘Design for All’ Knowledge (Figure 5).

interaction

addresses users (designers) and

external applications

adapts to user requirements / preferences

translates user models to communication

channels

support of the design process

addresses a wide range of issues within the product lifecycle

translates ‘Design for All’ knowledge to applicable

methods and tools

evaluates (the outcomes of) the design process

Synthesizes a wide range of ‘Design for

All’ knowledge

extends existing design for all tools

‘Design for All ’ knowledge

introduces new tools for ‘Design

for All’ aid

elicits specific problem situation

requirements

Figure 5 Basic concepts within the IRIS DSE.

The IRIS DSE may interact with users (designers of Internet services) and externalapplications (e.g. Web development tools, or Web products). The IRIS DSE willemphasise interactions that aim at translating user models (which may include usercharacteristics, preferences, requirements, etc. including impairments) to appropriatecommunication channels (service content and communicative media). Thusinteraction will take into account usability and accessibility issues. Furthermore,wherever possible the IRIS DSE will automatically adapt to user requirements,

22



preferences and characteristics. This type of proactive adaptation is required incritical phases of user – system interaction such as user enrolment.

The IRIS DSE will support a wide set of issues within the Internet service designprocess. These issues may involve user (designer) instruction, online collaborationand evaluation of the design process, at least in selected phases of the designprocess that may pose difficulties to designers. The IRIS DSE should support thedesign process by translating the wide range of ‘Design for All’ knowledge into easilyapplicable methods and tools.

The IRIS DSE will possess and synthesise a wide set of knowledge related to‘Design for All’. This knowledge will be both ‘borrowed’ from existing work and ‘selfdeveloped’. IRIS developments will include both the creation of new tools andextensions/adaptations of existing tools.

It needs to be noted that this approach is a first attempt towards defining the basicconcepts of the IRIS DSE. Work related to the review of current work in ‘Design forAll’ mainly conducted by workpackages 3 (User and system models specifications), 5(Directory Services) and 6 (Software Agents) will enhance this view. This will bedocumented in terms of D0402 (Architectural design of design aid environment).

23



2 The IRIS Design Support Environment FunctionalArchitecture

This section will present the basic functions of the IRIS design support environmentfunctional architecture. The discussion is made in a manner independent oftechnology to ease comprehension and allow for easy uptake of this work by otherfora with similar aims. The presentation of the functional architecture adopts theterminological conventions: domains and components.

A domain refers to a set of functional components that have a similar purpose. Thepurpose of components refers to the functional level of analysis, which may be quitedifferent at the level of the technical description. For example under the interactiondomain the functional components of ‘user interface’ and ‘software interface’ will beimplemented quite differently.

A functional component refers to a concrete (set of) component(s) and performs aspecific function. Functional components may be further broken down, however, inthis deliverable we mainly refer to ‘top-level’ components.

2.1 IRIS DSE Functional Architecture - DomainsThe IRIS DSE domains are directly taken from the conceptual analysis, thereforethey consist of: interaction, ‘Design for All’ support and ‘Design for All’, knowledge.Figure 6 presented an abstract view of the IRIS DSE functional architecture, whichincludes the three domains.

24



IRIS Design Support Environment

WEB PRODUCT

Web Designer

WEB DEVELOPMENT

TOOL

INTERACTION DOMAIN

DfA SUPPORT DOMAIN

DfA KNOWLEDGE DOMAIN

Functional

components

Functional

components

Functional

components

Design process

DfA: Design for All

… … …

Figure 6 Iris DSE Functional Architecture - Domains.

The designer is still involved in the design process and may have direct access to aWeb development tool and / or a Web product, while using the IRIS DSE in order tobe assisted towards designing for all. The IRIS DSE:

o interacts with the designer and/or external applications via the interactiondomain;

o provides support to the design process (which involves the designer and otherapplications) via the design support domain; and

o manages and uses ‘Design for All’ knowledge to pursue the above tasks via thecorresponding domain.

Each domain may include a number of functional components, which focus tospecific functions. A first set of these functions is presented in the next section.

2.7 IRIS DSE Functional Architecture - FunctionalComponents

A diagrammatic illustration of the IRIS DSE functional architecture is shown in Figure8 and discussed in the remainder of this section. At this first level of analysis only the‘top level’ functional components are presented and discussed. At this level ofdiscussion the identification of detailed functionality flow cannot be made; in otherwords, it is envisaged that the components identified at this level of analysis willprovide interfaces that will be available to all other components. A more detailed

25



discussion of the functional architecture will be part of deliverable D0402(Architectural Design of Design Aid Environment). In the following description sometechnical issues are also touched mostly in terms of examples. A first view oftechnical solutions with respect to the functional architecture is provided in section 5.

IRIS DfA Support Environment

WEB PRODUCT

MODIFICATION OF AN EXISTING APPLICATION

Web Designer

INITIATION OF A NEW WEB APPLICATION

WEB DEVELOPMENT

TOOL

INTERACTION/ INTERFACE

TRAINING

ONLINE DEVELOPMENT

SUPPORT

EVALUATION

DfA SUPPORT DESIGN FOR ALL KNOWLEDGE

METHODOLOGIES/ RECOMMENDATIONS/

GUIDELINES/ PRACTICES

DESIGN FOR ALL TOOLS

USER PROFILES/MODELS

USER INTERF

ACE

IN

TERA

CTIO

N SU

PPOR

T

S/W INTERFACE

Design process

DfA: Design for All

Figure 7 IRIS DSE Functional Architecture - top level components.

2.7.1 Interaction domainAt this level of analysis, under the interaction domain three functional componentshave been identified: the IRIS DfA support environment user interface, the interfaceto other (external or internal to the IRIS DSE) software and interaction support.

2.7.1.1 User interfaceThe user interface of the IRIS DSE will allow users (designers) to have direct accessand use of the IRIS DSE services. The IRIS DSE user interface will be Internet-based and compliant with WAI Web Content and Authoring Tool AccessibilityGuidelines.

The user interface will provide users (designers) with understandable and navigablecontent, which includes not only making the language clear and simple, but alsoproviding understandable mechanisms for navigating within and between differentpages. Some general principles for user interface design that will be applied duringthe IRIS DSE design include:

26



o Multimodality: the user interface content should convey essentially the samefunction or purpose as alternative auditory or visual content;

o Context and orientation information: to help users understand complex pages orelements because without orientation information users may not be able tounderstand very large tables, lists, menus, etc.

o Clear and consistent navigation mechanisms: such as orientation information,navigation bars, a site map, etc. in order to ensure location of existinginformation;

o User feedback: every operation initiated by user will have some kind ofaudio/visual presentation of its progression;

The user interface will follow principles of accessible design such as: device-independent access to functionality, keyboard operability, self-voicing, etc.

2.7.1.2 Software interfaceThe software interface will provide access to IRIS DSE services to other externalapplications (such as Web development tools or Web products) as well as to othercomponents of the IRIS DSE.

It is envisaged that the software interface will be mainly designed in the form of APIs(Application Program Interfaces), which will provide remote and cross-platformaccess to IRIS DSE services. In this way other applications can make use of IRISDSE services directly on top of their own user interfaces.

2.7.1.3 Interaction supportThe interaction support component will employ mechanisms for adaptation to user(designer) requirements and interactive dialogue. The main vehicles that will guidethis type of user interface will be based on user modeling approaches and userinterface agents. The IRIS DSE interaction support component will make use ofspecifications that are related to user profiling and modelling and recent advances ofsoftware agent design (for a review see D0302).

2.7.2 DfA Support DomainAt this level of analysis the DfA support domain consists of components that can aidthe designer (user) in the following ways: Instruction/training, online design supportand evaluation of design artifacts and the design process.

2.7.2.1 TrainingThe training component will address the need for designers to be familiar with theconcept of ‘Design for All’ and furthermore, with knowledge that is related to thisconcept. Designers have a vague picture of ‘Design for All’ concepts and tools andusually are not well guided with regard to the deployment of ‘Design for All’ toolsfailing to identify their suitability [Koutsabasis et al, 2001 and Velasco and Verelst,1999]. The IRIS DSE aims to establish a reference point for ‘Design for All’ work, notonly in terms of accumulation of resources but furthermore by establishing services

27



that can assist designers, if possible in specific problem situations in a context-awaremanner.

The training component will enable the user/designer to post requests to the IRISDSE and receive responses such as related topics, articles, drafts, andrecommendations based on the IRIS DSE Knowledge Repository. The trainingcomponent will enable the designer to take design decisions and follow necessaryactions related to a specific problem in order to enhance its ‘Design for All’ features,e.g. such as accessibility usability, adaptivity.

2.7.2.2 Online Design SupportThe IRIS DSE will provide functions that will allow for generating new Webapplications. It will thus act as a Web authoring tool capable of visually placing andarranging the available objects/modules or Web components based on accessibilitytechniques. Web components will provide preview, guidelines, verification andvalidation at the same time. Each designer will have access to online design supportcomponent and any extension of it such as uploading/downloading pages, alteringcontent etc. and responsibility for the hosting, maintenance and security/integrity ofdata. The online design support will be predictive i.e. designers will be self-guided bythis module during the page creation process. It will have intuitive, suggestive anddescriptive (user-friendly) interface toward designers thus providing them withextensive easy-to-use development environment.

The online development support component will also incorporate reusablecomponents that may be used in Internet application design and development.These components will encapsulate business logic of Web applications and will bedeployed and executed in context of application server (component container). Thedesign of these components will support accessibility in ways such as: the ability tomanipulate the graphical components entirely from the keyboard; the ability to trackevents (for example, when a window is opened or when a keyboard or mouse buttonis pressed); the ability to query components in order to determine their state (forexample, whether a box is checked or unchecked, and to enumerate the actions thatmay be invoked upon them); the ability to synthesize events that cause a change inthe state of the application; the ability to inspect text components directly, to accessboth content and text attributes (font, size, colour, style, etc.); the ability to implementa comprehensive set of keyboard navigation and editing sequences etc.

2.7.2.3 EvaluationThe main objective of the evaluation component is to determine to which degreeaspects of the design process and outcomes (e.g. Web pages) are following ‘Designfor All’ principles (e.g. accessibility, usability, adaptivity, multimodality, etc.). The IRISDSE may provide ‘self-developed’ tools or guide the designer to use external toolsfor this purpose. The evaluation component will provide guidance to the designerregarding those aspects and if possible, repair problems that will be identified.

The guidance to designers will be achieved by developing mechanisms that allow forfunctions such as reminding, helping and suggesting. The automatic repair ofidentified problems may be achieved with tools that can provide validation of content(i.e. compliance to the relevant standard / recommendation, such as HTML or

28



XHTML) and compliance with accessibility guidelines (i.e. WAI Web ContentAccessibility guidelines).

2.7.3 DfA Knowledge DomainThe IRIS DfA support environment will require a large amount of DfA knowledge,which can be either encoded inside the environment or externally available. Thisknowledge includes existing methodologies, user requirements and modelling, andtheir translation to technical characteristics, recommendations guidelines, standards,case studies and possibly other types of knowledge.

The IRIS DfA knowledge repository will mainly include the semantics for DfAknowledge in the form of metadata. These semantics will describe the types ofassistance that each type of knowledge (e.g. recommendation, tutorial,methodology, case study, etc.) can provide to the designer. The actual material willbe mainly external to the IRIS DSE (e.g. WAI accessibility guidelines are availableon the Web). This will address potential copyright issues. Even self-developedproject knowledge (e.g. extensions to existing recommendations, user requirementsfor specific types of applications, etc) may be located externally to the IRIS DSE.

2.7.3.1 Methodologies, Recommendations, Guidelines and PracticesDespite the fact that the usage of the IRIS DSE is independent of the methodologyused by the designer, the DfA knowledge will include issues related to designmethodology. Furthermore the IRIS DSE will include knowledge aboutrecommendations and specifications for ‘Design for All’. Currently a variety ofrecommendations exist that can be of great assistance to designers of Internetservices towards designing for all. Furthermore reference will be made to well knownexamples of design cases ranging from (successful or unsuccessful) applications tosimple Web pages or design patterns.

2.7.3.2 User ProfilesThe IRIS DSE knowledge repository will incorporate information about users anddesigners in the form of user profiles. User profiles will mainly include informationrelated to users (designers) of the IRIS DSE, however the inclusion of availablemodels and data for user requirements along with the methodology followed andcontext specific information will be considered for inclusion. User (designer) profileswill include personal profile information and device access information and will bebased on extensions / adaptations and implementations of related specifications (fora review see D0302int (User models for accessibility and enrolment of people withspecial needs).

2.7.3.3 DfA ToolsCurrently there are various (types of) tools that can provide assistance to designerstowards ‘Design for All’. However, as identified in D0301int (Review of guidelines andstandards for accessibility to Internet-based services), no single tool can address awide range of issues. The IRIS DSE will provide a purposeful synthesis of existing

29



and self-developed tools that can aid the designer towards a holistic confrontment of‘Design for All’ issues.

Currently there are some classifications of these tools available (e.g. see W3C WAIWeb site: http://www.w3.org/; Koutsabasis et al, 2001). The IRIS DSE knowledgerepository will take those classifications as a starting point towards the developmentof appropriate metadata specifications related to this type of knowledge.

It has to be noted that the functional components identified in this section will berevisited during project developments and external to the project evaluationsaccording to the project workplan.

30



3 IRIS Design Support Environment TechnicalArchitecture

The technical architecture of a system is one of the most important stages at the lifecycle model, which helps system developers at the design and implementation of asystem. In general there are two types of methods that corporations may follow forthe development of their system’s architecture. In the past, corporations were forcedto invent a server-side platform in-house while the modern approach supports thepurchase of a server-side platform from a middleware vendor, re-usable componentsfrom an application vendor and development and management tools from a toolsvendor. Every approach has advantages and disadvantages. The in-house server-side platform allows the better understanding of business culture and the fastintegration of the new system with the existing infrastructure, but on the other handis very expensive as the maintenance costs of a custom middleware solutionincrease exponentially, and it becomes necessary to train newly hired personnel onthe proprietary architecture. The vendor server-side platform offers development andmaintenance time decrease in conjunction with greater efficiency throughspecialization, but there is always the danger of incompatibility between thecomponents of the architecture. Our scope in the IRIS project is to ensure thecompatibility between the components of the DSE architecture while at the sametime mitigating the development, improvement and maintenance effort.

Technically, the IRIS DSE can be thought of comprising three layers, namely thepresentation layer, the application layer and the back end layer. More specifically:

• The presentation layer describes what the user interfaces displays and howuser requests are handled. The presentation logic is probably to have differentversions depending on which user interfaces are supported and what are theinterface requirements of users.

• The application layer models the application’s business rules through theinteraction with the application’s data

• The back-end layer includes Databases, Agents and the additional functionalityrequired by the application components

The diagram below presents in a schematic format the N-tier architecture

31



Presentation logic Business LogicClient

Database

OthersSystems

Agents

Presentation layer Application layer Back-end layer

Client side Server side

Figure 8 N-tier application architecture

o The User interface (client) handles the user’s interaction with theapplication; this can be a web browser running through a firewall or awireless device

o The Presentation logic defines what the user interface displays and how auser’s requests are handled – depending on what user interfaces aresupported one may need to have slightly different versions of thepresentation logic to handle the client appropriately

o The Business logic models the application’s business rules, often throughthe interaction with the application’s data

o The Infrastructure services provide additional functionality required by theapplication components, such as messaging, transactional support, etc.

o The data layer stores and manages application data

At the technical level the IRIS DSE may be either a standalone tool that is useddirectly by designers or an application that interfaces existing Web developmenttools, as shown in Figure 9.

32



Standalone withimport/export capabilities

Plug-in or API

Web basedIRISDSE

Redesign:Webforum,ONCROSS

Figure 9 A technical orientation of the IRIS Design Support Environment.

In order to identify and present the technical architecture of the IRIS DSE, there is aneed to overview and comment on existing services architectures and technologies.This section is devoted to this discussion. It first discusses and compares threepossible service architectures upon a number of technical issues: a) Java 2Enterprise Edition, b) Microsoft Windows DNA and c) Java 2 Enterprise edition withCOM support. Secondly, at a lower level of abstraction the criteria for technologyselection are identified and a number of state of the art technologies are evaluatedaccording to these criteria.

3.1 Platform architectures under considerationIn this section the three possible solutions are described: a) Java 2 EnterpriseEdition, b) Microsoft Windows DNA and c) Java 2 Enterprise edition with COMsupport. The selection of these three is based on their prominence and the fact thatthe market has adopted them more extensively. In the following sections a more indepth examination is given.

3.1.1 Java 2 Enterprise EditionThe Java 2 Platform, Enterprise Edition (J2EE) was designed to simplify complexproblems with the development, deployment, and management of multi-tierenterprise solutions. J2EE is an open industry standard, and is the result of anongoing industry collaboration led by Sun Microsystems. This collaborative processrepresents the collective expertise of the largest enterprise-computing vendors (suchas IBM, BEA, and Oracle), and ensures their participation and adoption. BecauseJ2EE is an open standard, it promotes competition among vendor products andtools, and thereby promotes best-of-breed products in the middleware space, thetool space, and the off-the-shelf component space.

A well-designed J2EE application can be independent of middleware, operatingsystem, and hardware. Middleware independence is possible because J2EE is aspecification, not a middleware implementation. Sun Microsystems enforcesmiddleware independence by requiring middleware vendors to pass a compatibilitytest suite before receiving the J2EE certification logo. Operating system andhardware independence is possible because J2EE is built on the platform-independent Java Virtual Machine (JVM).

33



Figure 10 The J2EE Object Model

J2EE is an evolution of several enterprise Java technologies, such as Java DatabaseConnectivity (JDBC), and Java Remote Method Invocation (RMI). The cornerstone ofJ2EE is Enterprise JavaBeans (EJB) technology, a standard for building server-sidecomponents.

3.1.2 Microsoft Windows DNA Like J2EE, Microsoft's Windows DNA was also designed to simplify complexproblems with the development, deployment, and management of multi-tierenterprise solutions. However, the most significant difference between the twoplatforms is that Windows DNA is a proprietary product designed and supported by asingle vendor, whereas J2EE is an open industry standard supported by all keymiddleware vendors, each of which is providing an implementation of the standard.

A Windows DNA application is tightly bound to Microsoft's Windows DNAimplementation. There is no open specification for Windows DNA, which preventsother vendors from providing Windows DNA implementations. Windows DNA

34



applications are also tightly bound to Microsoft's Windows 2000 operating system,and cannot be realistically deployed on other platforms. Because of this, hardwareselection is limited as well.

Windows DNA has evolved from the middleware services provided in Windows NT,such as the Component Object Model (COM), Distributed COM (DCOM), MicrosoftTransaction Server (MTS), and Microsoft Message Queue (MSMQ). The cornerstoneof Windows DNA is COM+, a standard for building server-side components.

Figure 11 The Windows DNA Object Model

3.1.3 Java 2 Enterprise edition with COM support It is true that up to now non-Windows operating systems, such as UNIX, are widelyused as a robust platform for application development and deployment. They offer a

35



combination of price, performance, and market availability that, until recently,couldn't be challenged by any other network operating system. However, Microsoftprovides a platform (Windows DNA architecture) that not only offers almost the sameresults with lower cost but also provides unique benefits that can significantly reducethe time and cost of designing. COM on non-Windows operating systems allowswrapping of existing logic on these systems in COM interface classes. This providesreplace front-end legacy logic on such systems with COM or Microsoft TransactionServer (MTS) or COM+ components running on Windows NT.

Furthermore, building COM-based apps in a heterogeneous environment, a kind ofinteroperability between Windows and non-Windows operating systems, providesmany new options for development and deployment. Running COM applications onsuch systems extends the flexibility of Windows NT-based enterprise applications.Building COM wrappers for existing logic, allows you to call that logic from MTS orCOM-based components running on Windows or any other operating system. Usinganother logical tier consisting of MTS servers as a front-end for legacy code provideseven more advantages, such as:

• Building more scalable applications

• Keeping legacy code that works

• Using the Windows NT programming model and improvements as theapplication evolves.

We believe that a combination of the two previous solutions (Solution 1 and Solution2) can provide us with the most efficient design because it combines the advantagesof the two previous platforms and provides an unlimited flexibility to all partners todesign their components with the technology that they have more concreteknowledge or they want to experiment with. This solution is actually based on Java 2Enterprise Edition but COM/COM+ support via COM-CORBA Bridge may be added.

36



COM-CORBA Bridge

COM objects COM

objects COM objects

Figure 12 J2EE model with COM support

In this context, a provisional table that states specific technical components that canbe used in the context of IRIS under the third solution, is shown below:Web server Apache, IIS, or other

JSP and Servlet container Tomcat

XML/XSL parser Cocoon and related technologies

Application server (EJB container) Jboss

SQL database server MySQL, SQL Server, ORACLE, etc.

Special agents EJB, CORBA and COM/COM+

OS Linux, Windows NT/2000, Unix (Sun Solaris, HP Unix, IBMUnix…)

Database connector ODBC, JDBC

37



All of the technical components stated here are described extensively later inAppendix A.

3.1.4 Criteria for the selection of final IRIS system architectureThe following criteria will be used for the selection of the final architecture as well asthe selection of the most appropriate technologies that will support each functionalmodule of the IRIS DSE:

1. Support for heterogeneous environments. Many large corporations have aheterogeneous server-side deployment environment, with a wide variety ofoperating systems, hardware and middleware products. A heterogeneousenvironment can also merge as the result of several distinct projects at anorganization or perhaps due to a merger or acquisition with another corporationthat has a different deployment environment. It is crucial to choose a unifyingprogramming language that can work equally well throughout the enterprisewithout having to use inefficient translation mechanisms.

2. Persistence. It is the storage of enterprise data in a durable data store, such asdatabase. Any serious commerce application requires persistence; just as anyserious commerce application requires security and transactions. A server-sideplatform should provide an automated, declarative persistence service to aid theapplication developer. Such a persistence service should provide adequatefunctionality to the developer. The evaluation parameters are the support forpersisting complex types of data, the support for persisting data across multipledata stores, the ability to override the server-side platform’s persistence and theability to provide custom persistence routines if necessary. An architecture thatprovides these features gives developers a higher degree of rapid applicationdevelopment, is powerful enough to address serious business problems, and yetis flexible enough to accommodate specialized needs.

3. Security. A secure deployment provides a mechanism to authenticate clients(test whether clients are who they claim to be) as well as authorize clients (testswhether clients have access rights to perform desired operations). Componentdevelopers should be able to perform security checks programmatically as wellas declaratively. There should also be a mechanism to control whether acomponent can run with the security level of its client, as well as delegate thosesecurity credentials when calling another subsystem.

4. Load-balancing. In a typical commerce system, presentation logic executes in aseparate physical tier from the business logic. Separation of tiers allows each tierto scale independently, enables one to secure business process and data logicwith a firewall and enables a Web development team and business process teamto each take care of a separate physical part of the enterprise. To accommodateheavy traffic, one must be able to scale any given tier by adding additionalmachines to that tier. Adding additional machines requires logic to load-balanceclient requests across machines. There must be logic to load-balance incomingrequests to the presentation tier, as well as load-balance requests from thepresentation tier to the business tier.

5. Preservation of existing IT investments. As corporations are forced to adapt tonew business requirements, it becomes essential to leverage investments inexisting enterprise information systems, rather than rewrite entire business

38



solutions from scratch. A server-side platform is needed that providesmechanisms to build on existing systems in an evolutionary (rather than arevolutionary) manner.

6. Platform maturity. The maturity of the proposed platforms is an important factorfor their evaluation. The server side component services in Windows DNA andCOM+ have been evolving since Microsoft Transaction Server (MTS) wasreleased in December 1996. J2EE and EJB products have been evolving sincethe spring of 1998. Even though, Windows DNA depict as the mature platform, inreality today’s high-end J2EE platform-based products contain fundamentaltransactional logic that has been in production for many years.

7. Industry support. The developing application must support as much as possiblestandards in order to avoid single vendor dependence. The purpose of theplatform is to be an open industry standard supported by all key middlewarevendors. The inclusion of multiple vendors in the specification process ensuresthat vendors will be able to successfully layer the selected platform on top ofestablished and proven existing solutions. The open collaborative specificationprocess of an open standard technology also reflects the collective knowledgeand expertise of a variety of enterprise computing vendors. This means thatproduct solutions will likely be available to fit any business needs.

8. Time to market. When developing a commerce solution in today’s marketplace,a few months of time is an eternity. One way to speed time to market is tochoose a server-side platform that allows rapid application development. It iscrucial to choose a platform that offer corporations the ability to externalize theircommon server-side plumbing tasks to a middleware vendor because thisenables developers to exclusively focus on creating business logic. Loweringdevelopment time.

9. Reusability of Code. Reuse is very important for the effectiveness andefficiency of the applications as it simplifies programming procedures. There aretwo ways to achieve it. First of all by segregating an application’s businessrequirements into component parts. The second way is by using objectorientation to encapsulate shared functionality. In the software world,encapsulation helps to cut down potential problems. In a system that consists ofobjects, the objects depend on each other in various ways. If some of themhappen to malfunction and software engineers have to change it in some way,hiding its operation from other objects means that it probably won’t be necessaryto change those other objects

10. Modularity. It refers to the simplification of complex programs into discretemodules that are responsible for a specific task. The concept of modularity isobject-oriented analysis, which is trying to identify separated and simple tasks inthe application in order to avoid conflict and misunderstanding.

11. High availability. A server-side platform must be highly available (24x7x365) toservice the needs of corporation’s customers and partners. Because the Internetis global and ubiquitous, even planned downtime during the evening can result insignificant lost business. Unplanned downtime during peak business hours canbe disastrous, and will become amplified even more as the Internet becomes aprimary vehicle for conducting business.

12. Scalability and Adaptability to change. It is the ability of the application to growin order to meet an increasing demand of users base. By rapidly evolving

39



applications to respond to changing market conditions, a corporation canleapfrog the competition through faster time to market, or quickly respond tosteps taken by its competitors. By designing commerce systems adaptable toincreased user load or transactional needs, an IT department can scale adeployment as demanded by the marketplace. The successful expansion ofsystem operations is secured by the effective use of system resources while theenlargement of the potential user base may be applied by the appropriatetechnological infrastructure.

13. Total cost of ownership. When purchasing a server-side platform, one mustconsider the total cost of ownership. This is defined as the price of the serverplatform, the cost to develop and evolve a solution on that platform, maintenancefees, lost deployment time due to scalability or instability problems and lostcustomers due to platform shortcomings. A low total cost of ownership is anecessity for a high-volume, mission-critical commerce site.

14. Maintainability. Often, corporations judge the cost of a deployment in the spanof a single project. In reality a deployment’s total cost includes the maintainabilityof the developed solution over time.

Splitting presentation logic from business and data logic (N-tier Architecture) andsupporting a number of different configurations ensures the fulfillment of the abovecriteria and ensures the interoperability in heterogeneous systems.

3.2 Examination of Technologies to Support Deployment ofIRIS DSE functional modules

The criteria described above will allow us to evaluate which technologies should beemployed in order to facilitate the design, development, deployment, maintenanceand exploitability of the IRIS DSE in the most efficient manner. We will examine foreach functional module of the IRIS DSE a) the Interaction Interface, b) the DfASupport, c) DfA (Knowledge Repository) as well as their respective submodules, themost appropriate technologies and we rank them using heuristic weighting factors foreach criteria in order to measure their relative importance. We compare as wellsome of the technologies described.

3.2.1 Interaction InterfaceThe Interaction Interface as it has already been described in the previous chapter,comprises mainly three functional submodules: a) User Interface, b) Interactionsupport and c) Software interface. In the next section, we examine the mostappropriate technologies and we classify them accordingly.

3.2.1.1 User Interface TechnologiesUser interface describes all issues regarding presentation toward both end-usersand designers (very often the same person plays both these roles at the same time.The criteria related to user interface are:

− Support for heterogeneous environments: It is crucial to choose a unifyingprogramming language that can work equally well throughout the enterprisewithout having to use inefficient translation mechanisms;

40



− Security: Technologies used in user interface implementation must providesecure communication between client and system;

− Load-balancing;

− Preservation of existing IT investments: It is important to leverageinvestments in existing enterprise information systems, rather than rewriteentire business solutions from scratch;

− Industry support: Technologies used in user interface implementation mustsupport as much as possible standards, specifications and recommendationsin order to avoid single vendor dependence;

− Time to market: This criterion will be satisfied by choosing a server-sideplatform that allows rapid application development;

− Reusability and Modularity: Code reuse is very important for the effectivenessand efficiency of the applications as it simplifies programming procedures;

− Total cost of ownership: As low total cost of ownership is a necessity for ahigh-volume site, it is important to reduce these expenses as much aspossible by choosing open-source and vendor-independent technologies;

− Splitting presentation logic from business and data logic: It is important tochoose technologies that have a core-support for this kind of separation.

The technologies that support user interfaces with respect to the criteria mentionedabove are HTML, XML, JSP, Servlets, and JFC Swing. We will examine them nowand rank them with respect the above criteria.

Hypertext Markup Language (HTML)HTML is the non-proprietary format for publishing hypertext on the World Wide Web,created and mantained by the World Wide Web Consortium. It can be created andprocessed by a wide range of tools, from simple plain text editors to sophisticatedWYSIWYG authoring tools. HTML uses tags to structure text into headings,paragraphs, lists, hypertext links etc. HTML is not designed to be used to controldocument layout. HTML should be used to mark up headings, paragraphs, lists,hypertext links, and other structural parts of document, and then use a style sheet tospecify layout separately. That way, not only is there a better chance of all browsersdisplaying document properly, but also, if required changing such things as the fontor color, is simple to do so. HTML documents are supposed to be structured arounditems such as paragraphs, headings and lists.

As pointed out by some authors (Velasco, 2001c), The need of a new meta-language to create new markup languages is justified by several problems presentedby HTML: it is not extensible by the author (although browser manufacturers definedproprietary tags in the past); it is display-centric (a well-known accessibility hurdle); itis not directly reusable; it only provides one view of the data; it has little or nosemantic structure; and it is not suitable for data exchange.

Extensible Markup Language (XML)As defined in the W3C recommendation, XML is a subset of SGML developed toenable generic SGML to be served, received, and processed on the Web in the waythat is now possible with HTML. Despite an initially slow take-up, the industry isadopting XML at an increasing pace. XML will shortly become a de-facto standard

41



for e-commerce and distributed applications. There are several elements that makethe future of XML promising (Velasco, 2001c):

1. It is well suited for data interchange between different organizations andindividuals. It will represent the «end of proprietary file formats,» were thestructure of the documents is decided by the vendor of the tool used in theorganization. Even if the structure of the Document Type Definition (DTDs) isnot available, XML documents can be read and exchanged, becausedocuments are standard Unicode text files, and its well-formedness can bechecked against the recommendation, which defines an unambiguousmechanism for constraining the structure. Thus XML bridges the gapbetween human-readable documents, and machine-readable documents,allowing a smooth and seamless interchange of information.

2. It allows to store the information in a hierarchical format. It must be stressedthat XML is better adapted to exchange information with Object Databases,although they have not reached yet the maturity and spread of RelationalDatabases.

3. It enables the use of smart software agents, and provides to Internet andlocal search engines with meaningful elements to classify and sortdocuments with the assistance of the document markup and content. It alsoallows the employment of meta-data [3,4].

4. It has a strict and consistent syntax that makes documents easy to process.

The landscape of new languages based upon the Extensible Markup Language(XML) of the World Wide Web Consortium (W3C) is growing at a fast pace. Theflexibility of these markup languages makes them specially suitable to developapplications and services for upcoming technologies. Among them, we can highlightXSL (Extensible Stylesheet Language), which consists of two parts: XSLT (XSLTransformations), and XSL:Formatting Objects (XSL:FO).

The DOM (Document Object Model) is a standard set of function calls formanipulating XML (and HTML) files from a programming language. And XML, as aW3C technology, is license-free. XML is the preferred technology in manyinformation-transfer scenarios because of its ability to encode information in a waythat is easy to read, process, and generate. As mentioned earlier, XML languageshave a number of uses including exchanging information, defining document typesand specifying messages. Information that is expressed in a structured, text-basedformat can easily be transmitted between, transformed, and interpreted by entitiesthat understand the structure. In this way XML brings the same cross-platformbenefits to information exchange as the Java programming language has forprocessing.

JavaServer Pages (JSP) JSP technology allows web developers and designers to rapidly develop and easilymaintain, information-rich, dynamic web pages that leverage existing businesssystems. As part of the Java family, JSP technology enables rapid development ofweb-based applications that are platform independent. JSP technology separatesthe user interface from content generation enabling designers to change the overallpage layout without altering the underlying dynamic content. JSP technology usesXML-like tags and scriptlets written in the Java programming language toencapsulate the logic that generates the content for the page. Additionally, the

42



application logic can reside in server-based resources (such as JavaBeanscomponent architecture) that the page accesses with these tags and scriptlets. Anyand all formatting (HTML or XML) tags are passed directly back to the responsepage. By separating the page logic from its design and display and supporting areusable component-based design, JSP technology makes it faster and easier tobuild web-based applications. The JSP specification is the product of industry-widecollaboration with industry leaders in the enterprise software and tools markets, ledby Sun Microsystems. Sun has made the JSP specification freely available to thedevelopment community, with the goal that every web server and application serverwill support the JSP interface. JSP technology is a key component in the Java 2Platform, Enterprise Edition, Sun's highly scalable architecture for enterpriseapplications.

JSP technology provides a number of capabilities that are ideally suited for workingwith XML. JSP pages can contain any type of text-based data, so it is straightforwardto generate documents that contain XML markup. Also, JSP pages can use the fullpower of the Java platform to access programming language objects to parse andtransform XML messages and documents. In particular, as part of the Java softwareenvironment, JSP pages can use objects that leverage the new Java APIs forprocessing XML data. Finally JSP technology provides an abstraction mechanism toencapsulate functionality for ease of use within a JSP page.

Java Servlet technologyThis technology provides web developers with a simple, consistent mechanism forextending the functionality of a web server and for accessing existing businesssystems. A servlet can almost be thought of as an applet that runs on the server side- without a face. Servlets are the Java platform technology of choice for extendingand enhancing web servers. Servlets provide a component-based, platform-independent method for building web-based applications, without the performancelimitations of CGI programs. And unlike proprietary server extension mechanisms,servlets are server-independent as well as platform-independent. Servlets haveaccess to the entire family of Java APIs, including the JDBC API to accessenterprise databases. Servlets can also access a library of HTTP-specific calls andreceive all the benefits of the mature Java language, including portability,performance, reusability, security and crash-protection.

The Java Foundation Class (JFC) SwingJFC is a set of user interface components, which is built using a “Pluggable Lookand Feel” architecture. This architecture separates the implementation of the userinterface components from their presentation. On a component-by-component basis,the presentation is programmatically determined, and can be chosen by the user.Instead of a visual presentation, a user could instead choose an audio presentation,or a tactile (e.g. Braille) presentation, or a combination of the two. With this support,a user wouldn't need a separate assistive technology product interpreting the visualpresentation of the program on the screen, but would instead have direct access tothat program because it would interact with the user in his/her desired modality. TheJFC Swing user interface building blocks are designed around a “Pluggable Lookand Feel” architecture that allows to get away from interpreting the visualmanifestations, and instead "plug in" a non-visual manifestation. This architectureseparates the expression of the user interface from the underlying structure and dataon a component-by-component basis. This is accomplished by separating the userinterface of the component from the "model" of the component (the structure whichencapsulates the state and information that the user interface portion presents to the

43



user). In order to make it easy to migrate from the user interface classes in the JavaAbstract Window Toolkit (AWT) to the new Swing user interface classes, Swingprovides a parallel set of user interface classes to those in AWT. There are over fiftyuser interface building blocks in Swing, including the common items such as buttons,check boxes, radio buttons, combo boxes, menus, and labels, as well moresophisticated items such as tooltips, tabbed panes, tree views, table views, editabletext fields, HTML editors, a Color Chooser, a Money Chooser, etc. Each of theseSwing user interface classes fully supports the “Pluggable Look and Feel”architecture.

3.2.1.2 Ranking of relevant technologiesHeuristic weighting factors are devised to measure the relative importance of thedifferent criteria with respect to the user interface. A criterion can be assigned high(weighting factor=3), medium (weighting factor=2) or low (weighting factor=1)priority. In the following table, all the technologies mentioned above are presentedwith respect to the evaluation criteria (with their associated weighting factors).

Criteria Weightingfactor HTML XML JSP/Servlets JFC

Swing

1.Support forheterogeneousenvironments

High Yes Yes Yes Yes

2. Persistence Medium - Yes - -

3. Security High - - Yes -

4. Load-balancing Low - - Yes -

5.Preservation ofexisting ITinvestments

Medium Yes Yes Yes Yes

6. Maturity Medium Yes Yes Yes -

7. Industry support High Yes Yes Yes -

8. Time to market Medium Yes Yes Yes -

9. Reusability High - Yes Yes Yes10

. Modularity High - Yes Yes Yes

11. High availability Low - - - -

12.

Scalability andAdaptability tochange

Low - - - -

13.

Total cost ofownership High Yes Yes Yes Yes

14. Maintainability Low - - - -

44



15.

Splittingpresentation logicfrom business anddata logic (N-tierArchitecture)

High - - Yes Yes

As a conclusion JSP technology and servlets together provide an attractivealternative to other types of dynamic web scripting/programming that offer platformindependence, enhanced performance, separation of logic from display, ease ofadministration, extensibility into the enterprise and most importantly, ease of use.Java and XML is a natural match for the creation of applications that exploit the webof information where different classes of clients consume and generate informationthat is exchanged between different servers that run on varied system platforms.

3.2.1.3 Interaction SupportInteraction support will take into consideration all models of interaction to inform thedevelopment of usability guidance. For example, instead of a visual presentation, auser will choose an audio presentation, or a tactile (e.g. Braille) presentation, or acombination of the two. In the same manner as before the criteria relevant tointeraction support are:

− Support for heterogeneous environments,

− Preservation of existing IT investments,

− Maturity,

− Industry support,

− Reusability,

− Modularity,

− Total cost of ownership,

− Maintainability.

Similarly, Java technologies like Java Accessibiliy API, Java Accessibility Utilities,Java Access Bridge, provide extensive interaction support with respect to therelevant criteria.

Java Accessibility APIThis API defines a contract between the individual user interface components thatmake up a Java application and an assistive technology that is providing access tothat Java application. If a Java application fully supports the Java Accessibility API,then it should be compatible with, and friendly toward, assistive technologies such asscreen readers, screen magnifiers, etc. With a Java application that fully supportsthe Java Accessibility API, no off-screen model would be necessary because the APIprovides all of the information normally contained in an off-screen model. In order toprovide access to Java applications, an assistive technology requires more than theJava Accessibility API: it also requires support in locating the objects that implementthe API as well as support for being loaded into the Java Virtual Machine, trackingevents, etc.

45



Java Accessibility UtilitiesThe Java Accessibility Utilities are delivered by Sun as a separately downloadablepackage for use by assistive technology vendors in their products that provideaccess to Java applications running in a Java Virtual Machine. This packageprovides the necessary support for assistive technologies to locate and query userinterface objects inside a Java application running in a Java Virtual Machine. It alsoprovides support for installing "event listeners" into these objects. These eventlisteners allow objects to learn about specific evens occurring in other objects usingthe peer-to-peer approach defined by the delegation event model. Finally, thispackage provides specific support for loading assistive technologies into a JavaVirtual Machine. As a conclusion: Together with tools such as screen readers andhands-free pointing devices, Java technology is helping to make computing andcomputer usage a reality for people with disabilities. (for example, a sight-impairedprogrammer who uses a screen reader to describe the components of a program'sgraphical user interface, or a quadriplegic who depends on a hands-free pointingdevice to update a spreadsheet.) These tools need access to the characteristics ofthe displayed content. In other words, the screen reader needs to know that acomponent is a button rather than a text field; the pointing device needs todistinguish each column of the spreadsheet. And that's where Java technologycomes in. Through the Java Accessibility API, application developers can make thecharacteristics of a program's user interface available to assistive technologies.

Java Access BridgeIt is a means by which already existing assistive technologies, operating on nativeplatforms, can access the information offered up by the Java Accessibility API withina given applet or application. Java applications run on a wide variety of hostoperating systems, many of which already have assistive technologies available forthem. In order for these existing assistive technologies to provide access to Javaapplications, they need a bridge between themselves in their native environment(s),and the Java Accessibility support that is available from within the Java VirtualMachine (JVM). This bridge, by virtue of the fact that it has one end in the JVM andthe other on the native platform, will be slightly different for each platform it bridgesto.

3.2.1.4 Ranking of relevant technologies Heuristic weighting factors are devised in the same manner as before in order tomeasure the relative importance of the different criteria with respect to the interactionsupport. A criterion can be assigned high, medium or low priority. In the followingtable, all the technologies mentioned above are presented with respect to theevaluation criteria (with their associated weighting factors).

Criteria Weightingfactor

JavaAccessibility

API

JavaAccessibility

UtilitiesJava Access

Bridge


High Yes Yes Yes

2. Persistence Low - - -

46



3. Security Medium - - -

4. Load-balancing Low - - -

5. Preservation ofexisting IT investments Medium - - -

6. Maturity High Yes Yes Yes

7. Industry support High Yes Yes Yes

8. Time to market Medium - - -

9. Reusability High Yes Yes Yes10

. Modularity High Yes Yes Yes

11. High availability Medium - - -

12.

Scalability andAdaptability to change Low - - -

13.

Total cost ofownership High - - -

14. Maintainability High Yes Yes Yes

15.

Splitting presentationlogic from businessand data logic (N-tierArchitecture)

Medium - - -

3.2.1.5 Software interfaceIn general, software interface describes collaboration between a WebProduct/Application and a Web Environment. Similarly the criteria relevant tosoftware interface are:

− Support for heterogeneous environments,

− Security,


− Maturity, Industry support,

− Time to market,

− Total cost of ownership.

The CORBA (Common Object Request Broker Architecture) technology providesextensive support for software interfaces with respect to the criteria mentionedabove. CORBA technology is the open standard for heterogeneous computing.CORBA complements the Java platform by providing a distributed objectsframework, services to support that framework, and interoperability with otherlanguages. CORBA technology is an integral part of the Java 2 platform through EJB(Enterprise JavaBeans), RMI (Remote Method Invocation) over IIOP (Internet Inter-

47



ORB Protocol), Java IDL (Interface Definition Language), and Java TransactionService (JTS).

RMI over IIOPThis is part of the Java 2 Platform, Enterprise Edition. It provides the ability to writeCORBA applications for the Java platform without learning CORBA InterfaceDefinition Language (IDL). To work with CORBA applications in other languages, IDLcan be generated from Java programming language interfaces. RMI over IIOPincludes the full functionality of a CORBA Object Request Broker (ORB) and JavaCORBA code can be written without having to license any other software. RMI-IIOPcombines the best features of Java Remote Method Invocation (RMI) with the bestfeatures of Common Object Request Broker Architecture (CORBA). It provides adesigner/developer with a powerful environment in which to do distributedprogramming using the Java platform. Like RMI, RMI-IIOP speeds distributedapplication development by allowing developers to work completely in the Javaprogramming language. When using RMI-IIOP to produce Java technology-baseddistributed applications, there is no separate Interface Definition Language (IDL) ormapping to learn. Like RMI, RMI-IIOP provides flexibility by allowingdevelopers/designers to pass any serializable Java object (Objects By Value)between application components. Like CORBA, RMI-IIOP is based on openstandards defined with the participation of hundreds of vendors and users in theObject Management Group. Like CORBA, RMI-IIOP uses Internet Inter-ORBProtocol (IIOP) as its communication protocol. IIOP eases legacy application andplatform integration by allowing application components written in C++, Smalltalk,and other CORBA supported languages to communicate with components runningon the Java platform. With RMI-IIOP, developers/designers can write remoteinterfaces in the Java programming language and implement them simply using Javatechnology and the Java RMI APIs. These interfaces can be implemented in anyother language that is supported by an OMG mapping and a vendor supplied ORBfor that language. Similarly, clients can be written in other languages using IDLderived from the remote Java technology-based interfaces. Using RMI-IIOP, objectscan be passed both by reference and by value over IIOP.

Java Interface Definition Language (Java IDL)It is part of the Java 2 Platform, Standard Edition. Java IDL adds CORBA capabilityto the Java platform, providing standards-based interoperability and connectivity.Java IDL enables distributed Web-enabled Java applications to transparently invokeoperations on remote network services using the industry standard IDL (ObjectManagement Group Interface Definition Language) and IIOP (Internet Inter-ORBProtocol) defined by the Object Management Group. Runtime components includeJava ORB for distributed computing using IIOP communication.

Java 2 Platform, Enterprise Edition (J2EE) simplifies application programming fordistributed transaction management. J2EE includes support for distributedtransactions through two specifications, Java Transaction API (JTA) and JavaTransaction Service (JTS). JTA is a high level, implementation independent,protocol independent API that allows applications and application servers to accesstransactions. It specifies standard Java interfaces between a transaction managerand the parties involved in a distributed transaction system: the resource manager,the application server, and the transactional applications. JTS specifies the

48



implementation of a Transaction Manager that supports JTA and implements theJava mapping of the OMG Object Transaction Service (OTS) 1.1 specification at thelevel below the API. JTS propagates transactions using the Internet Inter-ORBProtocol (IIOP). JTS is part of the Java 2 Platform, Enterprise Edition and providesan implementation of the Java Transaction API (JTA). JTS uses the standardCORBA ORB/TS interfaces and Internet Inter-ORB Protocol (IIOP) for transactioncontext propagation between JTS Transaction Managers. A JTS TransactionManager provides transaction services to the parties involved in distributedtransactions: the application server, the resource manager, the standalonetransactional application, and the Communication Resource Manager (CRM).

JTA and JTS allow application servers built on the Java 2 Platform, EnterpriseEdition to take the burden of transaction management off of the componentdeveloper. Developers can define the transactional properties of EnterpriseJavaBeans technology based components during design or deployment usingdeclarative statements in the deployment descriptor. The application server takesover the transaction management responsibilities.

Simple Object Access Protocol (SOAP)SOAP is a lightweight protocol for exchange of information in a decentralized,distributed environment. It is an XML based protocol that consists of three parts:

• an envelope that defines a framework for describing what is in a messageand how to process it,

• a set of encoding rules for expressing instances of application-defineddatatypes, and

• a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols suchas HTTP.SOAP provides a simple and lightweight mechanism for exchanging structured andtyped information between peers in a decentralized, distributed environment usingXML. SOAP does not itself define any application semantics such as a programmingmodel or implementation specific semantics; rather it defines a simple mechanismfor expressing application semantics by providing a modular packaging model andencoding mechanisms for encoding data within modules. This allows SOAP to beused in a large variety of systems ranging from messaging systems to RemoteProcedure Calls (RPC).SOAP consists of three parts:

• The SOAP envelope construct defines an overall framework for expressingwhat is in a message; who should deal with it, and whether it is optional ormandatory.

• The SOAP encoding rules (see) defines a serialization mechanism that canbe used to exchange instances of application-defined datatypes.

• The SOAP RPC representation (see) defines a convention that can be usedto represent remote procedure calls and responses.

Although these parts are described together as part of SOAP, they are functionallyorthogonal. In particular, the envelope and the encoding rules are defined in differentnamespaces in order to promote simplicity through modularity.

49



In addition to the SOAP envelope, the SOAP encoding rules and the SOAP RPCconventions, this specification defines two protocol bindings that describe how aSOAP message can be carried in HTTP messages either with or without the HTTPExtension Framework.A major design goal for SOAP is simplicity and extensibility. This means that thereare several features from traditional messaging systems and distributed objectsystems that are not part of the core SOAP specification. Such features include

• Distributed garbage collection • Batching of messages • Objects-by-reference (which requires distributed garbage collection) • Activation (which requires objects-by-reference)

3.2.1.6 Ranking of Technologies Heuristic weighting factors are also devised to measure the relative importance ofthe different criteria with respect to the software interface. In the following table, allthe technologies mentioned above are presented with respect to the evaluationcriteria (with their associated weighting factors).

Criteria Weightingfactor CORBA JTA/JTS RMI-IIOP SOAP



2. Persistence Low - - - Yes

3. Security High Yes Yes Yes Yes

4. Load-balancing Low - - - -

5.Preservation ofexisting ITinvestments


6. Maturity High Yes Yes Yes Yes

7. Industry support High Yes Yes Yes Yes

8. Time to market High Yes Yes Yes Yes

9. Reusability Low - - - Yes

10. Modularity Low - - - Yes

11. High availability Medium - - - -

12.Scalability andAdaptability tochange

Low - - - -

13. Total cost ofownership High Yes Yes Yes Yes

14. Maintainability Medium - - - -

50



15.

Splittingpresentationlogic frombusiness anddata logic (N-tierArchitecture)

Low - - - -

3.2.2 DfA SupportFrom the information technology point if view, the DfA Support functionalcomponents can be developed in the form of either stand-alone, thin-client or evencomplex client-server multi-tier application while the criteria relevant to thesemodules are:

− Support for heterogeneous environments (It is crucial to choose a unifyingprogramming language that can work equally well throughout the enterprisewithout having to use inefficient translation mechanisms),


− Platform maturity, Industry support (It is important to choose a technologiesthat are well-supported by numerous vendors and organizations),

− Reusability (Technologies used in application development must be based onadvanced concepts such as object-oriented approach),

− Modularity,

− Total cost of ownership,

− Maintainability,

− Splitting presentation logic from business and data logic.

The Java Enterprise Edition technologies provide extensive support for all thesemodules with respect to the criteria mentioned above. Actually, J2EE applicationsdeveloper/designers write J2EE application components. A J2EE component is aself-contained functional software unit that is assembled into a J2EE application andinterfaces with other application components. The J2EE specification defines thefollowing application components: Application client components, EnterpriseJavaBeans components, Servlets and JavaServer Pages (JSP) components (alsocalled Web components), Applets.

A Java Applet is a program written in the Java programming language that can beincluded in an HTML page, much in the same way an image is included. When usinga Java technology-enabled browser to view a page that contains an applet, theapplet's code is transferred to client system and executed by the browser's JavaVirtual Machine (JVM). Applets are a powerful tool in supporting client-sideprogramming, a major issue for the Web. Programming within an applet is veryrestrictive since there is the Java run-time security system. Java offers digital signingfor applets so a developer/designer can choose to allow trusted applets to haveaccess to local machine. To support more complex user interactions, it may benecessary to provide functionality directly in the client tier. This functionality istypically implemented as JavaBeans components that interact with the service in the

51



middle tier via servlets. Client-tier JavaBeans components would typically beprovided by the service as an applet that is downloaded automatically into a user'sbrowser. To eliminate problems caused by old or non-standard versions of the JVMin a user's browser, the J2EE application model provides special support forautomatically downloading and installing the Java Plug-in. Client-tier beans can alsobe contained in a stand-alone application client written in the Java programminglanguage. In this case, we would typically make operating system specific installationprograms for the client available for designer users to download via their browsers.Users execute the installation file and are then ready to access the service. SinceJava technology programs are portable across all environments, the service needonly maintain a single version of the client program. Although the client programitself is portable, installation of the Java technology client typically requires OS-specific code. There are several commercial tools that automate the generation ofthese OS-specific installation programs. If desired, non-Java clients can presentJ2EE services to users. Since the service is presented by servlets in the middle tierto first-tier clients using the standard HTTP protocol, it is easy to access it frompractically any program running on any operating system.

Similarly the Component Library Delivery module will consist of all reusablecomponents used in IRIS applications. These components will be used toencapsulate business logic of IRIS applications and will be deployed and executed incontext of application server (component container). The criteria relevant toComponent Library are :

− Support for heterogeneous environments (An IRIS application typically needs tobe customized at deployment time to each operational environment. Componentarchitecture must allow the component developer/designer to separate thecommon application business logic from the customization logic performed atdeployment time. It also must allow persistent components to be bound todifferent data sources. This persistence binding is done at deployment. Theapplication developer/designer can write code that is not limited to a single typeof data sources. Component architecture also facilitates the deployment of anapplication by establishing deployment standards, such as for data sourcelookup, other application dependencies, security configuration, and so forth. Thestandards enable the use of deployment tools. The standards and tools removemuch of the possibility of miscommunication between the developer/designer anddeployer),

− Persistence,

− Security (Components must rely on an architecture that will shift most of theresponsibility for an application’s security from the developer/designer to theserver vendor, or System Administrator etc. The people performing these rolesare more qualified than the developer/designer to secure the application. Thiskind of approach to application’s security leads to better security of theoperational applications),

− Preservation of existing IT investments (Component architecture must simplifyand standardize the integration of IRIS applications with any existing operationalapplications and systems at the target operational environment),

− Maturity,

− Industry support (Component architecture must be supported by great variety ofsoftware vendors, companies and organizations),

52



− Reusability (An IRIS application will consist of components, a reusable buildingblocks. There are two essential ways to reuse a component: A component notyet deployed can be reused at application development time by being included inseveral different applications. The component can be customized for eachapplication without requiring changes, or even access, to its source code. Otherapplications can reuse a component that is already deployed in a customer’soperational environment by making calls to its client-view interfaces. Multipleapplications can make calls to the deployed component),

− Modularity,

− Scalability,

− Maintainability,

− Separation of business logic from presentation logic (This separation makes itpossible to develop multiple presentation logic for the same business process, orto change the presentation logic of a business process without needing to modifythe code that implements the business process)

The Enterprise JavaBeans (EJB) architecture provides extensive support for theComponent Library Module, with respect to the criteria mentioned above. The EJBcomponent architecture is the backbone of the J2EE platform. The core of a J2EEapplication is comprised of one or several enterprise beans that perform theapplication’s business operations and encapsulate the business logic of anapplication. Other parts of the J2EE platform, such as the JavaServer Pages,complement the EJB architecture to provide functions such as presentation logic andclient interaction control logic. The EJB specification defines a component modeland deployment environment to simplify the lifecycle of multi-tiered distributedsystems. EJB is a specification defined by JavaSoft, endorsed and implemented bymany vendors. It’s not an actual product. An EJB-compliant product is a product thatimplements and adheres to the standards set out in the specification. The objectiveof the EJB specification is to “make it easy to write [server-side] applications”. TheEJB specification achieves this objective by defining a set of design patterns for theserver-side code as well as roles, which various developers, administrators, andsystem components play in the various phases of the lifecycle of a distributedapplication. Through the use of a set of standard design patterns and roles, whichdecouple business logic from system infrastructure- products which adhere to theEJB specification make it possible to write applications without having to understandthese low-level system infrastructure issues such as transactions, cachingmechanisms, multi-threading and security. The definition of these roles andcomponents also gives the application developer vendor independence. EJBvendors adhere and contribute to the one specification, hence Enterprise Java Beancomponents are easily transferable between vendors tools and platforms and deliveron Java’s promise of “Write Once, Run Anywhere” philosophy.

EJBeans are reusable components that are developed in accordance with theDesign Patterns highlighted in the EJB specification. EJBeans can be of two differenttypes, Entity Beans and Session Beans. EJB architecture supports persistence overpersistent objects called entity beans. An entity bean is an object representation ofsome persistent data, such as a record stored in a database. When building an entitybean, a developer/designer can either write her/his own code to retrieve the objectdata from the persistent data store and write back any updates when the transactioncompletes. EJB will automatically manage the persistence of the data on behalf ofthe object. If EJB manages the persistence, the object is portable across any data

53



store. For example, the object could be mapped to a relational database in oneapplication and to an object database in another, and a developer/designer doesn’thave to change any code in the application to make it happen. The EJB 1.0specification did not require Entity Beans to be implemented, this has changed inversion 1.1, which makes mandatory the implementation of Entity Beans. The EJB1.1 specification has also further clarified some ambiguous issues with SessionBeans. It is the responsibility of the EJB Container to provide caching, session andlifecycle management of all EJBs so that the Bean Provider can focus on solving thebusiness problem at hand.

3.2.2.1 Ranking of TechnologiesHeuristic weighting factors are also devised here to measure the relative importanceof the different criteria with respect to the component library. In the following table, allthe technologies mentioned above are presented with respect to the evaluationcriteria (with their associated weighting factors).

Criteria Weightingfactor EJB

1. Support for heterogeneousenvironments High Yes

2. Persistence High Yes

3. Security High Yes

4. Load-balancing Low -

5. Preservation of existing ITinvestments High Yes

6. Maturity High Yes

7. Industry support High Yes

8. Time to market Medium -

9. Reusability High Yes

10. Modularity High Yes

11. High availability Low -

12. Scalability and Adaptabilityto change High Yes

13. Total cost of ownership Medium -

14. Maintainability High Yes

15.Splitting presentation logicfrom business and datalogic (N-tier Architecture)

High Yes

3.2.3 DfA Knowledge (Knowledge Repository)Similarly to enterprise applications that require access to applications running onenterprise information systems (such as enterprise resource planning systems,mainframe transaction processing systems, relational database management

54



systems, and other legacy information systems), IRIS will run its services using theinformation stored in such systems; the success of the system critically depends onthis information. The IRIS system cannot afford to have an application causeinconsistent data or compromise the integrity of data stored in these systems. Thisleads to a requirement for ensuring transactional access to enterprise informationsystems from various applications. The criteria relevant to Knowledge Repositoryare:

− Support for heterogeneous environments (Many large corporations have aheterogeneous server-side deployment environment, with a wide variety ofoperating systems, hardware and middleware products.);

− Security (A mechanism to authenticate clients as well as authorize clients mustbe provided.);

− Load-balancing (In order to accommodate heavy traffic, a multi-tier system mustbe able to scale any tier by adding additional machines to that tier. Addingadditional machines requires logic to load-balance client requests acrossmachines. There must be logic to load-balance incoming requests to thepresentation tier, as well as load-balance requests from the presentation tier tothe business tier, and so on.);

− Preservation of existing IT investments (It is important to leverage investments inexisting enterprise information systems.);

− Maturity;

− Industry support (Technologies that will be used must support as much aspossible standards, specifications and recommendations in order to avoid singlevendor dependence);

− High availability;

− Total cost of ownership (As low total cost of ownership is a necessity for a high-volume site, it is important to reduce these expenses as much as possible bychoosing open-source and vendor-independent technologies);

− Maintainability.

The Java technologies such as JDBC and JNDI provide extensive support forKnowledge Repository with respect to the criteria mentioned above.

The Java Database Connectivity (JDBC) technology is an API that letsdeveloper/designer to access virtually any tabular data source from the Javaprogramming language. It provides cross-DBMS connectivity to a wide range of SQLdatabases, and provides access to other tabular data sources, such as spreadsheetsor flat files. The JDBC API allows developers/designers to take advantage of theJava platform's capabilities for industrial strength, cross-platform applications thatrequire access to enterprise data. With a JDBC technology-enabled driver, adeveloper/designer can easily connect all corporate data even in a heterogeneousenvironment.

These are advantages of JDBC Technology:

• Leverage Existing Enterprise Data (With JDBC technology, businesses are notlocked in any proprietary architecture, and can continue to use their installeddatabases and access information easily - even if it is stored on differentdatabase management systems);

55



• Simplified Enterprise Development (The combination of the Java API and theJDBC API makes application development easy and economical. JDBC hides thecomplexity of many data access tasks, doing most of the "heavy lifting" for thedeveloper behind the scenes. The JDBC API is simple to learn, easy to deploy,and inexpensive to maintain);

• Zero Configuration for Network Computers (With the JDBC API, no configurationis required on the client side. With a driver written in the Java programminglanguage, all the information needed to make a connection is completely definedby the JDBC URL or by a DataSource object registered with a Java Naming andDirectory Interface (JNDI) naming service. Zero configuration for clients supportsthe network computing paradigm and centralizes software maintenance.)

These are key-features of JDBC technology:

• Full Access to Metadata (The JDBC API provides metadata access that enablesthe development of sophisticated applications that need to understand theunderlying facilities and capabilities of a specific database connection.);

• No Installation (A Pure JDBC technology-based driver does not require specialinstallation; it is automatically downloaded as part of the applet that makes theJDBC calls.);

• Database Connection Identified by URL (JDBC technology exploits theadvantages of Internet-standard URLs to identify database connections. The newJDBC 2.0 API adds an even better way to identify and connect to a data source,using a DataSource object, that makes code even more portable and easier tomaintain. In addition to this important advantage, DataSource objects canprovide connection pooling and distributed transactions, essential for enterprisedatabase computing. This functionality is provided transparently to theprogrammer.);

• Included in the Java Platform (As a core part of the Java 2 Platform, the JDBC2.0 core API is available anywhere that the platform is. This means that Javaapplications can truly write database applications once and access dataanywhere. The Java 2 Platform, Enterprise Edition (J2EE), includes both theJDBC core API and the JDBC Optional Package API. The Optional Package APIcontains server-side functionality for industrial strength scalability.);

• Requirements (Software: The Java 2 Platform, either the Java 2 SDK, StandardEdition, or the Java 2 SDK, Enterprise Edition, an SQL database, and a JDBCtechnology-based driver for that database. Hardware: Same as the Java 2Platform.);

• Availability (The JDBC API specification is available on the Java Software website. The JDBC API and a reference implementation of the JDBC-ODBC Bridgeand related documentation are shipping now with the Java 2 SDK, StandardEdition, and the Java 2 SDK, Enterprise Edition.).

The Java Naming and Directory Interface (JNDI) is a standard extension to theJava platform, providing Java technology-enabled applications with a unifiedinterface to multiple naming and directory services in the enterprise. As part of theJava Enterprise API set, JNDI enables seamless connectivity to heterogeneousenterprise naming and directory services. Developers/designers can now buildpowerful and portable directory-enabled applications using this industry standard.JNDI is an API specified in Java that provides naming and directory functionality to

56



applications written in Java. It is designed especially for Java by using Java's objectmodel. Using JNDI, Java applications can store and retrieve named Java objects ofany type. In addition, JNDI provides methods for performing standard directoryoperations, such as associating attributes with objects and searching for objectsusing their attributes. JNDI is also defined independent of any specific naming ordirectory service implementation. It enables Java applications to access different,possibly multiple, naming and directory services using a common API. Differentnaming and directory service providers can be plugged in seamlessly behind thiscommon API. This allows Java applications to take advantage of information in avariety of existing naming and directory services, such as LDAP, NDS, DNS, andNIS (YP), and allows Java applications to coexist with legacy applications andsystems. Using JNDI as a tool, the Java application developer/designer can buildnew powerful and portable applications that not only take advantage of Java's objectmodel but also are well-integrated with the environment in which they are deployed.

Directory-enabled applications and applets (application like IRIS that uses a namingor directory service), like any other program running on the network, can use thedirectory in the traditional way, that is, to store and retrieve attributes of directoryobjects. (For example, a mail client program can use the directory as an addressbook for retrieving the addresses of mail recipients. A mail transfer agent programcan use it to retrieve mail routing information. And a Java calendar program can useit to retrieve user preference settings.) Applications can share the commoninfrastructure provided by the directory. This sharing makes applications that aredeployed across the system, and even the network, more coherent and manageable(For example, printer configuration and mail routing information can be stored in thedirectory so that it can be replicated and distributed for use by all printer-related andmail-related applications and services) In addition to using the directory in thetraditional way, applications can also use it as a repository for objects that is to storeand retrieve objects (For example, a print client program should be able to look up aprinter object from the directory and send a data stream to the printer object forprinting.)

As a conclusion, naming and directory services play a vital role in intranets and theInternet by providing network-wide sharing of a variety of information about users,machines, networks, services, and applications. Finding resources is of particularimportance in large-scale enterprise environments, where the applications maydepend on services provided by applications written by other groups in otherdepartments. A well-designed naming infrastructure makes such projects possible -and the lack of one makes them impossible.

3.2.3.1 Ranking of Technologies Weighting factors are devised to measure the relative importance of the differentcriteria with respect to the knowledge repository. In the following table, all thetechnologies mentioned above are presented with respect to the evaluation criteria(with their associated weighting factors).

Criteria Weightingfactor JDBC JNDI

1. Support for heterogeneousenvironments High Yes Yes

2. Persistence Low - -

57



3. Security High Yes Yes

4. Load-balancing High Yes Yes

5. Preservation of existing ITinvestments High Yes Yes

6. Maturity High Yes Yes

7. Industry support High Yes Yes

8. Time to market Low - -

9. Reusability Low - -

10. Modularity Low - -

11. High availability High Yes Yes

12. Scalability and Adaptabilityto change Low - -

13. Total cost of ownership High Yes Yes

14. Maintainability High Yes Yes

15.Splitting presentation logicfrom business and datalogic (N-tier Architecture)

Low - -

3.2.4 Comparison of JavaServer Pages (JSP) and Microsoft ActiveServer Pages (ASP) Technologies

At first glance, these technologies have many similarities because both are designedto create interactive pages as part of a Web-based application. To a certain degree,both enable developers to separate programming logic from page design through theuse of components that are called from the page itself. And both provide analternative to creating CGI scripts that make page development and deploymenteasier and faster.

In many ways, the biggest difference between JSP and ASP technologies lies in theapproach to the software design itself. JSP technology is designed to be bothplatform and server independent, created with input from a broader community oftool, server, and database vendors. In contrast, ASP is a Microsoft technology thatrelies primarily on Microsoft technologies.

Instead of being tied to a single platform or vendor, JSP technology can run on anyWeb server and is supported by a wide variety of tools from multiple vendors.Because it uses ActiveX controls for its components, ASP technology is basicallyrestricted to Microsoft Windows-based platforms. Offered primarily as a feature ofMicrosoft IIS, ASP technology does not work easily on a broader range of Webservers because ActiveX objects are platform specific. Although ASP technology isavailable on other platforms through third-party porting products, to accesscomponents and interact with other services, the ActiveX objects must be present onthe selected platform. If not present, a bridge to a platform supporting them isrequired.

Because Sun developed JSP technology using the Java Community Process, as wellas Apache development process, JSP API has undoubtedly benefited - and willcontinue to benefit - from the input of this extended community. In contrast, ASPtechnology is a specifically Microsoft initiative, developed in a proprietary process.

58



JSP technology provides a flexible, open choice that works with a wide variety ofvendor tools and reflects industry input and collaboration.

From developer's perspective, both ASP and JSP technologies let developersseparate content generation from layout by accessing components from the page.ASP supports the COM model, while JSP technology provides components based onJavaBeans technology or JSP tags.

The first difference apparent to any page author is the JSP tags themselves. Whileboth ASP and JSP use a combination of tags and scripting to create dynamic Webpages, JSP technology enables developers to extend the JSP tags available. JSPdevelopers can create custom tag libraries, so page authors can access morefunctionality using XML-like tags and depend less on scripting. With custom tags,developers can shield page authors from the complexities of page creation logic andextend key functions to a broader range of authors.

Regarding reusability across platforms, JSP components (Enterprise JavaBeans,JavaBeans, or custom JSP tags) are reusable across platforms. An EnterpriseJavaBean component accessing legacy databases can serve distributed systems onboth UNIX and Microsoft Windows platforms. And the tag extension capability of JSPtechnology gives developers an easy, XML-like interface for sharing packagedfunctionality with page designers throughout the enterprise. This component-basedmodel speeds application development because it enables developers to build quickprototype applications using lightweight subcomponents, then integrate additionalfunctionality as it becomes available, and to leverage work done elsewhere in theorganization and encapsulate it in a JavaBean or Enterprise JavaBean component.

JSP technology uses the Java language for scripting, while ASP pages use MicrosoftVBScript or JScript. The Java language is a mature, powerful, and scalableprogramming language that provides many benefits over the interpreted Basic-basedscripting languages. Because they use Java technology and are compiled into Javaservlets, JSP pages provide a gateway to the entire suite of server-side Javalibraries for HTTP-aware applications. Furthermore, Java language helps protectagainst system crashes, while ASP applications on Windows NT systems aresusceptible to crashing. It also helps in the area of memory management byproviding protection against memory leaks and pointer-related bugs that can slowapplication deployment. Additionally, JSP provides the robust exception handlingnecessary for real-world applications.

Applications using JSP technology are easier to maintain over time than ASP-basedapplications. Scripting languages are fine for small applications, but do not scale wellto manage large, complex applications. Because the Java language is structured, itis easier to build and maintain large, modular applications with it. JSP technology'semphasis on components over scripting makes it easier to revise content withoutaffecting logic, or revise logic without changing content. The Enterprise JavaBeansarchitecture encapsulates the enterprise logic, such as database access, security,and transaction integrity, and isolates it from the application itself. Because JSPtechnology is an open, cross-platform architecture, Web servers, platforms, andother components can be easily upgraded or switched without affecting JSP-basedapplications. This makes JSP suitable for real-world Web applications, whereconstant change and growth is the norm.

As part of J2EE, JSP pages have access to all J2EE components, includingJavaBeans and Enterprise JavaBeans components and Java servlets. JSP pageshave access to all of the standard J2EE services. Through J2EE, JSP pages can

59



interact with enterprise systems in many ways. J2EE supports two CORBA-compliant technologies: Java IDL and RMI-IIOP. With Enterprise JavaBeanstechnology, JSP pages can access databases using high-level, object-relationalmappings.

Finally, because JSP technology was developed through the Java CommunityProcess, it has wide support from tool, Web server and application server vendors.

Table 1 Comparing JavaServer Pages (JSP) and Microsoft Active Server Pages (ASP)Technologies

ASP Technology JSP Technology

Web Server Microsoft IIS or PersonalWeb Server

Any Web server, includingApache, Netscape, and IIS

PlatformsMicrosoft Windows(Accessing other platformsrequires third-party ASPporting products.)

Most popular platforms,including the Solaris OperatingEnvironment, MicrosoftWindows, Mac OS, Linux, andother UNIX platformimplementations

Reusable, Cross-PlatformComponents No JavaBeans, Enterprise

JavaBeans, custom JSP tags

Security Against SystemCrashes No Yes

Memory Leak Protection No Yes

Scripting Language VBScript, Jscript Java

Customizable Tags No Yes

Compatible with LegacyDatabases Yes (COM) Yes (using JDBC API)

Ability to Integrate withData Sources

Works with any ODBC-compliant database

Works with any ODBC- andJDBC technology-compliantdatabase

Components COM componentsJavaBeans, EnterpriseJavaBeans, or extensible JSPtags

Extensive Tool Support Yes Yes

3.2.5 Comparison between CORBA and Microsoft Distributed(DCOM) Technologies

DCOM is an application-level protocol for object-oriented remote procedure calls(RPCs) and is useful for distributed, component-based systems of all types. It is ageneric protocol layered on the distributed computing environment (DCE) RPCspecification and facilitates the construction of task-specific communication protocolsthrough features. DCOM extends the Component Object Model (COM) to supportcommunication among objects on different computers-on a LAN, a WAN, or eventhe Internet. With DCOM, an application can be distributed at locations that make themost sense to customer and to the application. Because DCOM is a seamlessevolution of COM, developers can leverage their existing investment in COM-based

60



applications, components, tools, and knowledge to move into the world of standards-based distributed computing. DCOM handles low-level details of network protocolsso developers can focus on their real business: providing great solutions to theircustomers.

Both middleware technologies provide integration frameworks for object-based,distributed client/server development. As such, both technologies provide full supportfor component distribution. The key remaining difference lies in support for cross-platform interoperability.

Historically, CORBA has focused on enterprise-wide interoperable solutions,whereas many of the underlying technologies that make up DCOM have focused onthe desktop. Since 1989, CORBA has followed the path of developing thearchitecture first and then the implementation. Microsoft, on the other hand, followsthe opposite path of “build first, then architect.” Unfortunately, CORBA’s “architectfirst” distinction does not necessarily hold with the vendors of ORB products. As aresult, ORB vendors often provide services that are not in full compliance with theCORBA specification.

From the outset, CORBA has concentrated on providing an open architecture tosupport interoperability with both existing and new technologies. As evidence, neitherJava nor DCOM were defined at the time CORBA was originally specified; however,significant progress has been made toward integrating these into the standard. Thisis a testament to open nature of the CORBA reference architecture and thecollaborative nature of the OMG as a standards body.

DCOM has approached distribution and interoperability as an afterthought. This isevident in the way that DCOM has evolved from DDE to OLE to OLE2 to ActiveX andso on. However, this makes DCOM’s significance as a limited platform middlewareno less important. The often-cited problem with this approach is disruption toprevious iterations of technology and lack of interoperability.

Finally, CORBA has traditionally been heavily concentrated toward the mixedplatform server domain. The recent collaborations with Java have given CORBAproducts a way to realize support for the client tier also. With ActiveX, DCOMincorporates both client-side and server-side features. The homogenous nature ofthe desktop has given DCOM less motivation for cross-platform support. With NT’smaturation in the middle-tier, DCOM will most likely continue this trend.

As a conclusion, CORBA continues to be seen as the middleware of choice whereenterprise systems are made up of a wide variety of languages, platforms, andoperating systems. Although DCOM is rapidly evolving into a viable middleware forNT platforms, it has yet to become practicable for real-world, heterogeneousenterprise environments.

3.2.6 Comparison of Microsoft Transaction Server (MTS) and EJBMicrosoft Transaction Server (MTS), based on the Component Object Model(COM) that is the middleware component model for Windows NT, is used forcreating scalable, transactional, multi-user and secure enterprise-level server sidecomponents. MTS provides a surrogate for in-process server-side components. MTScan also be defined as a component-based programming model. An MTScomponent is a type of COM component that executes in the MTS run-timeenvironment. MTS supports building enterprise applications using ready-made MTS

61



components and allows you to "plug and work" with off-the-shelf MTS componentsdeveloped by component developers. Just as a COM component can be modeled onthe basis of interfaces and their implementation, MTS enforces modeling based onthe component's state and behavior. MTS, through the COM infrastructure, handlescommunication between components using DCOM. This allows MTS to expose itscomponents to Windows applications from anywhere on the net or the web. As longas you are only running on Windows NT, MTS components can be deployed on topof existing transaction processing systems including traditional transactionprocessing monitors, web servers, database servers, application servers, etc.Legacy system integration with non-Windows systems and MTS is achieved usingthe COM Transaction Integrator (COM-TI) technology. Also, it is important to realizethat MTS is a stateless component model, whose components are always packagedas an in-proc DLL. Since they are composed of COM objects, MTS components canbe implemented in a variety of different languages including C++, Java, ObjectPascal (Delphi), Visual Basic etc.

MTS EJB

Language supportMTS supports Java, C++,C, Visual Basic, Delphi, andpractically any otherdevelopment language.

EJB supports platform-independent Javaprogramming language.

Platform support MTS runs only on NT.

EJB can run on anyplatform. Implementationsare currently available onWindows 95, NT, AS/400,and many flavors of Unix.EJB implementations can befind for almost everyoperating system.

Client supportMTS supports ActiveXclients on Win32, WinCE,Internet Explorer, and IISActive Server Pages.

EJB supports Java clientson any platform throughRMI, CORBA clients on anyplatform through IIOP, andWeb clients throughservlets, Java Server Pages,or similar Web extensions.At least one EJB serverimplementation (WebLogic)supports ActiveX clients.

Portability MTS components can runonly in MTS.

EJB components can beported to any EJB-compliantapplication server.

FlexibilityEJB allows developers to override any EJB automaticservice, including transactions, security, statemanagement, and persistence. MTS doesn’t.

62



Type of objects

MTS views all objects asstateless transient objects.A new object is created foreach user and for eachmethod call.

EJB supports both transientand persistent objects(Transient objects, calledsession beans, can bedefined as either statelessor stateful. State-lesssession beans are treatedexactly like MTScomponents.) No code isrequired within the object tosave the state.

Persistence MTS doesn’t supportpersistent objects.

EJB persistent objects arecalled entity beans.

Transactions EJB transactions are more versatile and simpler to usethan MTS.

As a conclusion, the architectures of MTS and EJB provide mechanisms fordeveloping distributed enterprise components. Though the mechanisms that theyemploy to achieve their objective may be different, the approach each of them takeis more or less similar. But, EJB technology model delivers benefits that address themost pressing concerns of enterprise development teams. EJB server-sidecomponent model simplifies development of middleware components that aretransactional, scalable, and portable. EJB servers reduce the complexity ofdeveloping middleware by providing automatic support for middleware services suchas transactions, security, database connectivity, and more. These include reducedtime-to-market for mission-critical applications, effortless scalability and portability,reduced reliance on hard to find develop/designer skill sets, and an overall increasein developer/designer productivity. EJB technology reduces the cost of developingenterprise-scale applications, while protecting an organization's existing investmentin IT resources. And because EJB technology is based on the Java programminglanguage, components can be deployed on any platform and operating system thatsupports the EJB standard, and any operating system.

63



4 ConclusionsThis aim of this deliverable was to:

• Present and justify the IRIS approach for design aid;

• Provide a first view of the conceptual, functional and technical levels of the IRISdesign aid architecture;

The first objective was addressed by a brief presentation of the need for the IRISDSE and a discussion regarding the IRIS DSE position into the landscape of currentdesign aid tools, in reference to end-user and designer needs. Section 2 overviewedthe breadth of related work (which is presented in detail in other IRIS deliverables,mainly D0301int (Review of guidelines and standards for accessibility to Internet-based services) and D0302int (User models for accessibility and enrolment of peoplewith special needs) and will be further enhanced in terms of D0501int (Review ofdirectory services design approaches and technologies) and D0601int (Review ofdirectory services design approaches and technologies)) and illustrated the aspectsand the manner by which this work has started to be adopted, implemented andextended.

Furthermore the positioning of the IRIS DSE in the context of other relevantinitiatives originating from other fora was made. It is identified that, at the businesslevel, IRIS does not directly compete with large IT vendors of Web developmentsoftware (e.g. such as Microsoft, or Macromedia) and tools because IRIS is notbuilding a classical Web development environment or tool, although there is somedegree of overlapping. The IRIS design support environment focuses onfunctionalities that are not typical of classic development tools and therefore can actsynergistically with existing Web development environments and tools in order toprovide ‘design for all’ assistance to Internet designers.

The presentation of the IRIS architecture was made at three levels of abstraction:conceptual, functional and technical. The deliverable presented a first view on theseissues: the work in terms of other workpackages is not yet finished and their input isnot finalized. The final view of the IRIS DSE architecture will be documented inD0402 (Architectural design of design aid environment). However this first view is avery important step in the project, as it will provide the initiating point of work on theIRIS approach for design aid, architecture and technology.

At the conceptual level, the emphasis has been on to discussing the essence of theIRIS DSE, its relationship with other basic elements of its environment and itsoriginating basic concepts. The IRIS Design Support Environment can be defined asan organized set of methods, tools, guidelines, software applications, provided viathe Internet to all designers in order to support the design of web applications /services for all users based on user modeling. The IRIS design support environmentis a new element in a typical design process, where a designer aims to understand adesign problem and produce a Web product with the use of a (set of) Webdevelopment tool(s). The need for the design support environment is created fromthe observation that the designer is engaged to solve a design problem that requiresa ‘Design for All’ approach, which cannot be offered by existing Web developmenttools.

At the functional level, a first view of the IRIS DSE functional architecture waspresented. The presentation was made in terms of domains (a set of functionalcomponents that have a similar purpose) and functional components (a concrete (set

64



of) component(s) that perform a specific function). The architecture identifies threebasic domains: interaction, design support and ‘Design for all’ knowledge. For eachdomain, the top level functional components have been identified and discussed in amanner independent of technology. This work however, is work in progress: thefunctional components identified so far will be revisited during project developmentsand external evaluations according to the project workplan.

At the technical level, an overview and discussion of existing services architecturesand technologies was made in order to identify the basic technologies to be used perfunctional domain. This discussion compared three possible service architecturesupon a number of technical issues: a) Java 2 Enterprise Edition, b) MicrosoftWindows DNA and c) Java 2 Enterprise edition with COM support and secondly, at alower level of abstraction the criteria for technology selection were identified and anumber of state of the art technologies were evaluated according to these criteria.The main results of the technical discussion are as follows.

JSP/Servlets technologies provide an attractive alternative to other types of dynamicweb scripting/programming that offer platform independence, enhancedperformance, separation of logic from display, ease of administration, extensibilityinto the enterprise and most importantly, ease of use. Java and XML are a naturalmatch for the creation of applications that exploit the web of information wheredifferent classes of clients consume and generate information that is exchangedbetween different servers that run on varied system platforms.

Although DCOM is rapidly evolving into a viable middleware for NT platforms, it hasyet to become practicable for real-world, heterogeneous enterprise environments.Therefore, CORBA continues to be seen as the middleware of choice whereenterprise systems are made up of a wide variety of languages, platforms, andoperating systems.

JTA and JTS allow application servers built on the Java 2 Platform, EnterpriseEdition to take the burden of transaction management off of the componentdeveloper. Developers can define the transactional properties of EnterpriseJavaBeans technology based components during design or deployment usingdeclarative statements in the deployment descriptor. The application server takesover the transaction management responsibilities.SOAP has been developed to solve an old problem that arises when developingapplications for the Internet: interoperability. It facilitates accessing objects andservices on remote servers in a platform-independent manner. In order tointeroperate across the Internet both the client and server need to understand eachother’s security types and trusts, service deployment schemas, and implementationdetails, and the same platform language. A major design goal for SOAP is simplicityand extensibility. The client sends a request to a server to invoke an object, and theserver sends back the results. The messages themselves are formatted in XML, andencapsulated in HTTP protocol messages. SOAP works with the existing Internetinfrastructure. It is not needed to make any special configurations on any of routers,firewalls, or proxy servers for SOAP to work.

The EJB architecture provides mechanisms for developing distributed enterprisecomponents. This model delivers benefits that address the most pressing concernsof enterprise development teams. EJB server-side component model simplifiesdevelopment of middleware components that are transactional, scalable, andportable. EJB servers reduce the complexity of developing middleware by providingautomatic support for middleware services such as transactions, security, database

65



connectivity, and more. These include reduced time-to-market for mission-criticalapplications, effortless scalability and portability, reduced reliance on hard to finddevelop/designer skill sets, and an overall increase in developer/designerproductivity. EJB technology reduces the cost of developing enterprise-scaleapplications, while protecting an organization's existing investment in IT resources.And because EJB technology is based on the Java programming language,components can be deployed on any platform and operating system that supportsthe EJB standard, and any operating system.

JDBC provides cross-DBMS connectivity to a wide range of SQL databases, andprovides access to other tabular data sources, such as spreadsheets or flat files.The JDBC API allows developers/designers to take advantage of the Java platform'scapabilities for industrial strength, cross-platform applications that require access toenterprise data. With a JDBC technology-enabled driver, a developer/designer caneasily connect all corporate data even in a heterogeneous environment.

Naming and directory services play a vital role in intranets and the Internet byproviding network-wide sharing of a variety of information about users, machines,networks, services, and applications. Finding resources is of particular importance inlarge-scale enterprise environments, where the applications may depend on servicesprovided by applications written by other groups in other departments.

66



5 APPENDIX A: An in depth examination of technicalcomponents considered for IRIS DSE system

5.1 J2EE Platform OverviewThe J2EE platform represents a single standard for implementing and deployingenterprise applications. The J2EE platform has been designed through an openprocess, engaging a range of enterprise computing vendors, to ensure that it meetsthe widest possible range of enterprise application requirements.

The J2EE platform provides a multitier distributed application model. This means thatthe various parts of an application can run on different devices. The J2EEarchitecture defines a client tier, a middle tier (consisting of one or more subtiers),and a backend tier providing services of existing information systems. The client tiersupports a variety of client types, both outside and inside of corporate firewalls. Themiddle tier supports client services through Web containers in the Web tier andsupports business logic component services through Enterprise JavaBeans (EJB)containers in the EJB tier. The enterprise information system (EIS) tier supportsaccess to existing information systems by means of standard APIs.

5.1.1 Container-Based Component Management Central to the J2EE component-based development model is the notion ofcontainers. Containers are standardized runtime environments that provide specificcomponent services. Components can expect these services to be available on anyJ2EE platform from any vendor. For example, all J2EE Web containers provideruntime support for responding to client requests, performing request timeprocessing (such as invoking JSP or servlet behavior), and returning results to theclient. All EJB containers provide automated support for transaction and life cyclemanagement of EJB components, as well as bean lookup and other services.Containers also provide standardized access to enterprise information systems; forexample, providing RDBMS access through the JDBC API.

While the J2EE specification defines the component containers that must besupported, it doesn't specify or restrict the configuration of these containers. Thus,both container types can run on a single platform, Web containers can live on oneplatform and EJB containers on another, or a J2EE platform can be made up ofmultiple containers on multiple platforms.

5.1.2 Support for Client Components The J2EE client tier provides support for a variety of client types, both within theenterprise firewall and outside. Clients can be offered through Web browsers byusing plain HTML pages, dynamic HTML generated with JavaServer Pages (JSP)technology, or Java applets. Clients can also be offered as stand-alone Javalanguage applications. J2EE clients are assumed to access the middle tier primarilyusing Web standards, namely HTTP, HTML, and XML.

To support more complex user interactions, it may be necessary to providefunctionality directly in the client tier. This functionality is typically implemented asJavaBeans components that interact with the service in the middle tier via servlets.Client-tier JavaBeans components would typically be provided by the service as anapplet that is downloaded automatically into a user's browser. To eliminate problems

67



caused by old or non-standard versions of the Java virtual machine in a user'sbrowser, the J2EE application model provides special support for automaticallydownloading and installing the Java Plug-in.

Client-tier beans can also be contained in a stand-alone application client written inthe Java programming language. In this case, the enterprise would typically makeoperating system specific installation programs for the client available for users todownload via their browsers. Users execute the installation file and are then ready toaccess the service. Since Java technology programs are portable across allenvironments, the service need only maintain a single version of the client program.Although the client program itself is portable, installation of the Java technologyclient typically requires OS-specific code. There are several commercial tools thatautomate the generation of these OS-specific installation programs.

5.1.3 Support for Business Logic Components In the J2EE platform, middle-tier business logic is implemented in the middle tier asEnterprise JavaBeans components (also referred to as enterprise beans). Enterprisebeans allow the component or application developer to concentrate on the businesslogic while the complexities of delivering a reliable, scalable service are handled bythe EJB server.

The J2EE platform and EJB architecture have complementary goals. The EJBcomponent model is the backbone of the J2EE programming model. The J2EEplatform complements the EJB specification by:

• Fully specifying the APIs that an enterprise bean developer can use toimplement enterprise beans.

• Defining the larger, distributed programming environment in whichenterprise beans are used as business logic components.

5.1.4 Support for the J2EE Standard The J2EE standard is defined through a set of related specifications, key amongthese the J2EE specification, the EJB specification, the Servlet specification, and theJSP specification. Together, these specifications define the architecture described inthis discussion. In addition to the specifications, several other offerings are availableto support the J2EE standard, including the J2EE Compatibility Test Suite and theJ2EE SDK. The J2EE Compatibility Test Suite (CTS) helps maximize the portabilityof applications by validating the specification compliance of a J2EE platform product.

The J2EE SDK is intended to achieve several goals. First, it provides an operationaldefinition of the J2EE platform, used by vendors as the "gold standard" to determinewhat their product must do under a particular set of application circumstances. It canbe used by developers to verify the portability of an application. And it is used as thestandard platform for running the J2EE Compatibility Test Suite.

Another important role for the J2EE SDK is to provide the developer community witha freely available implementation of the J2EE platform to help expedite adoption ofthe J2EE standard. Although it is not a commercial product and its licensing termsprohibit its commercial use, the J2EE SDK is freely available in binary form to use indeveloping application demos and prototypes. The J2EE SDK is also available insource form.

68



The J2EE specifications have, by design, set the platform-compatibility-bar at a levelthat's relatively easy to clear. Owing to the collaborative way in which the platformspecifications have been developed, it was deemed important to give platformvendors plenty of opportunity to supply implementations of the J2EE platform.Obvious and unreasonable implementation hurdles were avoided. For example,there are no restrictions on vendors adding value to J2EE products by supportingservices not defined in the specifications.

It should therefore not be surprising that J2EE component portability is primarily afunction of the dependency a component has on the underlying container.Components using a vendor-specific feature that falls outside of the J2EErequirements may have limitations in the area of portability. The J2EE specificationsdo however spell out a base set of capabilities that a component can count on.Hence, there is a minimum cross-container portability that an application should beable to achieve. Needless to say, an application developer expecting to deploy on aspecific vendor implementation of the J2EE platform, should be able to do so acrossa wide range of operating systems and hardware architectures.

5.1.5 J2EE Platform Benefits With a set of features designed specifically to expedite the process of distributedapplication development, the J2EE platform offers several benefits:• Simplified architecture and development • Scalability to meet demand variations • Integration with existing information systems • Choices of servers, tools, components • Flexible security model

5.1.6 Simplified Architecture and Development The J2EE platform supports a simplified, component-based development model.Because it's based on the Java programming language and the Java 2 Platform,Standard Edition (J2SE platform), this model offers “Write Once, Run Anywhere”portability, supported by any server product that conforms to the J2EE standard.

The component-based J2EE development model can enhance applicationdevelopment productivity in a number of ways.

Maps easily to application functionality: Component-based application modelsmap easily and flexibly to the functionality desired from an application. The J2EEplatform provides a variety of ways to configure the architecture of an application,depending on such things as client types required, level of access required to datasources, and other considerations. Component-based design also simplifiesapplication maintenance, since components can be updated and replacedindependently--new functionality can be shimmed into existing applications simply byupdating selected components.

Enables assembly- and deploy-time behaviors: Components can expect theavailability of standard services in the runtime environment, and can be dynamicallyconnected to other components providing well-defined interfaces. As a result, manyapplication behaviors can be configured at the time of application assembly ordeployment, without any recoding required. Component developers can

69



communicate their requirements to application deployers through specific settings.Tools can automate this process to further expedite development.

Supports division of labour: Components help divide the labour of applicationdevelopment among specific skill sets, enabling each member of a developmentteam to focus on his or her ability. Thus, JSP templates can be created by graphicdesigners, their behavior by Java programming language coders, business logic bydomain experts, and application assembly and deployment by the appropriate teammembers. This division of labour also helps expedite application maintenance. Forexample, the user interface is the most dynamic part of many applications,particularly on the Web. With the J2EE platform, graphic designers can tweak thelook and feel of JSP-based user interface components without the need forprogrammer intervention.

A number of generic roles are discussed in the J2EE specifications, includingApplication Component Provider, Application Assembler, and Application Deployer.On some development teams, one or two people may perform all these roles, whileon others, these tasks may be further subdivided into more specific skill sets (suchas user interface designers, programmers, and so on).

5.1.7 Scales Easily J2EE containers provide a mechanism that supports simplified scaling of distributedapplications, without requiring any effort on the part of the application developmentteam.

Because J2EE containers provide components with transaction support, databaseconnections, life cycle management, and other features that influence performance,they can be designed to provide scalability in these areas. For example, by providingdatabase connection pooling, containers can ensure that clients will have access todata quickly.

Because the J2EE specifications allow server providers freedom to configurecontainers to run on multiple systems, Web containers can be implemented toperform automatic load balancing as the demand for a particular applicationfluctuates.

5.1.8 Integrating Existing Enterprise Information Systems The J2EE platform, together with the J2SE platform, includes a number of industrystandard APIs for access to existing enterprise information systems. Basic access tothese systems is provided by the following APIs:

• JDBC is the API for accessing relational data from Java.

• The Java Transaction API (JTA) is the API for managing and coordinatingtransactions across heterogeneous enterprise information systems.

• The Java Naming and Directory Interface (JNDI) is the API for accessinginformation in enterprise name and directory services.

• The Java Message Service (JMS) is the API for sending and receivingmessages via enterprise messaging systems like IBM MQ Series andTIBCO Rendezvous.

• JavaMail is the API for sending and receiving email.

• Java IDL is the API for calling CORBA services.

70



In addition, specialized access to enterprise resource planning and mainframesystems such as IBM's CICS and IMS will be provided in future versions of J2EEthrough the Connector architecture. Since each of these systems is highly complexand specialized, they each require unique tools and support to ensure utmostsimplicity to application developers. As J2EE evolves, enterprise beans will be ableto combine the use of connector access objects and service APIs with middle-tierbusiness logic to accomplish their business functions.

5.1.9 Choice of Servers, Tools, and Components The J2EE standard and J2EE brand are central to creating a marketplace forservers, tools, and components. The J2EE brand on a server product ensures thekind of ubiquity that's fundamental to the goals of the J2EE platform. In addition,J2EE standards ensure a lively marketplace for tools and components.

A range of server choices: Application development organizations can expectJ2EE branded platforms from a variety of vendors, providing a range of choices inhardware platforms, operating systems, and server configurations. This ensures thatbusinesses get a choice of servers appropriate to the strategic purpose of theapplications they need.

Designed for tool support: Both EJB and JSP components are designed to bemanipulated by graphical development tools, and to allow automating many of theapplication development tasks traditionally requiring the ability to write and debugcode. Both J2EE server providers and third-party tool developers can develop toolsthat conform to J2EE standards and support various application development tasksand styles. Application developers get a choice of tools to manipulate and assemblecomponents, and individual team members may choose tools that suit their specificrequirements best.

A marketplace for components: Component-based design ensures that manytypes of behavior can be standardized, packaged, and reused by any J2EEapplication. Component vendors will provide a variety of off-the-shelf componentsolutions, including accounting beans, user interface templates, and even verticalmarket functionality of interest in specific industries. Application architects get achoice of standardized components to handle common or specialized tasks.

The J2EE standard and associated branding programming ensure that solutions arecompatible. By setting the stage for freedom of choice, J2EE makes it possible todevelop with confidence that the value of your investment will be protected.

5.1.10Simplified, Unified Security Model The J2EE security model is designed to support single sign-on access to applicationservices. Component developers can specify the security requirements of acomponent at the method level, to ensure that only users with appropriatepermissions can access specific data operations. While the EJB and Java ServletAPIs both provide mechanisms for building security checks into code, the basicmechanism for matching users with roles (groups of users having specificpermissions) is performed entirely at application deployment time. This provides bothgreater flexibility and better security control.

71



5.2 Web Server

5.2.1 IntroductionIn general, Web servers serve content over the Internet using the Hyper TextMarkup Language (HTML). The Web server accepts requests from client-side useragents, such as Web browsers, and then returns the appropriate HTML documents,images etc. A number of server-side technologies can be used to increase the powerof the server beyond its ability to deliver standard HTML pages. These include CGIscripts, server-side includes, SSL security, JavaServer Pages, PHP and ActiveServer Pages (ASPs).

5.2.2 Apache ProjectThe Apache Project is a collaborative software development effort aimed at creatinga robust, commercial-grade, full featured, and freely-available source codeimplementation of an HTTP (Web) server. The project is jointly managed by ofvolunteers located around the world, using the Internet and the Web tocommunicate, plan, and develop the server and its related documentation. Inaddition, hundreds of users have contributed ideas, code, and documentation to theproject. There is a core group of contributors that was formed from the projectfounders and is augmented from time to time when core members nominateoutstanding contributors and the rest of the core members agree. The core groupfocus is more on "business" issues and limited-circulation things like securityproblems than on mainstream code development. The term "The Apache Group"technically refers to this core of project contributors.

The Apache project is an effort to develop and maintain an open-source HTTPserver for various modern desktop and server operating systems, such as UNIX andWindows NT. The goal of this project is to provide a secure, efficient and extensibleserver that provides HTTP services in sync with the current HTTP standards.

5.2.3 Apache HTTP ServerThe Apache HTTP server is a powerful, flexible, HTTP/1.1 compliant web server. Itimplements the latest protocols, including HTTP/1.1 (RFC2616).It’s highly configurable and extensible with third-party modules and can becustomized by writing “modules” using the Apache module API. It provides fullsource code and comes with an unrestrictive license and is actively being developedand encourages user feedback through new ideas, bug reports and patches. It runson Windows NT/9x, Netware 5.x, OS/2, and most versions of Unix, as well asseveral other operating systems.In addition, it implements many frequently requested features, including:

• DBM databases for authentication. Allows you to easily set up password-protected pages with enormous numbers of authorized users, withoutbogging down the server.

• Customized responses to errors and problems. Allows you to set up files,or even CGI scripts, which are returned by the server in response to errorsand problems, e.g. setup a script to intercept 500 Server Errors and performon-the-fly diagnostics for both users and the administrator.

72



• Multiple DirectoryIndex directives. • Unlimited flexible URL rewriting and aliasing. Apache has no fixed limit on

the numbers of Aliases and Redirects that may be declared in theconfiguration files. In addition, a powerful rewriting engine can be used tosolve most URL manipulation problems.

• Content negotiation i.e. the ability to automatically serve clients of varyingsophistication and HTML level compliance, with documents which offer thebest representation of information that the client is capable of accepting.

• Virtual Hosts. A much requested feature, sometimes known as multi-homedservers. This allows the server to distinguish between requests made todifferent IP addresses or names (mapped to the same machine). Apachealso offers dynamically configurable mass-virtual hosting.

• Configurable Reliable Piped Logs. You can configure Apache to generatelogs in the format that you want. In addition, on most Unix architectures,Apache can send log files to a pipe, allowing for log rotation, hit filtering, real-time splitting of multiple vhosts into separate logs, and asynchronous DNSresolving on the fly.

5.2.4 Features and performancesApache version 1.1 and above comes with a proxy module. If compiled in, this willmake Apache act as a caching-proxy server.

"Multiviews" is the general name given to the Apache server's ability to providelanguage-specific document variants in response to a request. This is documentedquite thoroughly in the content negotiation description page.

SSL (Secure Socket Layer) data transport requires encryption, and manygovernments have restrictions upon the import, export, and use of encryptiontechnology. If Apache included SSL in the base package, its distribution wouldinvolve all sorts of legal and bureaucratic issues, and it would no longer be freelyavailable. Also, some of the technology required to talk to current clients using SSLis patented by RSA Data Security, who restricts its use without a license. Some SSLimplementations of Apache are available, however.

Apache does not include a search engine, but there are many good commercial andfree search engines which can be used easily with Apache.

Apache has been shown to be substantially faster, more stable, and more fullfeatured than many other web servers. Apache is run on sites that get millions of hitsper day, and they have experienced no performance difficulties.

Apache is run on over 6 million Internet servers (as of February 2000). It has beentested thoroughly by both developers and users. The Apache Group maintainsrigorous standards before releasing new versions of their server. When bugs doshow up, they release patches and new versions as soon as they are available.

Apache has been the most popular Web server on the Internet since April of 1996.The February 2001 Netcraft Web Server Survey2 found that 60% of the web sites onthe Internet are using Apache (around 62% if Apache derivatives are included), thusmaking it more widely used than all other web servers combined.

2 The Netcraft Web Server Survey is a survey of Web Server software usage on Internet connectedcomputers.

73



5.3 Web Applications and Web Containers

5.3.1 IntroductionIn the J2EE lexicon, a Web application is a collection of HTML/XML documents,Web components (servlets and JSP pages), and other resources in either a directorystructure or archived format known as a Web ARchive (WAR) file. A Web applicationis located on a central server and provides service to a variety of clients.

A Web container is a runtime environment for a Web application; a Web applicationruns within a Web container of a Web server. A Web container provides Webcomponents with a naming context and life cycle management. Some Web serversmay also provide more services, such as security, concurrency, transactions, andswapping to secondary storage. A Web server may work with an EJB server toprovide such services. A Web server need not be located on the same machine asthe EJB server. In some cases, a Web container may communicate with other Webcontainers.

5.3.2 JavaServer Pages (JSP) and Java Servlet TechnologiesJavaServer Pages (JSP) technology allows web developers and designers torapidly develop and easily maintain, information-rich, dynamic web pages thatleverage existing business systems. As part of the Java family, JSP technologyenables rapid development of web-based applications that are platform independent.JavaServer Pages technology separates the user interface from content generationenabling designers to change the overall page layout without altering the underlyingdynamic content.

Java Servlet technology provides web developers with a simple, consistentmechanism for extending the functionality of a web server and for accessing existingbusiness systems. A servlet can almost be thought of as an applet that runs on theserver side -- without a face. Java servlets have made many web applicationspossible. Servlets have access to the entire family of Java APIs, including the JDBCAPI to access enterprise databases. Servlets can also access a library of HTTP-specific calls and receive all the benefits of the mature Java language, includingportability, performance, reusability, and crash protection.

5.3.3 Tomcat as JSP/Servlet ContainerTomcat is the Reference Implementation for the Java Servlet 2.2 and JavaServerPages 1.1 Technologies.

Developed under the Apache license in an open and participatory environment,Tomcat is intended to be a collaboration of the best-of-breed developers fromaround the world. Sun will continue responsibility for the Servlet API and JavaServerPages specifications, which are being developed under the Java CommunityProcess.

Tomcat is a servlet container and JavaServer Pages implementation. It may be usedeither stand alone or, even better, in conjunction with several popular web servers: -Apache, version 1.3 or later - Microsoft Internet Information Server, version 4.0 orlater - Microsoft Personal Web Server, version 4.0 or later - Netscape EnterpriseServer, version 3.0 or later.

74



5.3.4 Conjunction With ApacheTomcat currently supports three modes of execution. Although it is entirely possibleto have Tomcat serve both static and dynamic document provision needs, there areseveral reasons not to use Tomcat this way. With respect to the Apache web server:

• Tomcat is not as fast as Apache when it comes to static pages.

• Tomcat is not as configurable as Apache.

• Tomcat is not as robust as Apache.

• Tomcat may not address many sites' need for functionality found only inApache modules (e.g. Perl, PHP, etc.).

For all these reasons it is recommended that real-world sites use an industrial-strength web server, such as Apache, for serving static content, and use Tomcat asa Servlet/JSP add-on.

In a nutshell a web server is waiting for requests. When these requests arrive theserver does whatever is needed to serve the requests by providing the necessarycontent. Adding Tomcat to the mix may somewhat change this behaviour. Now theweb server needs to perform the following:

• Before the first request can be served, Apache needs to load a web serveradapter (how Tomcat will communicate with Apache) library and initialise it.

• When a request arrives, Apache needs to check and see if it belongs to aservlet, if so it needs to let the adapter take the request and handle it.

• We'd like Apache to handle our static content, such as images and htmldocuments, and to forward all requests for dynamic content to Tomcat.

75



5.4 XML Processing

5.4.1 IntroductionXML (Extensible Markup Language) is the preferred technology in many information-transfer scenarios because of its ability to encode information in a way that is easy toread, process, and generate. Java is an ideal companion to XML: both languagesshare a similar historical background (C++, SGML); both have goals of simplicity,portability, and flexibility; and both continue to be developed in groups that involveindustry, development community and academia (W3C, JCP).

Not surprisingly Java is the overwhelmingly preferred language for server and client-side XML application development. The portability and extensibility of both XML andJava make them the ideal choice for the flexibility and wide availability requirementsof this new web.

5.4.2 Java API for XML Parsing (JAXP) 1.1 RequirementsJAXP includes the industry standard SAX and DOM APIs, as well as a pluggabilityAPI that allows SAX and DOM parsers and XSLT transform engines to be pluggedinto the framework, and allows applications to find parsers that support the featuresneeded by the application.

All J2EE products must meet the JAXP conformance requirements and must provideat least one SAX 2 parser, at least one DOM 2 parser, and at least one XSLTtransform engine. There must be a SAX parser or parsers that support allcombinations of validation modes and namespace support. There must be a DOMparser or parsers that support all combinations of validation modes and namespacesupport.

5.4.3 Apache XML ProjectThe goals of the Apache XML Project are:

• To provide commercial-quality standards-based XML solutions that aredeveloped in an open and cooperative fashion,

• To provide feedback to standards bodies (such as IETF and W3C) from animplementation perspective, and

• To be a focus for XML-related activities within Apache projects

The Apache XML Project currently consists of seven sub-projects, each focused ona different aspect of XML: Xerces (XML parsers in Java, C++, with Perl and COMbindings), Xalan (XSLT stylesheet processors, in Java and C++), Cocoon (XML-based web publishing, in Java), FOP (XSL formatting objects, in Java), Xang (Rapiddevelopment of dynamic server pages, in JavaScript), SOAP - Simple Object AccessProtocol, Batik - A Java based toolkit for Scalable Vector Graphics (SVG) andCrimson - A Java XML parser derived from the Sun Project X Parser.

5.4.4 Cocoon: XML-based Web PublishingCocoon is a powerful framework for XML web publishing that brings a whole newworld of abstraction and ease to consolidated web site creation, and managementbased on the XML paradigm and related technologies.

76



Cocoon is a 100% pure Java publishing framework that relies on new W3Ctechnologies (such as DOM, XML, and XSL) to provide web content.

The new Cocoon paradigm is based on the fact that document content, style andlogic are often created by different individuals or working groups. Cocoon aims for acomplete separation of the three layers, allowing the three layers to beindependently designed, created and managed, reducing management overhead,increasing work reuse and reducing time to market.

Cocoon offers a different way of working, allowing content, logic and style to beseparated out into different XML files, and uses XSL transformation capabilities tomerge them.

Even if the most common use of Cocoon is the automatic creation of HTML throughthe processing of statically or dynamically generated XML files, Cocoon is also ableto perform more sophisticated formatting, such as XSL:FO rendering to PDF files,client-dependent transformations such as WML formatting for WAP-enabled devices,or direct XML serving to XML and XSL aware clients.

The Cocoon model allows web sites to be highly structured and well-designed,reducing duplication efforts and site management costs by allowing differentpresentations of the same data depending on the requesting client (HTML clients,PDF clients, WML clients) and separating out different contexts with differentrequirements, skills and capacities.

To do this, the Cocoon model divides the development of web content into threeseparate levels:

• XML creation - The XML file is created by the content owners. They do notrequire specific knowledge on how the XML content is further processed -they only need to know about the particular chosen "DTD" or tag set for theirstage in the process. (As one would expect from a fully generic XMLframework, DTDs are not required in Cocoon, but can be used and validatedagainst). This layer is always performed by humans directly, through normaltext editors or XML-aware tools/editors.

• XML processing - The requested XML file is processed and the logiccontained in its logicsheet(s) is applied. Unlike other dynamic contentgenerators, the logic is separated from the content file.

• XSL rendering - The created document is then rendered by applying an XSLstylesheet to it and formatting it to the specified resource type (HTML, PDF,XML, WML, XHTML, etc.)

The main concern remains processing complexity: the kind of operations required toprocess the document layers are complex and not designed for real-time operationon the server side. For this reason, Cocoon is designed to be a page compiler fordynamic pages, trying to hardcode, whenever possible, those layers in precompiledbinary code coupled with an adaptive and memory-wise cache system for both staticand dynamic pages. A key development goal is performance improvement of bothprocessing subsystems as well as the creation and testing of special cache systems.

5.4.5 Cocoon and Apache TomcatTo make Cocoon work with Tomcat, a context to Tomcat that describes to Tomcathow to load Cocoon files must be added. A context in Tomcat describes to Tomcathow and when to load a particular servlet and Cocoon is one such servlet. Then

77



Apache must be told to send certain requests to Tomcat (and consequentlyCocoon). Finally, the .xml files to be served by Cocoon must be provided.

78



5.5 Enterprise JavaBeans (EJB) Container

5.5.1 IntroductionIn a multitier J2EE application, the EJB-tier hosts application-specific business logicand system-level services such as transaction management, concurrency control,and security. EJB technology provides a distributed component model that enablesdevelopers to focus on solving business problems while relying on the J2EE platformto handle complex system-level issues. This separation of concerns allows rapiddevelopment of scalable, accessible, and highly secure applications. In the J2EEprogramming model, EJB components are a fundamental link between presentationcomponents hosted by the Web tier and business-critical data and systemsmaintained in the enterprise information system tier.

5.5.2 EJB containerEnterprise Java Beans run within a container, which controls the beans and providesthem with system services. The services a container offers are:

• Transactions. The EJB specification provides transactional semantics forcomponents, allowing the component developer to specify transactionalproperties of components.

• Security.

• Remote access (RMI).

• Life cycle management.

• Database connection pooling. To provide efficient access to databases it isbetter to make clients share database connections – this means a newdatabase connection doesn't have to be opened for every client request.Instead there is a pool of a number of connections, and when a client wants adatabase connection it gets an already opened connection to use so there isno start-up time. When the client doesn't need the connection any more, it'sreturned to the pool so that it can be reused. The EJB server handles thispooling.

5.5.3 JBoss/Server As EJB ContainerThe JBoss/Server is an Open Source, standards-compliant, EJB application serverimplemented in 100% Pure Java, as is our full product suite. The JBoss communityof over 500 developers worldwide is working to deliver the full range of J2EE tools asthe premier Enterprise Java application server for the Java 2 Enterprise Edition(J2EE) platform. The JBoss/Server and complement of products are delivered undera public license.

JBoss 2.0 also standardizes on JMX (Java Management eXtension) to offerstandard interfaces to the management of its components as well as the applicationsdeployed on it.

JBoss is an implementation of the EJB 1.1 (and parts of 2.0) specification, that is, itis a server and container for EJB. In this it is similar to Sun's “J2SDK EnterpriseEdition” (J2EE), but JBoss is much more single-minded than J2EE. The JBoss coreserver provides only an EJB server; it does not include support for JSP, SSL, and all

79



the other protocols that the Sun product can handle. Because of its small memoryfootprint, JBoss starts up about 10 times faster than Sun’s J2EE. There is a built-inSQL database server for handling persistent beans, and this starts up automaticallywith the server (J2EE ships with the CloudScape SQL server, which has to bestarted separately).

One of the nicest features of JBoss is its support for “hot” deployment. What thismeans is that deploying a Bean is a simple as copying its JAR file into thedeployment directory. If this is done while the Bean is already loaded, JBossautomatically unloads it, then loads the new version. Contrast this with the rigmarolethat other J2EE server makes us go through. JBoss is distributed under the LGPL,which means that it's free, even for commercial work, and is likely to remain thatway. You get no support, of course.

Being both open and standards-compliant, JBoss/Server supports both EJB SessionBeans and Entity Beans.

5.5.4 Modular Server DesignModularly developed from the ground up, the JBoss server and container arecompletely implemented using component-based plug-ins.

The modularisation effort is supported by the use of JMX, the Java ManagementeXtension API. Using JMX, industry-standard interfaces help us manage bothJBoss/Server components and the applications deployed on it. Ease of use is still thenumber one priority here at JBoss.org, and JBoss/Server 2.0 sets a new standard forboth modular, plug-in design and ease of server and application management.

This high degree of modularity benefits the application developer in several ways.The already tight code can be further trimmed down in support of applications thatmust have a very small footprint. For example, if EJB passivation is unnecessary inyour application, simply take the feature out of the server. However, if you laterdecide to deploy the same application under an Application Service Provider (ASP)model, simply enable the server's passivation feature for that Web-baseddeployment.

5.5.5 Features That Speed DevelopmentIn addition to the fact that JBoss/Server is an EJB 1.1 compliant application server,there are some innovative features that make that server a pleasure to use.Specifically two features make application deployment extremely easy to perform,saving developers much time and effort. In a phrase, JBoss/Server takes the gruntwork out of EJB application development.

First there's dynamically, runtime-generated stub and skeleton classes. In manycommercial EJB servers the generation of these classes must be performed in anadditional step prior to deployment. It goes without saying that this extra steprequires additional developer overhead, adding significant time to each change-compile-deploy cycle. By generating stub and skeleton classes on the fly,JBoss/Server takes at least several seconds, and perhaps minutes, off of eachdeployment. As an added benefit, the method used by JBoss/Server to accomplishthis time- and effort-savings feature also saves memory and other server resourcessince only a single server object supports every deployed Enterprise JavaBeanscomponent.

80



A second time- and effort-savings feature is automatic hot deploy and redeploy.Some of the top commercial EJB servers require you to "bounce" the server in orderto successfully deploy your application changes. However, JBoss/Server allows youto deploy new applications and redeploy existing applications without stopping andrestarting the server. In fact, the feature is as easy as copying your newly built EJBJAR file to the server deployment directory where JBoss/Server picks up the newfile, automatically undeploys the old JAR (if any) and deploys the new JAR withinseconds. This feature definitely provides the benefit of slicing minutes off of eachchange-compile-deploy cycle.

5.5.6 Tomcat and JBoss - A Full J2EE StackThe JBoss organization wants to deliver a complete J2EE based product to themarket. The JBoss organization decided to integrate the Tomcat engine stack with arunning version of JBoss in a single VM.

Now, they run optimised stacks the JSP/Servlet engine talks natively with the EJBengine resulting in dramatic speed increases. Without the optimisation the invocationis through the network layer. With the optimised layers the invocation is native, inVM,within the same stack of APIs.

5.5.7 Data SourcesOne of the most common requirements is to create one or more data sources foryour EJBs. A data source for CMP entity beans must be created, and it is therecommended way to interact with a database for BMP entity beans and sessionbeans.

JBoss data sources provide database connection pooling. This means that whenapplication closes a connection, it is not really closed, just returned to the "ready"state. The next time your application requests a database connection, it may reusethe same connection. This saves you the overhead of opening new databaseconnections for every request, and since normal web applications use connectionsvery often but for a very short period of time, the savings can be significant.However, there are some new issues raised such as the fact that a databaseconnection that is left unused in the pool for a long period of time may timeout. TheJBoss pools have a number of configuration parameters to address issues like this.

JBoss supports any database with a JDBC driver. Pure java drivers (type 3 or type 4)are recommended, and it is specifically suggested not to use the JDBC-ODBCbridge (type 1).

The mappings available for CMP that have been tested extensively includePostgreSQL, InstantDB, Hypersonic SQL, Oracle 7, Oracle 8, Sybase, DB2, andInterBase. Additional contributed mappings include PointBase, SOLID, mySQL, MSSQL Server, and DB2/400.

81



5.6 Interoperability AssuranceThe interoperability of the variety of services that the IRIS DSE will support can beensured by the use of the Simple Object Access Protocol and the Web ServicesDescription Language.

5.6.1 SOAPSimple Object Access Protocol (SOAP) is a lightweight protocol for exchange ofinformation in a decentralized, distributed environment. It is an XML based protocolthat consists of three parts: an envelope that defines a framework for describingwhat is in a message and how to process it, a set of encoding rules for expressinginstances of application-defined datatypes, and a convention for representing remoteprocedure calls and responses. SOAP can potentially be used in combination with avariety of other protocols.

SOAP has been developed to solve an old problem that arises when developingapplications for the Internet: interoperability. It facilitates accessing objects andservices on remote servers in a platform-independent manner. In order tointeroperate across the Internet both the client and server need to understand eachother’s security types and trusts, service deployment schemas, and implementationdetails, and the same platform language (e.g. COM to COM, ORB to ORB, EJB toEJB, etc.).

SOAP is simple. The client sends a request to a server to invoke an object, and theserver sends back the results. The messages themselves are formatted in XML, andencapsulated in HTTP protocol messages. SOAP works with the existing Internetinfrastructure. You don't need to make any special accommodations on any of yourrouters, firewalls, or proxy servers for SOAP to work.

SOAP client requests are encapsulated within an HTTP POST (or M-POST) packet.The following example is taken from the Internet-draft specification(http://www.w3.org/TR/SOAP):

POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body></SOAP-ENV:Envelope>

The first four lines here are standard HTTP.

82



The XML code is straightforward, as well: the elements Envelope and Body provide ageneric payload packaging mechanism; the element <GetLastTradePrice> containsan element called <symbol>, which contains a stock ticker symbol. The purpose ofthis request is obvious: get the last trading price for a specific stock -- in this caseDisney (DIS).

The program that sends this message needs to understand only how to format aSOAP request: the HTTP header formation, and the XML formats needed to framethe request. In this case, the program knows this is the way to format a request for astock price. The HTTP server receiving this message knows that it is a SOAPmessage because it recognizes the HTTP header SOAPMethodName; it then doessomething to deliver or process the message appropriately. For example, a typicalresponse may be:

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body>

Based on the already industry widely accepted IETF HTTP standard and W3C XMLstandard, SOAP bridges the gap between competing object RPC technologies andprovides a light-weight messaging format that works with any operating system, anyprogramming language, and any platform.

In order to utilize a service on a remote server using SOAP, a program needs tounderstand what the remote service is capable of and not understanding the remoteservice's implementation (platform specific information). SOAP provides a way toquery the remote service and learn about its capabilities, such as how it representsdata types and commands.

5.6.2 Apache SOAPApache SOAP is an open-source implementation of the SOAP v1.1 and SOAPMessages with Attachments specifications in Java. Apache SOAP is developed bythe Apache SOAP community.

Apache SOAP can be used as a client library to invoke SOAP services availableelsewhere or as a server-side tool to implement SOAP accessible services. As aclient library it provides an API for invoking SOAP RPC services as well as an API forsending and receiving SOAP messages. As a mechanism to write new RPCaccessible services or message accessible services, it expects to be hosted by aservlet container (such as Apache Tomcat, for example). While the codebase can beextended to support non-HTTP transports, the provided code only has limitedsupport for non-HTTP transports (specifically, only for SMTP).

83



5.6.2.1 Requirements & LimitationsApache SOAP has the following requirements:

• Java 1.1 or higher, and a servlet engine supporting version 2.1 or higher ofthe Java Servlet API

• A JAXP compatible, namespace aware XML parser • JavaMail (mail.jar) and the JavaBeans Activation Framework (activation.jar) • XMI encoding requires use of Java 1.2.2 and XML4J 2.0.15. A classpath

system variable must have xerces.jar first and then xml4j.jar next in thatorder.

• Implementing services in scripting languages requires the use of BeanScripting Framework.

• SSL (HTTPS) support requires Java 1.2.1 or later and the Java SecureSocket Extension.

• The SMTP transport requires the SMTP and POP3 Bean Suites. The following features of the SOAP v1.1 specification are not currently supported:

• encodingStyle attribute must have only one encoding style given (see section4.1.1 of the spec)

• mustUnderstand attribute support - only supports checking for and rejectingrequests that require mustUnderstand checking

• root attribute • actor attribute and SOAP intermediaries • does not use multi-ref accessors during serialization

The following limitations on SOAP Messages with Attachments currently exist:• The document base URI is not picked up from the multipart's Content-

Location header. • Support for relative URIs in Content-Location headers is limited to

concatenating the document base URI to the relative URI. • The provided SMTP transport does not support multipart messages. • Server-side RPC methods have no way to add attachments to the response

other than via the return object. Messaging methods can do this already.

5.7 Web Services Description Language (WSDL) / Webservices

Web services using XML standards is a new paradigm in the way B2B collaborationsare modeled. It provides a conceptual and architectural foundation, which can beimplemented using a variety of platforms and products. Today, developers can usethe Java 2 Enterprise Edition (J2EE) to build XML-based web services. They canleverage existing J2EE technologies to build a complete and fully interoperable webservice that complies with XML standards.

Web Services can be described as follows:

84



• Web Services are self-contained, modular applications that can be described,published, located, and invoked over a network, generally, the World WideWeb.

• The Web Services architecture describes three roles: service provider,service requester and service broker; and three basic operations: publish,find and bind. A network component can play any or all of these roles.

• Two separate documents describe Web Services: A Well-Defined Service(WDS) document describes non-operational service information, such asservice category, service description, and expiration date, as well as businessinformation about the service provider, such as company name, address, andcontact information. A Network-Accessible Service Specification Language(NASSL) document describes operational information about the service, suchas service interface, implementation details, access protocol, and contactendpoints.

• A Web Services architecture implementation should allow for incrementalsecurity and quality of service models facilitated by configuring a set ofenvironmental prerequisites (for example, authentication mechanism, billing,and so on) to control and manage the interactions.

• Web Services can be dynamically composed into applications stemming fromcapabilities-based look-up at runtime, instead of the traditional static binding.The dynamic nature of the collaborations allow the implementations to beplatform- and programming language-neutral, and communicationsmechanism-independent, while creating innovative products, processes, andvalue chains.

5.7.1 WSDLAs communications protocols and message formats are standardized in the webcommunity, it becomes increasingly possible and important to be able to describethe communications in some structured way. WSDL addresses this need by definingan XML grammar for describing network services as collections of communicationendpoints capable of exchanging messages. WSDL service definitions providedocumentation for distributed systems and serve as a recipe for automating thedetails involved in applications communication.

5.7.2 UDDI (Universal Description, Discovery, and Integration)Before a partner can make a web service call to a business, it must first locate abusiness with the service needed, discover the call interface and semantics, andwrite or configure software on their end to collaborate with the service. Therefore avehicle to publish web services is required.

UDDI is a project aimed towards providers and seekers of web services. Themembers of the UDDI Project operate a web service called the UDDI BusinessRegistry (UBR), which is global, public directory of businesses and services. Webservice providers can register and describe their services in the UBR. Users canquery the UBR to discover web services and to locate information needed tointeroperate with the services.

UDDI is a mechanism to direct systems looking for certain services to documentationthat describes them. UDDI contains the standard “white pages”- type business

85



search and “yellow pages”- type topical search, as well as a “green pages”- typeservice type search. It is this “green pages” search that will allow a developer to findall services that match a particular service type.

UDDI utilizes SOAP messaging (typically XML/ HTTP) for publishing, editing,browsing, and searching for information in a registry. It also contains an XMLschema for encapsulating the various types of data that may be returned or sent tothe registry service.

86



6 ReferencesAnne Thomas, Comparing MTS and EJB, December 1998, Available at: http://java.sun.com/

Anne Thomas, Java™ 2 Platform, Enteprise Edition, Ensuring Consistency, Portability andInteroperability, Prepared for Sun Microsystems Inc., June 1999, Available at:http://java.sun.com/

Apache SOAP: http://xml.apache.org/soap/index.html

Apache: http://www.netcraft.com/survey/, http://httpd.apache.org/

Avison and Fitzgerald (1994) Information Systems Development: Methodologies,Techniques and Tools, The Alden Press, Oxford.

Bill Shannon, Java™ 2 Platform Enterprise Edition Specification, v1.3, Proposed Final Draft3, Sun Microsystems Inc., March 30, 2001, Available at: http://java.sun.com/

Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Frystyk Nielsen, H.,Thatte, S. and Winer, D. (2000). Simple Object Access Protocol (SOAP) 1.1, W3C Note08 May 2000. Available at: http://www.w3.org/TR/SOAP/

Chisholm, W. Vanderheiden, G. Jacobs, I. (editors) (1999) Web Content AccessibilityGuidelines (WCAG), W3C Recommendation 5 May 1999.

Christensen, E., Curbera, F., Meredith, G. and Weerawarana, S. (2001). Web ServicesDescription Language (WSDL) 1.1, W3C Note 15 March 2001. Available at:http://www.w3.org/TR/wsdl

Cocoon: http://xml.apache.org/, http://xml.apache.org/cocoon/index.html

Comparing JavaServer Pages™ Technology and Microsoft Active Server Pages, An Analysisof Functionality, Sun Microsystems Inc., 1999, Available at: http://java.sun.com/

CORBA vs. DCOM: Solutions for the Enterprise, META Group Consulting, March 20, 1998,Available at: http://java.sun.com/

Ed Roman and Rickard Öberg, The Business Benefits of EJB and J2EE Technologies overCOM+ and Windows DNA, Prepared for Sun Microsystems Inc., The MiddlewareCompany December 1999, Available at: http://java.sun.com/

Ed Roman and Rickard Öberg, The Technical Benefits of EJB and J2EE Technologies overCOM+ and Windows DNA, Prepared for Sun Microsystems Inc., The MiddlewareCompany December 1999, Available at: http://java.sun.com/

EJB: http://java.sun.com/j2ee/products/ejb/

ENTERPRISE JAVABEANS™ TECHNOLOGY, A BUSINESS BENEFITS ANALYSIS,Zona Research Inc., Available at: http://java.sun.com/

J2EE Blueprints: http://java.sun.com/j2ee/blueprints/

J2EE Platform and CORBA: http://java.sun.com/j2ee/corba/

J2EE Platform and XML: http://java.sun.com/xml/index.html

J2EE: http://java.sun.com/j2ee/

Java accessibility: http://java.sun.com/j2se/1.3/docs/guide/access/, http://www-3.ibm.com/able/accessjava.html, http://www-3.ibm.com/able/snsjavag.html,

87



http://www.sun.com/access/articles/JavaUniverseOverview.html, http://www.sun.com/access/articles/java.access.support.html, http://www.sun.com/access/articlesoftwarep-caped/

Jboss: http://www.jboss.org/, http://www.jboss.org/documentation/HTML/index.html

JDBC: http://java.sun.com/j2ee/products/jdbc/

JNDI: http://java.sun.com/j2ee/products/jndi/

JSP: http://java.sun.com/j2ee/products/jsp/

JTS and JTA: http://java.sun.com/j2ee/transactions.html

Koutsabasis, P. Darzentas, J. S. Abascal, J. Spyrou, T. Darzentas J. (2001) DesigningInternet-based Systems and Services for All: Problems and Solutions, to appear inProceedings of 1st International Conference on Universal Access in Human-ComputerInteraction, to be held on August 5-10, 2001 New Orleans, LA, USA.

Servlets: http://java.sun.com/j2ee/products/servlet/

Shubic, M. (1979) Computer and Modelling, in Dertouzos and Moses, 1979

SOAP: http://www.w3.org/TR/SOAP/, http://xml.apache.org/soap/, http://www.alphaworks.ibm.com/tech/soap4j, http://www.xmethods.net, http://www.webservices.org, http://www.ibm.com/developerworksoftwareebservices/, http://msdn.microsoft.com/soap, http://www.develop.com/soap, http://www.soapware.org/

Stephanidis, C. Salvendy, G. Akoumianakis, D. Arnold, A. Bevan, N. Dardailler, D. Emiliani,P. L. Iakovidis, I. Jenkins, P. Karshmer, A. Korn, P. Marcus, A. Murphy, H.Oppermann, C. Stary, C. Tamura, H. Tscheligi, M. Ueda, H. Weber, G. Ziegler, J.(1999, November) Toward an Information Society for All: HCI challenges and R&Drecommendations, International Journal of Human-Computer Interaction, Vol. 11(1),1999, pp. 1-28.

Tomcat: http://jakarta.apache.org/tomcat/

Treviranus, J. McCathieNevile, C. Jacobs, I. Richards, J. (editors) (2000) Authoring ToolAccessibility Guidelines 1.0 (ATAG), W3C Recommendation, 3 February 2000.

UDI: http://www.uddi.org/

Velasco, C.A.; and Verelst, T. (1999) Raising awareness among designers of accessibilityissues. Interfaces Vol. 41, pp. 6-8.

Velasco, C.A.; and Verelst, T. (2001a) Training, Verification and Evaluation of Guidelines.In Inclusive Design Guidelines for HCI, Nicolle, C. and Abascal, J. (eds.), Taylor andFrancis (London).

Velasco, C.A. (2001b) Evaluation and training on accessibility guidelines; to appear inProceedings of 1st International Conference on Universal Access in Human-ComputerInteraction, August 5-10, 2001 New Orleans, LA, USA.

88



Velasco, C. A. (2001c) Using XSLT to render accessible documents to the Web, Proceedingsof CSUN Conference 2001, 19-24 March 2001,http://www.csun.edu/cod/conf2001/proceedings/0130velasco.html

89

Documents

IST-2000-26211 Project IRIS D0401 Recommendations for ... · IST-2000-26211 Project IRIS D0401 Recommendations for Design Aid Approaches and Technologies Contractual Date of Delivery