IST-2000-26211 Project IRIS D0401 Recommendations for Design Aid

Document Sample
IST-2000-26211 Project IRIS D0401 Recommendations for Design Aid Powered By Docstoc
					                           IST-2000-26211 Project IRIS
                                             D0401
                         Recommendations for
                Design Aid Approaches and Technologies
Contractual Date of Delivery to the 31/06/01
CEC:
Actual Date of Delivery to the CEC:                (Slipped one month later, according               to
                                                   contingency plan submitted to EC)
Editor (s):                                        Vladica Stojic, Nikos Floratos (ED)

Contributor (s):                                   Elias Lizardos, Nikitas Tsopelas(ED), John
                                                   Darzentas, Thomas Spyrou, Jenny Darzentas,
                                                   Panayiotis  Koutsabasis  (Aegean),   Carlos
                                                   Velasco, 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 ‘Design
for All’ (‘DfA’). This task is still work in progress for the project; however, an overview of this work
is given in order to position the IRIS DSE into the landscape of other relevant initiatives. The IRIS
approach for identifying and formulating the designer support architecture is described at three
levels: conceptual, functional and technical. The IRIS conceptual architecture presents the basic
concepts of the IRIS design support environment including the basic entities acting in the system
and the purpose of their participation. The IRIS functional architecture presents the basic
functions of the design support environment in manner independent of technology. The IRIS
technical architecture presents the technological design of the design support environment
according to the constraints imposed by the conceptual and functional analysis, as well as from
the 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 : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




                            IST-2000-26211 Project IRIS
                        Recommendations for
               Design Aid Approaches and Technologies

VERSION DETAILS
Version:            F

Date:               15/08/01

Circulation:        Consortium

Status:             Final

DOCUMENT HISTORY
Version     Version     Respon-           Description
            date        sible
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 extended
                                          discussion 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 REVIEW
Version     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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




Executive Summary
Deliverable D0401 presents and justifies the IRIS approach for the Design Support
Environment design (DSE) aid and provides a first view of the conceptual, functional
and technical architectural elements of the IRIS design support environment (IRIS
DSE). In order to justify this approach for design aid, there is a need to review a wide
range of work related to ‘Design for All’ (‘DfA’). This task is still in progress for the
project; however, an overview of this work is given in order to position the IRIS DSE
work into the landscape of other relevant initiatives. The IRIS approach for identifying
and formulating the designer support architecture is described at three levels:
conceptual, functional and technical. The IRIS conceptual architecture presents the
basic concepts of the IRIS design support environment including the basic entities
acting in the system and the purpose of their participation. The IRIS functional
architecture presents the basic functions of the design support environment in
manner independent of technology. The IRIS technical architecture presents the
technological design of the design support environment according to the constraints
imposed by the conceptual and functional analysis, as well as from the current state
of the art on Internet technologies, recommendations and tools. D0401 provides a
first view on these multifarious issues: the work in terms of other workpackages is
not yet finished and their input is not finalized. The final view of these issues will be
documented in D0402 (Architectural design of design aid environment). However this
first view is a very important step in the project, as it will provide the initiating point of
work on the IRIS approach for design aid, architecture and technology.




                                                                                          3
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




                                               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
W ORKPACKAGE:.................................................................................................................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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




       3.1.4Criteria for the selection of final IRIS system architecture......................... 38
   3.2Examination of Technologies to Support Deployment of IRIS DSE functional
   modules.................................................................................................................. 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.2.1Ranking of Technologies..................................................................... 54
       3.2.3 DfA Knowledge (Knowledge Repository).................................................. 54
           3.2.3.1Ranking of Technologies..................................................................... 57
       3.2.4Comparison of JavaServer Pages (JSP) and Microsoft Active Server
       Pages (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 DSE
SYSTEM.......................................................................................................................... 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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




       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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




1 Introduction
As 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 design
     support 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, widely
     accessible system;
In order to achieve those objectives the work in WP4 will be informed by the findings
of a number of WPs (Figure 1).

                                                Wp1: Project Management


     Wp2: Requirements of
    people with special needs               Wp4: Design Support
      for Internet Services                    Environment

        Wp3: User and System              Wp5: Design & Development                   Wp8: Electronic Commerce
        Models Specifications                 Directory Services                       service Enhancement and
                                                                                            Demonstration
                                            Wp6: Design & Develop-
                                            ment: Intelligent Agents                    Wp9: Teleworking / On-line
                                                                                     Learning service Enhancement and
                                                                                               Demonstration
                                                   Wp7: Recommendations for
                                                 Enhancements of Internet Services

                                                  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 provide
information on the accessibility and usability problems of existing services in the
areas of electronic commerce and teleworking for people with special needs, which
can contribute to the work of WP4 by identifying areas where specific focus can be
given regarding knowledge that will be incorporated into the design support
environment. WP3 (User and System Models Specifications) will provide insight
considering existing recommendations, standards and tools in the areas of
accessibility, usability, user profiles and modeling. WP4 will incorporate all this work
in its knowledge base and present it to designers of Internet-based services in a
manner suitable to the problem areas they are faced with. WP5 (Design and
Development: Directory Services) and WP6 (Design and Development: Intelligent
Agents) will provide the design of components of the design support environment
while WP7 (Recommendations for Enhancements of Internet-based Services) will
continuously provide external feedback of the work carried out in terms of WP4.


                                                                                                                  8
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




Deliverable D0401 (Design Support Approaches and Technologies) provides a first
view on architectural issues of the IRIS design support environment (IRIS DSE). It
formulates the problem space where IRIS attempts to provide solutions and to which
it is applicable and also elaborates on the entities involved and their corresponding
views and business opportunities (conceptual level); it demonstrates the manner by
which support to designers will be pursued in terms of functional - independent of
technology – design; and also sketches the technical design, that elaborates on
specific technologies and recommendations that will be used. D0401 is a first view
on these multifarious issues: the work in terms of other workpackages is not yet
finished and their input is not finalized. The final view of these issues will be
documented in D0402 (Architectural design of design aid environment). However this
first view is a very important step in the project, as it will provide the baseline of work
on 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 IRIS
    design aid architecture;
In order to justify the IRIS approach for design aid, there is a need to review a wide
range of work related to ‘Design for All’ (‘DfA’). This task is still work in progress for
the project and is being carried out mainly by workpackages 3 (User and system
models specifications), 5 (Directory Services) and 6 (Software Agents).
The IRIS approach for identifying and formulating the designer support architecture
is described at three levels: conceptual, functional and technical. The IRIS
conceptual architecture presents the basic concepts of the IRIS design support
environment including the basic entities acting in the system and the purpose of their
participation. The IRIS functional architecture presents the basic functions of the
design support environment. These functions explain how the system achieves the
goals revealed from the conceptual level. The functional architecture is presented in
a manner, which is independent of technology. Finally,the IRIS technical architecture
presents the technological design of the design support environment. The technical
architecture attempts to provide an implementable solution to the constraints
imposed by the conceptual and functional analysis, as well as from the current state
of the art on Internet technologies, recommendations and tools.




                                                                                       9
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




2 Approaches for Design Aid: Penetration to 'Design
  for All' Concepts
This section briefly presents the need for IRIS DSE and positions the IRIS DSE in
the landscape of current design aid tools, in reference to end-user and designer
needs. In order to demonstrate the need for the IRIS DSE it is important to present
the breadth of related work and illustrate the aspects and the manner by which this
work is to be implemented and extended. Furthermore it is important to position IRIS
development in the context of other relevant initiatives originating from other fora.



2.1 Design for all in ICT - Basic concepts
The term ‘Design for All’ has been widely used in a number of contexts. As
Stephanidis et al (1999) summarise ‘for some individuals, it is considered as a new
politically correct term, referring to efforts intended to introduce “special features” for
“special users” during the design of a product. To others, universal design is a
deeply 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 all
potential users’. Notwithstanding, the fact that there might be dangers inherent in
examining concepts, methods, tools, techniques etc. under such a generic spectrum,
the inclusive, user-centred approach towards product and systems design is
especially appropriate to the context of the IRIS project.
A key element in approaches for design for all is active user participation and
engagement in every phase of product and systems design (Velasco and Verelst,
1999, 2001a, 2001b). However, the achievement of such an engagement and
productive participation is a difficult task to plan, organize and conduct, especially
taking into account that products, systems and services, when referring to the
Internet, 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 new
circumstances and interesting challenges for the designer. A major challenge to be
faced arises from the fact that the incorporation of requirements by diverse user
groups most often results in conflicting or simultaneously interoperable technical
solutions. For example the use of small fonts is not appropriate for users with sight
impairments, thus, in order to design for all, it is important that the system can
provide alternative options and modalities, which are often related to human sensory
cues and modalities.
Furthermore, even if a system supports multiple states and can cover a wide range
of requirements, a given system state may not be at all accessible by users whose
requirements seriously conflict with the given system state, with the consequence
that 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 the
system is configurable regarding its font size, because it is not accessible by them to
begin with, at the given default state. Therefore, besides supporting multimodality, it
has been realised that an approach towards achieving design for all is that of




                                                                                       10
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




designing for system adaptivity, i.e. the system inherent property to trace and
automatically adapt/respond to user requirements.
The IRIS project takes an approach towards user-participatory and adaptive design
of systems and services, which includes diverse user groups from a large number of
European countries. Furthermore within the perspective of active user participation
and adaptive design, emphasis is given in areas relevant to this approach such as
user 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, user
characteristics, preferences, abilities and constraints into product and system design.
This interdisciplinary area of research has produced results both at the level of
conceptual representations and processes and at the level of knowledge and data
representations.
Accessibility has traditionally been associated with disabled and elderly people. This
area has often focused too narrowly on the requirements of disabled and elderly
people, producing solutions that are much customised to the needs of those groups
of people and thus with constrained impact. These types of solutions are often called
assistive technologies. However, the range of different categories of users that may,
at a given time or gradually, be confronted with accessibility problems is far greater
than the population of disabled and elderly users. For example a driver who wants to
access the Web while driving a car has also sensory and cognitive limitations, that
have 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 that
are 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 with
emphasis on functionality rather than aesthetics, making them psychologically
unattractive. Most of all, in the area of ICT, assistive technology solutions have often
fallen behind, becoming obsolete, when mainstream technology moves on. Instead,
disabled and elderly people are interested to ensure that mainstream products are
widely accessible, incorporating their requirements, as much as possible. That is to
say, it is understood that some disabilities may need special equipment to access
technology, but once this is achieved, there should not be further accessibility
problems (Koutsabasis et al, 2001; Velasco, 2001a, 2001b).
Thus, in the context of the IRIS project accessibility is viewed in its widest
perspective. That is, recommendations and tools that are examined are not only
specific 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, this
deliverable is not limited to technical and development issues but reviews work
related to the lifecycle of Internet-based systems design including phases such as
user requirements and evaluation.



2.2 Design for all               recommendations               for Internet-based
    services
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
         IRIS Project IST-2000-26211
         Deliverable number : D0401
         Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




         perspective requires that a wide range of methodologies, methods,
         recommendations, techniques and tools that can provide aid at various phases of the
         design process should be taken into account in an approach towards aiding
         designers 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 selection
         and interpretation of significant strands of work that can be incorporated into the IRIS
         design support environment. This view is presented in many phases of the project.
         An enumeration that represents the empirical, broad and disparate nature of work in
         the 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 are
         not constrained only to these types of systems, can provide useful references to
         designers of Internet-based services at various phases of the design process, such
         as requirements, design, development, evaluation – not necessarily in this order, as
         shown in (Koutsabasis et al, 2001). Unfortunately designers rarely take into account
         the breadth of issues regarding the incorporation of work related to ‘Design for All’
         concepts. Most often, designers focus on work that contributes directly to the
         development and prototyping phases of the design process (Velasco and Verelst,
         1999, 2001a, 2001b).

                                 Work relevant to ‘Design
                                        for All’ concepts                                                       Contribution of work
                                                                                                                  relevant to ‘Design
                                                                                                                for All’ to the design
                      Models of perception,                                                                                    process
Designer Tools at               and action
the Methodology
      level
                         Interaction models


                     Recommendations (e.g.                                                                      Increased, explicit
                     Guidelines, Standards)                                                                      user involvement
                               for usability
      Level of
     abstraction
                     Recommendations (e.g.
                     Guidelines, Standards)
                           for user profiles


                     Recommendations (e.g.               Decreased, implicit
                     Guidelines, Standards)               user involvement
                     for metadata/semantics


                     Recommendations (e.g.
  Designer Tools     Guidelines, Standards)
  at the Technical         for accessibility
        level


                                               …   Requirements    …           Design   …   Development /   …        Evaluation          … Phases of
                                                                                             prototyping                                   the Design
                                                                                                                                           Process



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




                                                                                                                                                 12
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




For example, despite the fact that most of the work on W3C.WAI 1 recommendations
for accessibility can be taken up at the development and evaluation phases of a
design process or methodology, naturally there are aspects of these guidelines that
cannot be automatically implemented by a software compliance test program, but
are left to the designer to decide how they are met. These aspects are usually
ignored. 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 and
deciding upon which recommendations and tools to select and apply. For example,
Stephanidis and Akoumianakis (1999) demonstrate that different engineering
perspectives in the implementation of guidelines can lead to different interpretations
and can influence the quality of the final products.
The effect of this existing, relevant to ‘Design for all’ concepts, work cannot be
strictly 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 these
tools cannot provide formal solutions to assist designer in an automatic manner, user
involvement 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 IRIS
project. This task is the starting point for the development of a framework for aiding
designers to incorporate this work into their methodologies and design processes.
This work, which will be conducted in terms of specific activities and deliverables, will
gradually 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 producing
proposals for recommendations and enhancements, both in terms of specific
commercial IRIS Internet services and demonstrators in the areas of electronic
commerce and teleworking/ education, as well as part of other initiatives. This will
require selections and interpretations, for example in terms of technology,
recommendations, existing tools, etc. These interpretations may be
provided/updated by the industry directly into the IRIS designer aid environment, by
accessing its knowledge base.



2.3 Emerging Specifications Reflecting User Needs
User needs are reflected in a number of specifications / recommendations that have
recently appeared, despite the fact that in some cases the methodology for user
involvement is not clearly provided. In some areas related to ‘Design for All’,
problems have been dealt with specifications that are easily interpretable to technical
solutions, while in other areas further interpretations are required by Internet
designers. In any case, it is true that most of these specifications are quite new and
have not been implemented and tested extensively.
IRIS will make use of emerging recommendations / specifications whenever
possible, while in other cases the project will follow well-established research and
development 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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




fora that currently work on these selections (see also section 3 IRIS Design Support
Environment Technical Architecture). The purpose of listing these selections is
mostly informational and should not be treated as definitive of plans for IRIS
developments. On the contrary, experience shows that in a 30-month project it is
highly probable that some of the selections listed below may become obsolete.
Accessibility. IRIS will apply the W3C WAI guidelines for accessibility of Web
Content and Authoring Tools (Chisholm et al 1999; Treviranus et al, 2000) into
project developments and thereby contribute to further adaptation / extension of this
work. The WAI Web Content Accessibility Guidelines will be applied in all
developments of Internet content: IRIS Website, enhancements of Internet services
and development of the IRIS DSE. The WAI Authoring Tools Accessibility Guidelines
will be applied during the development of the IRIS DSE and the enhancement of the
selected e-commerce service, which includes automated, online design of electronic
shops.
Usability. IRIS will apply well-known methodological approaches for usability testing
and evaluation in terms of user requirements capture and evaluation of selected
Internet services. Furthermore, IRIS will consider the application of related standards
to this work (for a review see D0301int, Review of guidelines and standards for
accessibility to Internet-based services), however, it seems that the application of
usability standards requires extended allocation of resources and requires further
elaborations for the case of Internet usability (D0301int).
User profiling / modeling: IRIS will implement specifications for personal
information profiles that stem out of the LDAP Person specification (for a review see
D0302int (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 information
and is closely watching this area by partners’ participation to W3C and other
collaborative 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 DSE
development. The study of the current user profile infrastructure of selected Internet
services is also work in progress and it is possible that this infrastructure may be
extended to implement the above specifications.
Metadata: IRIS will make use of XML, which is a standard that is general in scope
for metadata design. Furthermore, IRIS will consider the use of other XML-related
specifications such as XSL and XSLT. In addition well-known metadata schemata
such as RDF and Dublin Core will be considered for the metadata design of specific
components of the IRIS DSE, such as the knowledge repository. The suitability of
these recommendations to aspects of ‘Design for All’ (such as promoting
accessibility) 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 work
in terms of concrete specifications / recommendations / standards. However, IRIS
will base its developments on emerging findings from the area of software agents.
This work has been introduced in D0302int (User models for accessibility and
enrolment of people with special needs) and will be analytically presented in
D0601int (Review of directory services design approaches and technologies).




                                                                                   14
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




2.4 Approach for User Requirements in IRIS
As noted above, IRIS will implement, adapt and extend a number of emerging
specifications and recommendations related to Internet accessibility, usability, user
profiles and metadata design. Besides the purposeful synthesis of existing work in
terms of project activities (mainly under workpackages 3, 5 and 6) another important
project activity that influences those adaptations / extensions is that of user
requirements analysis. Currently IRIS WP2 is working on the development of user
requirements that is targeted towards specifying the requirements for accessibility
and enrolment of users with special needs in selected Internet services and thereby
identifying areas of focus for the design and development phases including the
evaluation criteria against which the design aid environment and the enhanced
Internet services will be judged.
The IRIS work on user requirements analysis is guided by the USERFIT
methodological framework which can organise and record information about user
requirements in an operational way and has been developed in terms of TIDE 1062
USER project. The application of the framework will be enhanced by usability and
accessibility evaluations of existing IRIS services in the areas of teleworking and
electronic commerce. This will enable IRIS to have a first set of specific test items in
terms of the Internet services to be enhanced. The usability evaluation is based on
related methods that have been also used for the usability evaluation of GMD’s
BSCW teleworking platform. The accessibility evaluation will be based on W3C’s
WAI accessibility guidelines for both authoring tools and Web content.



2.5 Positioning IRIS in the Current Landscape for Design for
    All Aid
Before formulating and discussing the architecture of the IRIS design support
environment, 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 in
approaches for designer support may consist of: large IT vendors, IT SMEs, the
open software community, specific organizations in the areas of accessibility,
independent consortia and academia. Each player approaches designer support in a
different manner, but of course in some cases these approaches have some
common elements. The approaches taken by each of the above players are different
to 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 above
approaches and attempts to synthesize their findings. The purposeful synthesis of
the wide range of results in the area of ‘Design for all’ is a task at least of the same
importance to the design of another technical solution that would address an aspect
of a specific problem. IRIS contributes to both, by synthesizing and elaborating on
current work on design for all and by adapting/extending this work to selected
Internet services in emerging application areas.
However, it has to be noted that at the business level IRIS will not directly compete
with large IT vendors of Web development software (e.g. such as Microsoft, or
Macromedia) and tools because IRIS is not building a classical Web development
environment or tool, although there is some degree of overlapping. The IRIS design
support environment focuses on functionalities that are not typical of classic
development tools and therefore can act synergistically with existing Web



                                                                                    15
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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



2.6 Describing the Architectural Design of the IRIS Design
    Support Environment
The approach for describing the architectural design of the IRIS DSE is borrowed
from classical information systems analysis and design approaches. The basic
characteristic of those approaches is that they include models, which may operate at
different levels of abstraction. The selection of levels by which a system is defined
depends on the purpose of the investigation and design, however, there is a wide
consensus that there are some ‘natural’ or ‘inherent’ levels upon which a system can
be 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
                        Levels of                 Model
                       Abstraction



                                                 Physical
                                                  Model


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

The conceptual level presents the basic concepts of an information system including
the 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 conceptual
architecture explains what the system composes of at a high level of abstraction.
The conceptual architecture may be presented in different levels from general to
specific.




                                                                                            16
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




The functional level presents the basic functions of the system. These functions
explain how the system achieves the goals revealed from the conceptual level. The
functional architecture is independent of technology. In a similar way with the
conceptual level, the functional level may be presented in different levels from
general to specific.
The technical level presents the technological design of the system. The technical
level attempts to provide an implementable solution to the constraints imposed by
the conceptual and functional analysis, as well as from the current state of the art on
technologies, recommendations and tools.
Regarding the form of presentation of models, these have been categorized into four
distinct types (Shubic 1979): (1) verbal; (2) analytic / mathematical; (3) iconic /
pictorial / schematic and (4) simulation. Avison and Fitzerald (1994) note that ‘the
models of concern in information systems methodologies are almost exclusively of
the third type’, (i.e. iconic / pictorial / schematic) because of the importance of using
models as a means of communication.
IRIS will follow the afore-outlined model for the definition and description of the IRIS
design support environment. The architectural design of the IRIS design support
environment will be discussed at these three levels of abstraction: conceptual
functional and technical. The strength of this approach is that it can enable us to
study a broad range of issues/questions such as: what is the IRIS Design Support
Environment (i.e. conceptual level); who uses it (i.e. conceptual level); in what
contexts may it be used (i.e. conceptual level); what are its basic parts (i.e. functional
level); what are the basic technologies employed (i.e. technical level); how does it
work (i.e. functional and technical level). These issues are discussed in the
remainder of this deliverable.




                                                                                      17
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




1 The IRIS Design Support Environment Concept
This section presents the basic concepts around the IRIS design support
environment. The discussion on the conceptual issues of the IRIS DSE addresses
concerns related to the essence of the IRIS DSE such as: what is the IRIS Design
Support Environment for? what does it do? whom does it serve? The discussion is
structured as follows: firstly the IRIS project concept is overviewed, and secondly
conceptual issues within the IRIS DSE are discussed.



1.1 The IRIS Project Concept
The objectives of the IRIS project are to:
•   Encapsulate into a design aid environment, work on design-for-all tools and
    methods; user modelling theories and methods, including users with special
    needs; guidelines, recommendations and results from work about hypermedia,
    enrolment and accessibility; and
•   Use this environment to redesign and enhance existing services in the areas of
    teleworking / on-line learning and electronic commerce, guided by rigorous user
    testing and evaluation.
IRIS aims to genuinely advance the current scientific and technological state of the
art in the area of accessibility by ensuring that current design-for-all tools and
methods, user modeling theories and methods, design guidelines, recommendations
and results from work about hypermedia, enrolment and accessibility are
encapsulated into a homogeneous design aid environment. The project will formulate
existing knowledge and experience in the area under a generic integrated design aid
environment that supports the designers of Internet services; combine state of the
art technologies (like directory services, metadata and intelligent agents) for
implementing this environment considering and contributing to relevant standards;
validate the concept of the design aid environment by using this to enhance existing
Internet applications and services tested by different groups of users with special
needs.
The basic elements of the IRIS project approach and tasks are shown
diagrammatically in Figure 4 and are discussed in the remainder of this section.




                                                                                   18
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




              Figure 4                              The IRIS project concept.

Designing for all implies a user centred approach in design and starts from the
identification, modelling, specification and automated utilisation of user
characteristics. 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 all
methods, recommendations, results of relevant previous projects and insight
provided 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 and
international groups of users with special needs, relevant to media and translate
these models into technical characteristics of communication channels so that
services may be configured to these characteristics.



                                                                                   19
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




The IRIS design support environment also takes into account existing work in areas
related to design for all such as usability, accessibility, content metadata and user
modelling and profiles. IRIS will identify the suitability of a range of tools and
methods, such as metadata for delivering media and alternating content formats. By
identifying the suitability of such methods and tools, IRIS will have formed a broad
design space, where the aforementioned user models can be translated to a range
of possible selections regarding the design of accessible services. The specification
of user models takes into account relevant recommendations and emerging
standards and specifications in the areas of user enrolment and accessibility in
accordance to the application domains.
The IRIS design support environment will be used by designers in order to enhance
existing Internet services and applications in the selected areas of electronic
commerce and telework / on-line learning. This will be achieved by further
developing existing Internet services in these areas according to the specifications
that will be consolidated mainly by workpackage 4.
During the enhancement of existing services, IT designers will assess the support of
the design aid environment and the extensibility and customisability of design for all
tools. 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 to
their developments.
The evaluation of enhanced Internet services will be user-centered, involving
international associations of people with special needs, who are familiar with ICT and
who will provide insight to various usability and accessibility issues.



1.2 Conceptual Views                    of     the     IRIS      Design         Support
    Environment
This section refers to conceptual views of the IRIS design support environment in
terms of two perspectives. The first is related to the view of the IRIS design support
environment 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 design
support environment relative to other entities either human or artificial. The second
view 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 in
section 5.



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




                                                                                        20
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




   Design a Web
    product for
        All
                              IRIS “DESIGN for ALL” (DfA)
                               SUPPORT ENVIRONMENT

                                                                                Access and
                                                                                   Use




       DESIGNER

                                 WEB DEVELOPMENT
                                     TOOL (S)               WEB PRODUCT




                                                                               ALL USERS


  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 product
with the use of a (set of) Web development tool(s). The need for the design support
environment is created from the observation that the designer is engaged to solve a
design problem that requires a ‘Design for All’ approach, which cannot be offered by
existing Web development tools.
The design problem may be formed in a manner that is independent of the IRIS
design support environment or the Web development tool(s) and that the designer is
familiar with and normally uses for design and development (e.g. in terms of a
generic methodology). The design problem may be communicated with the IRIS
design support environment (via suitable mechanisms and rules) and/or the Web
development tools according to the communication language(s) used.
The ultimate aim of the designer is to produce a Web product, e.g. an Internet
service. For the purposes of the IRIS project there will be developments and
demonstrators in Internet services in the selected areas of teleworking and electronic
commerce. However, the scope of the IRIS design support environment is to provide
assistance to designers at a generic level and support the design process beyond
these domains of application.
The IRIS design support environment may also communicate with Web development
tool(s) and with the Web product that is in design and development phase. This may
happen with various technical solutions, however, it is important that these solutions
are generic and extensible so that they can be taken up and used by vendors of
these development tools. The link between the IRIS design support environment with
Web development tool(s) can enable the IRIS design support environment to monitor
the design process proactively and possibly act in this manner in order to provide
assistance to the designer.
As can be seen from this conceptual level of analysis, the IRIS design support
environment could act synergistically with existing Web development tools with the
purpose of supporting the designer in a generic manner and scope, covering the full


                                                                                             21
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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



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


              interaction

             addresses users        translates user models
             (designers) and          to communication
           external applications           channels
                                                                    ‘Design for All ’
           adapts to user requirements /                              knowledge
                    preferences
                                                                     Synthesizes a wide
                                                                    range of ‘Design for
                                                                      All’ knowledge
                support of the design process

           addresses a wide range     evaluates (the outcomes        extends existing
             of issues within the      of) the design process       design for all tools
              product lifecycle
                                              elicits specific        introduces new
             translates ‘Design for All’    problem situation        tools for ‘Design
              knowledge to applicable         requirements              for All’ aid
                 methods and tools



            Figure 5                                Basic concepts within the IRIS DSE.

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


                                                                                           22
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




preferences and characteristics. This type of proactive adaptation is required in
critical phases of user – system interaction such as user enrolment.
The IRIS DSE will support a wide set of issues within the Internet service design
process. These issues may involve user (designer) instruction, online collaboration
and evaluation of the design process, at least in selected phases of the design
process that may pose difficulties to designers. The IRIS DSE should support the
design process by translating the wide range of ‘Design for All’ knowledge into easily
applicable 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 ‘self
developed’. IRIS developments will include both the creation of new tools and
extensions/adaptations of existing tools.
It needs to be noted that this approach is a first attempt towards defining the basic
concepts of the IRIS DSE. Work related to the review of current work in ‘Design for
All’ mainly conducted by workpackages 3 (User and system models specifications), 5
(Directory Services) and 6 (Software Agents) will enhance this view. This will be
documented in terms of D0402 (Architectural design of design aid environment).




                                                                                   23
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




2 The IRIS Design Support Environment Functional
  Architecture
This section will present the basic functions of the IRIS design support environment
functional architecture. The discussion is made in a manner independent of
technology to ease comprehension and allow for easy uptake of this work by other
fora with similar aims. The presentation of the functional architecture adopts the
terminological conventions: domains and components.
A domain refers to a set of functional components that have a similar purpose. The
purpose of components refers to the functional level of analysis, which may be quite
different at the level of the technical description. For example under the interaction
domain the functional components of ‘user interface’ and ‘software interface’ will be
implemented quite differently.
A functional component refers to a concrete (set of) component(s) and performs a
specific function. Functional components may be further broken down, however, in
this deliverable we mainly refer to ‘top-level’ components.



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




                                                                                   24
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




             Design process                   IRIS Design Support Environment
                                    INTERACTION      DfA SUPPORT       DfA KNOWLEDGE
                                      DOMAIN           DOMAIN              DOMAIN
                  Web
                 Designer
                                       Functional      Functional           Functional
                                      components      components           components




                  WEB
              DEVELOPMENT
                  TOOL




                   WEB                    …               …                   …
                 PRODUCT




    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 a
Web development tool and / or a Web product, while using the IRIS DSE in order to
be assisted towards designing for all. The IRIS DSE:
o   interacts with the designer and/or external applications via the interaction
    domain;
o   provides support to the design process (which involves the designer and other
    applications) via the design support domain; and
o   manages and uses ‘Design for All’ knowledge to pursue the above tasks via the
    corresponding domain.
Each domain may include a number of functional components, which focus to
specific functions. A first set of these functions is presented in the next section.



2.7 IRIS DSE Functional                         Architecture           -     Functional
    Components
A diagrammatic illustration of the IRIS DSE functional architecture is shown in Figure
8 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 of
discussion the identification of detailed functionality flow cannot be made; in other
words, it is envisaged that the components identified at this level of analysis will
provide interfaces that will be available to all other components. A more detailed


                                                                                         25
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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


                      Design process
                                                                                 IRIS DfA Support Environment
                                                        INTERACTION/                     DfA SUPPORT       DESIGN FOR ALL
                                                          INTERFACE                                         KNOWLEDGE
                              Web
                             Designer




                                                                  INTERACTION SUPPORT
                                                                                           TRAINING        METHODOLOGIES/
                                                          USER                                            RECOMMENDATIONS/
                                                         INTERF                                              GUIDELINES/
   MODIFICATION OF       INITIATION OF A NEW               ACE                                                PRACTICES
    AN EXISTING            WEB APPLICATION
    APPLICATION

                                                                                            ONLINE
                                                                                         DEVELOPMENT
                                                                                           SUPPORT
                               WEB
                                                                                                                 USER
                           DEVELOPMENT
                                                                                                           PROFILES/MODELS
                               TOOL



                                                             S/W
                                                          INTERFACE
                                WEB                                                      EVALUATION
                              PRODUCT                                                                       DESIGN FOR ALL
                                                                                                                TOOLS




DfA: Design for All
           Figure 7                            IRIS DSE Functional Architecture - top level components.



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


2.7.1.1 User interface
The user interface of the IRIS DSE will allow users (designers) to have direct access
and use of the IRIS DSE services. The IRIS DSE user interface will be Internet-
based and compliant with WAI Web Content and Authoring Tool Accessibility
Guidelines.
The user interface will provide users (designers) with understandable and navigable
content, which includes not only making the language clear and simple, but also
providing understandable mechanisms for navigating within and between different
pages. Some general principles for user interface design that will be applied during
the IRIS DSE design include:



                                                                                                                             26
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




o   Multimodality: the user interface content should convey essentially the same
    function or purpose as alternative auditory or visual content;
o   Context and orientation information: to help users understand complex pages or
    elements because without orientation information users may not be able to
    understand 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 existing
    information;
o   User feedback: every operation initiated by user will have some kind of
    audio/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 interface
The software interface will provide access to IRIS DSE services to other external
applications (such as Web development tools or Web products) as well as to other
components 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-platform
access to IRIS DSE services. In this way other applications can make use of IRIS
DSE services directly on top of their own user interfaces.


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



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


2.7.2.1 Training
The training component will address the need for designers to be familiar with the
concept of ‘Design for All’ and furthermore, with knowledge that is related to this
concept. Designers have a vague picture of ‘Design for All’ concepts and tools and
usually are not well guided with regard to the deployment of ‘Design for All’ tools
failing 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, not
only in terms of accumulation of resources but furthermore by establishing services


                                                                                   27
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




that can assist designers, if possible in specific problem situations in a context-aware
manner.
The training component will enable the user/designer to post requests to the IRIS
DSE and receive responses such as related topics, articles, drafts, and
recommendations based on the IRIS DSE Knowledge Repository. The training
component will enable the designer to take design decisions and follow necessary
actions 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 Support
The IRIS DSE will provide functions that will allow for generating new Web
applications. It will thus act as a Web authoring tool capable of visually placing and
arranging the available objects/modules or Web components based on accessibility
techniques. Web components will provide preview, guidelines, verification and
validation at the same time. Each designer will have access to online design support
component and any extension of it such as uploading/downloading pages, altering
content etc. and responsibility for the hosting, maintenance and security/integrity of
data. The online design support will be predictive i.e. designers will be self-guided by
this module during the page creation process. It will have intuitive, suggestive and
descriptive (user-friendly) interface toward designers thus providing them with
extensive easy-to-use development environment.
The online development support component will also incorporate reusable
components that may be used in Internet application design and development.
These components will encapsulate business logic of Web applications and will be
deployed and executed in context of application server (component container). The
design of these components will support accessibility in ways such as: the ability to
manipulate the graphical components entirely from the keyboard; the ability to track
events (for example, when a window is opened or when a keyboard or mouse button
is pressed); the ability to query components in order to determine their state (for
example, whether a box is checked or unchecked, and to enumerate the actions that
may be invoked upon them); the ability to synthesize events that cause a change in
the state of the application; the ability to inspect text components directly, to access
both content and text attributes (font, size, colour, style, etc.); the ability to implement
a comprehensive set of keyboard navigation and editing sequences etc.


2.7.2.3 Evaluation
The main objective of the evaluation component is to determine to which degree
aspects of the design process and outcomes (e.g. Web pages) are following ‘Design
for All’ principles (e.g. accessibility, usability, adaptivity, multimodality, etc.). The IRIS
DSE may provide ‘self-developed’ tools or guide the designer to use external tools
for this purpose. The evaluation component will provide guidance to the designer
regarding those aspects and if possible, repair problems that will be identified.
The guidance to designers will be achieved by developing mechanisms that allow for
functions such as reminding, helping and suggesting. The automatic repair of
identified 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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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



2.7.3 DfA Knowledge Domain
The IRIS DfA support environment will require a large amount of DfA knowledge,
which can be either encoded inside the environment or externally available. This
knowledge includes existing methodologies, user requirements and modelling, and
their 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 DfA
knowledge in the form of metadata. These semantics will describe the types of
assistance that each type of knowledge (e.g. recommendation, tutorial,
methodology, case study, etc.) can provide to the designer. The actual material will
be mainly external to the IRIS DSE (e.g. WAI accessibility guidelines are available
on the Web). This will address potential copyright issues. Even self-developed
project knowledge (e.g. extensions to existing recommendations, user requirements
for specific types of applications, etc) may be located externally to the IRIS DSE.


2.7.3.1 Methodologies, Recommendations, Guidelines and Practices
Despite the fact that the usage of the IRIS DSE is independent of the methodology
used by the designer, the DfA knowledge will include issues related to design
methodology. Furthermore the IRIS DSE will include knowledge about
recommendations and specifications for ‘Design for All’. Currently a variety of
recommendations exist that can be of great assistance to designers of Internet
services towards designing for all. Furthermore reference will be made to well known
examples of design cases ranging from (successful or unsuccessful) applications to
simple Web pages or design patterns.


2.7.3.2 User Profiles
The IRIS DSE knowledge repository will incorporate information about users and
designers in the form of user profiles. User profiles will mainly include information
related to users (designers) of the IRIS DSE, however the inclusion of available
models and data for user requirements along with the methodology followed and
context specific information will be considered for inclusion. User (designer) profiles
will include personal profile information and device access information and will be
based on extensions / adaptations and implementations of related specifications (for
a review see D0302int (User models for accessibility and enrolment of people with
special needs).


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


                                                                                   29
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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 WAI
Web site: http://www.w3.org/; Koutsabasis et al, 2001). The IRIS DSE knowledge
repository will take those classifications as a starting point towards the development
of appropriate metadata specifications related to this type of knowledge.


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




                                                                                   30
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




3 IRIS Design                   Support          Environment               Technical
  Architecture
The technical architecture of a system is one of the most important stages at the life
cycle model, which helps system developers at the design and implementation of a
system. In general there are two types of methods that corporations may follow for
the development of their system’s architecture. In the past, corporations were forced
to invent a server-side platform in-house while the modern approach supports the
purchase of a server-side platform from a middleware vendor, re-usable components
from an application vendor and development and management tools from a tools
vendor. Every approach has advantages and disadvantages. The in-house server-
side platform allows the better understanding of business culture and the fast
integration of the new system with the existing infrastructure, but on the other hand
is very expensive as the maintenance costs of a custom middleware solution
increase exponentially, and it becomes necessary to train newly hired personnel on
the proprietary architecture. The vendor server-side platform offers development and
maintenance time decrease in conjunction with greater efficiency through
specialization, but there is always the danger of incompatibility between the
components of the architecture. Our scope in the IRIS project is to ensure the
compatibility between the components of the DSE architecture while at the same
time mitigating the development, improvement and maintenance effort.
Technically, the IRIS DSE can be thought of comprising three layers, namely the
presentation layer, the application layer and the back end layer. More specifically:
  •   The presentation layer describes what the user interfaces displays and how
      user requests are handled. The presentation logic is probably to have different
      versions depending on which user interfaces are supported and what are the
      interface requirements of users.
  •   The application layer models the application’s business rules through the
      interaction with the application’s data
  •   The back-end layer includes Databases, Agents and the additional functionality
      required by the application components
  The diagram below presents in a schematic format the N-tier architecture




                                                                                   31
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




 Client side                                           Server side



                     Presentation layer                  Application layer     Back-end layer

                                                                                  Database




    Client              Presentation logic                   Business Logic        Agents



                                                                                    Others
                                                                                   Systems




                                    Figure 8 N-tier application architecture




        o      The User interface (client) handles the user’s interaction with the
               application; this can be a web browser running through a firewall or a
               wireless device
        o      The Presentation logic defines what the user interface displays and how a
               user’s requests are handled – depending on what user interfaces are
               supported one may need to have slightly different versions of the
               presentation logic to handle the client appropriately
        o      The Business logic models the application’s business rules, often through
               the interaction with the application’s data
        o      The Infrastructure services provide additional functionality required by the
               application 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 used
directly by designers or an application that interfaces existing Web development
tools, as shown in Figure 9.




                                                                                                32
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




                                                Standalone with
                                            import/export capabilities
                     IRIS
                     DSE                             Web based


                                                   Plug-in or API
                  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 a
need to overview and comment on existing services architectures and technologies.
This section is devoted to this discussion. It first discusses and compares three
possible service architectures upon a number of technical issues: a) Java 2
Enterprise Edition, b) Microsoft Windows DNA and c) Java 2 Enterprise edition with
COM support. Secondly, at a lower level of abstraction the criteria for technology
selection are identified and a number of state of the art technologies are evaluated
according to these criteria.



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

3.1.1 Java 2 Enterprise Edition
The Java 2 Platform, Enterprise Edition (J2EE) was designed to simplify complex
problems with the development, deployment, and management of multi-tier
enterprise solutions. J2EE is an open industry standard, and is the result of an
ongoing industry collaboration led by Sun Microsystems. This collaborative process
represents the collective expertise of the largest enterprise-computing vendors (such
as IBM, BEA, and Oracle), and ensures their participation and adoption. Because
J2EE is an open standard, it promotes competition among vendor products and
tools, and thereby promotes best-of-breed products in the middleware space, the
tool space, and the off-the-shelf component space.
A well-designed J2EE application can be independent of middleware, operating
system, and hardware. Middleware independence is possible because J2EE is a
specification, not a middleware implementation. Sun Microsystems enforces
middleware independence by requiring middleware vendors to pass a compatibility
test suite before receiving the J2EE certification logo. Operating system and
hardware independence is possible because J2EE is built on the platform-
independent Java Virtual Machine (JVM).



                                                                                           33
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




                                    Figure 10 The J2EE Object Model



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

3.1.2 Microsoft Windows DNA
Like J2EE, Microsoft's Windows DNA was also designed to simplify complex
problems with the development, deployment, and management of multi-tier
enterprise solutions. However, the most significant difference between the two
platforms is that Windows DNA is a proprietary product designed and supported by a
single vendor, whereas J2EE is an open industry standard supported by all key
middleware vendors, each of which is providing an implementation of the standard.
A Windows DNA application is tightly bound to Microsoft's Windows DNA
implementation. There is no open specification for Windows DNA, which prevents
other vendors from providing Windows DNA implementations. Windows DNA


                                                                                   34
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




applications are also tightly bound to Microsoft's Windows 2000 operating system,
and cannot be realistically deployed on other platforms. Because of this, hardware
selection 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), Microsoft
Transaction Server (MTS), and Microsoft Message Queue (MSMQ). The cornerstone
of 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 widely
used as a robust platform for application development and deployment. They offer a


                                                                                   35
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




combination of price, performance, and market availability that, until recently,
couldn't be challenged by any other network operating system. However, Microsoft
provides a platform (Windows DNA architecture) that not only offers almost the same
results with lower cost but also provides unique benefits that can significantly reduce
the time and cost of designing. COM on non-Windows operating systems allows
wrapping of existing logic on these systems in COM interface classes. This provides
replace front-end legacy logic on such systems with COM or Microsoft Transaction
Server (MTS) or COM+ components running on Windows NT.
Furthermore, building COM-based apps in a heterogeneous environment, a kind of
interoperability between Windows and non-Windows operating systems, provides
many new options for development and deployment. Running COM applications on
such systems extends the flexibility of Windows NT-based enterprise applications.
Building COM wrappers for existing logic, allows you to call that logic from MTS or
COM-based components running on Windows or any other operating system. Using
another logical tier consisting of MTS servers as a front-end for legacy code provides
even more advantages, such as:
    •   Building more scalable applications
    •   Keeping legacy code that works
    •   Using the Windows NT programming model and improvements as the
        application evolves.
We believe that a combination of the two previous solutions (Solution 1 and Solution
2) can provide us with the most efficient design because it combines the advantages
of the two previous platforms and provides an unlimited flexibility to all partners to
design their components with the technology that they have more concrete
knowledge or they want to experiment with. This solution is actually based on Java 2
Enterprise Edition but COM/COM+ support via COM-CORBA Bridge may be added.




                                                                                   36
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




                                                                                           COM
                                                                                         COM
                                                                                          objects
                                                                   COM-CORBA            COM
                                                                                         objects
                                                                     Bridge            objects




                                Figure 12 J2EE model with COM support




In this context, a provisional table that states specific technical components that can
be 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, IBM
                                           Unix…)
Database connector                         ODBC, JDBC



                                                                                           37
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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



3.1.4 Criteria for the selection of final IRIS system architecture
The following criteria will be used for the selection of the final architecture as well as
the selection of the most appropriate technologies that will support each functional
module of the IRIS DSE:
1. Support for heterogeneous environments. Many large corporations have a
   heterogeneous server-side deployment environment, with a wide variety of
   operating systems, hardware and middleware products. A heterogeneous
   environment can also merge as the result of several distinct projects at an
   organization or perhaps due to a merger or acquisition with another corporation
   that has a different deployment environment. It is crucial to choose a unifying
   programming language that can work equally well throughout the enterprise
   without having to use inefficient translation mechanisms.
2. Persistence. It is the storage of enterprise data in a durable data store, such as
   database. Any serious commerce application requires persistence; just as any
   serious commerce application requires security and transactions. A server-side
   platform should provide an automated, declarative persistence service to aid the
   application developer. Such a persistence service should provide adequate
   functionality to the developer. The evaluation parameters are the support for
   persisting complex types of data, the support for persisting data across multiple
   data stores, the ability to override the server-side platform’s persistence and the
   ability to provide custom persistence routines if necessary. An architecture that
   provides these features gives developers a higher degree of rapid application
   development, is powerful enough to address serious business problems, and yet
   is 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 (tests
   whether clients have access rights to perform desired operations). Component
   developers should be able to perform security checks programmatically as well
   as declaratively. There should also be a mechanism to control whether a
   component can run with the security level of its client, as well as delegate those
   security credentials when calling another subsystem.
4. Load-balancing. In a typical commerce system, presentation logic executes in a
   separate physical tier from the business logic. Separation of tiers allows each tier
   to scale independently, enables one to secure business process and data logic
   with a firewall and enables a Web development team and business process team
   to each take care of a separate physical part of the enterprise. To accommodate
   heavy traffic, one must be able to scale any given tier by adding additional
   machines to that tier. Adding additional machines requires logic to load-balance
   client requests across machines. There must be logic to load-balance incoming
   requests to the presentation tier, as well as load-balance requests from the
   presentation tier to the business tier.
5. Preservation of existing IT investments. As corporations are forced to adapt to
   new business requirements, it becomes essential to leverage investments in
   existing enterprise information systems, rather than rewrite entire business



                                                                                      38
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




    solutions from scratch. A server-side platform is needed that provides
    mechanisms to build on existing systems in an evolutionary (rather than a
    revolutionary) manner.
6. Platform maturity. The maturity of the proposed platforms is an important factor
   for their evaluation. The server side component services in Windows DNA and
   COM+ have been evolving since Microsoft Transaction Server (MTS) was
   released in December 1996. J2EE and EJB products have been evolving since
   the spring of 1998. Even though, Windows DNA depict as the mature platform, in
   reality today’s high-end J2EE platform-based products contain fundamental
   transactional logic that has been in production for many years.
7. Industry support. The developing application must support as much as possible
   standards in order to avoid single vendor dependence. The purpose of the
   platform is to be an open industry standard supported by all key middleware
   vendors. The inclusion of multiple vendors in the specification process ensures
   that vendors will be able to successfully layer the selected platform on top of
   established and proven existing solutions. The open collaborative specification
   process of an open standard technology also reflects the collective knowledge
   and expertise of a variety of enterprise computing vendors. This means that
   product 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 to
   choose a server-side platform that allows rapid application development. It is
   crucial to choose a platform that offer corporations the ability to externalize their
   common server-side plumbing tasks to a middleware vendor because this
   enables developers to exclusively focus on creating business logic. Lowering
   development time.
9. Reusability of Code. Reuse is very important for the effectiveness and
   efficiency of the applications as it simplifies programming procedures. There are
   two ways to achieve it. First of all by segregating an application’s business
   requirements into component parts. The second way is by using object
   orientation to encapsulate shared functionality. In the software world,
   encapsulation helps to cut down potential problems. In a system that consists of
   objects, the objects depend on each other in various ways. If some of them
   happen 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 necessary
   to change those other objects
10. Modularity. It refers to the simplification of complex programs into discrete
    modules that are responsible for a specific task. The concept of modularity is
    object-oriented analysis, which is trying to identify separated and simple tasks in
    the application in order to avoid conflict and misunderstanding.
11. High availability. A server-side platform must be highly available (24x7x365) to
    service the needs of corporation’s customers and partners. Because the Internet
    is global and ubiquitous, even planned downtime during the evening can result in
    significant lost business. Unplanned downtime during peak business hours can
    be disastrous, and will become amplified even more as the Internet becomes a
    primary vehicle for conducting business.
12. Scalability and Adaptability to change. It is the ability of the application to grow
    in order to meet an increasing demand of users base. By rapidly evolving



                                                                                    39
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




    applications to respond to changing market conditions, a corporation can
    leapfrog the competition through faster time to market, or quickly respond to
    steps taken by its competitors. By designing commerce systems adaptable to
    increased user load or transactional needs, an IT department can scale a
    deployment as demanded by the marketplace. The successful expansion of
    system operations is secured by the effective use of system resources while the
    enlargement of the potential user base may be applied by the appropriate
    technological infrastructure.
13. Total cost of ownership. When purchasing a server-side platform, one must
    consider the total cost of ownership. This is defined as the price of the server
    platform, the cost to develop and evolve a solution on that platform, maintenance
    fees, lost deployment time due to scalability or instability problems and lost
    customers due to platform shortcomings. A low total cost of ownership is a
    necessity for a high-volume, mission-critical commerce site.
14. Maintainability. Often, corporations judge the cost of a deployment in the span
    of a single project. In reality a deployment’s total cost includes the maintainability
    of the developed solution over time.
  Splitting presentation logic from business and data logic (N-tier Architecture) and
  supporting a number of different configurations ensures the fulfillment of the above
  criteria and ensures the interoperability in heterogeneous systems.



3.2 Examination of Technologies to Support Deployment of
    IRIS DSE functional modules
The criteria described above will allow us to evaluate which technologies should be
employed in order to facilitate the design, development, deployment, maintenance
and exploitability of the IRIS DSE in the most efficient manner. We will examine for
each functional module of the IRIS DSE a) the Interaction Interface, b) the DfA
Support, c) DfA (Knowledge Repository) as well as their respective submodules, the
most appropriate technologies and we rank them using heuristic weighting factors for
each criteria in order to measure their relative importance. We compare as well
some of the technologies described.

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


3.2.1.1 User Interface Technologies
User interface describes all issues regarding presentation toward both end-users
and 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 unifying
        programming language that can work equally well throughout the enterprise
        without having to use inefficient translation mechanisms;


                                                                                      40
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




    −   Security: Technologies used in user interface implementation must provide
        secure communication between client and system;
    −   Load-balancing;
    −   Preservation of existing IT investments: It is important to leverage
        investments in existing enterprise information systems, rather than rewrite
        entire business solutions from scratch;
    −   Industry support: Technologies used in user interface implementation must
        support as much as possible standards, specifications and recommendations
        in order to avoid single vendor dependence;
    −   Time to market: This criterion will be satisfied by choosing a server-side
        platform that allows rapid application development;
    −   Reusability and Modularity: Code reuse is very important for the effectiveness
        and efficiency of the applications as it simplifies programming procedures;
    −   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 by choosing open-source and vendor-independent technologies;
    −   Splitting presentation logic from business and data logic: It is important to
        choose technologies that have a core-support for this kind of separation.
The technologies that support user interfaces with respect to the criteria mentioned
above are HTML, XML, JSP, Servlets, and JFC Swing. We will examine them now
and 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 and
processed by a wide range of tools, from simple plain text editors to sophisticated
WYSIWYG authoring tools. HTML uses tags to structure text into headings,
paragraphs, lists, hypertext links etc. HTML is not designed to be used to control
document 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 to
specify layout separately. That way, not only is there a better chance of all browsers
displaying document properly, but also, if required changing such things as the font
or color, is simple to do so. HTML documents are supposed to be structured around
items 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 presented
by HTML: it is not extensible by the author (although browser manufacturers defined
proprietary tags in the past); it is display-centric (a well-known accessibility hurdle); it
is not directly reusable; it only provides one view of the data; it has little or no
semantic 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 to
enable generic SGML to be served, received, and processed on the Web in the way
that is now possible with HTML. Despite an initially slow take-up, the industry is
adopting XML at an increasing pace. XML will shortly become a de-facto standard


                                                                                        41
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




for e-commerce and distributed applications. There are several elements that make
the future of XML promising (Velasco, 2001c):
    1. It is well suited for data interchange between different organizations and
       individuals. It will represent the «end of proprietary file formats,» were the
       structure of the documents is decided by the vendor of the tool used in the
       organization. Even if the structure of the Document Type Definition (DTDs) is
       not available, XML documents can be read and exchanged, because
       documents are standard Unicode text files, and its well-formedness can be
       checked against the recommendation, which defines an unambiguous
       mechanism for constraining the structure. Thus XML bridges the gap
       between 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 stressed
       that XML is better adapted to exchange information with Object Databases,
       although they have not reached yet the maturity and spread of Relational
       Databases.
    3. It enables the use of smart software agents, and provides to Internet and
       local search engines with meaningful elements to classify and sort
       documents with the assistance of the document markup and content. It also
       allows 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. The
flexibility of these markup languages makes them specially suitable to develop
applications and services for upcoming technologies. Among them, we can highlight
XSL (Extensible Stylesheet Language), which consists of two parts: XSLT (XSL
Transformations), and XSL:Formatting Objects (XSL:FO).
   The DOM (Document Object Model) is a standard set of function calls for
manipulating XML (and HTML) files from a programming language. And XML, as a
W3C technology, is license-free. XML is the preferred technology in many
information-transfer scenarios because of its ability to encode information in a way
that is easy to read, process, and generate. As mentioned earlier, XML languages
have a number of uses including exchanging information, defining document types
and specifying messages. Information that is expressed in a structured, text-based
format can easily be transmitted between, transformed, and interpreted by entities
that understand the structure. In this way XML brings the same cross-platform
benefits to information exchange as the Java programming language has for
processing.
JavaServer Pages (JSP)
JSP technology allows web developers and designers to rapidly develop and easily
maintain, information-rich, dynamic web pages that leverage existing business
systems. As part of the Java family, JSP technology enables rapid development of
web-based applications that are platform independent. JSP technology separates
the user interface from content generation enabling designers to change the overall
page layout without altering the underlying dynamic content. JSP technology uses
XML-like tags and scriptlets written in the Java programming language to
encapsulate the logic that generates the content for the page. Additionally, the


                                                                                   42
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




application logic can reside in server-based resources (such as JavaBeans
component architecture) that the page accesses with these tags and scriptlets. Any
and all formatting (HTML or XML) tags are passed directly back to the response
page. By separating the page logic from its design and display and supporting a
reusable component-based design, JSP technology makes it faster and easier to
build web-based applications. The JSP specification is the product of industry-wide
collaboration with industry leaders in the enterprise software and tools markets, led
by Sun Microsystems. Sun has made the JSP specification freely available to the
development community, with the goal that every web server and application server
will support the JSP interface. JSP technology is a key component in the Java 2
Platform, Enterprise Edition, Sun's highly scalable architecture for enterprise
applications.
JSP technology provides a number of capabilities that are ideally suited for working
with XML. JSP pages can contain any type of text-based data, so it is straightforward
to generate documents that contain XML markup. Also, JSP pages can use the full
power of the Java platform to access programming language objects to parse and
transform XML messages and documents. In particular, as part of the Java software
environment, JSP pages can use objects that leverage the new Java APIs for
processing XML data. Finally JSP technology provides an abstraction mechanism to
encapsulate functionality for ease of use within a JSP page.
Java Servlet technology
This technology provides web developers with a simple, consistent mechanism for
extending the functionality of a web server and for accessing existing business
systems. 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 extending
and enhancing web servers. Servlets provide a component-based, platform-
independent method for building web-based applications, without the performance
limitations of CGI programs. And unlike proprietary server extension mechanisms,
servlets are server-independent as well as platform-independent. Servlets have
access to the entire family of Java APIs, including the JDBC API to access
enterprise databases. Servlets can also access a library of HTTP-specific calls and
receive all the benefits of the mature Java language, including portability,
performance, reusability, security and crash-protection.
The Java Foundation Class (JFC) Swing
JFC is a set of user interface components, which is built using a “Pluggable Look
and Feel” architecture. This architecture separates the implementation of the user
interface 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 visual
presentation of the program on the screen, but would instead have direct access to
that program because it would interact with the user in his/her desired modality. The
JFC Swing user interface building blocks are designed around a “Pluggable Look
and Feel” architecture that allows to get away from interpreting the visual
manifestations, and instead "plug in" a non-visual manifestation. This architecture
separates the expression of the user interface from the underlying structure and data
on a component-by-component basis. This is accomplished by separating the user
interface of the component from the "model" of the component (the structure which
encapsulates the state and information that the user interface portion presents to the


                                                                                     43
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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


3.2.1.2 Ranking of relevant technologies
Heuristic weighting factors are devised to measure the relative importance of the
different 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 presented
with respect to the evaluation criteria (with their associated weighting factors).


                              Weighting                                             JFC
            Criteria                        HTML          XML       JSP/Servlets
                               factor                                              Swing
      Support for
1.    heterogeneous             High         Yes           Yes           Yes       Yes
      environments
2.    Persistence             Medium           -           Yes             -         -
3.    Security                  High           -            -            Yes         -
4.    Load-balancing            Low            -            -            Yes         -
      Preservation of
5.    existing IT             Medium         Yes           Yes           Yes       Yes
      investments
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       Yes
10
      Modularity                High           -           Yes           Yes       Yes
  .
11
      High availability         Low            -            -              -         -
  .
      Scalability and
12
      Adaptability to           Low            -            -              -         -
  .
      change
13    Total cost of
                                High         Yes           Yes           Yes       Yes
  .   ownership
14
      Maintainability           Low            -            -              -         -
  .




                                                                                   44
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




      Splitting
      presentation logic
15
      from business and        High            -            -            Yes        Yes
  .
      data logic (N-tier
      Architecture)


As a conclusion JSP technology and servlets together provide an attractive
alternative to other types of dynamic web scripting/programming that offer platform
independence, enhanced performance, separation of logic from display, ease of
administration, 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 web
of information where different classes of clients consume and generate information
that is exchanged between different servers that run on varied system platforms.


3.2.1.3 Interaction Support
Interaction support will take into consideration all models of interaction to inform the
development of usability guidance. For example, instead of a visual presentation, a
user will choose an audio presentation, or a tactile (e.g. Braille) presentation, or a
combination of the two. In the same manner as before the criteria relevant to
interaction 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 the
relevant criteria.
Java Accessibility API
This API defines a contract between the individual user interface components that
make up a Java application and an assistive technology that is providing access to
that Java application. If a Java application fully supports the Java Accessibility API,
then it should be compatible with, and friendly toward, assistive technologies such as
screen readers, screen magnifiers, etc. With a Java application that fully supports
the Java Accessibility API, no off-screen model would be necessary because the API
provides all of the information normally contained in an off-screen model. In order to
provide access to Java applications, an assistive technology requires more than the
Java Accessibility API: it also requires support in locating the objects that implement
the API as well as support for being loaded into the Java Virtual Machine, tracking
events, etc.


                                                                                    45
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




Java Accessibility Utilities
The Java Accessibility Utilities are delivered by Sun as a separately downloadable
package for use by assistive technology vendors in their products that provide
access to Java applications running in a Java Virtual Machine. This package
provides the necessary support for assistive technologies to locate and query user
interface objects inside a Java application running in a Java Virtual Machine. It also
provides support for installing "event listeners" into these objects. These event
listeners allow objects to learn about specific evens occurring in other objects using
the peer-to-peer approach defined by the delegation event model. Finally, this
package provides specific support for loading assistive technologies into a Java
Virtual Machine. As a conclusion: Together with tools such as screen readers and
hands-free pointing devices, Java technology is helping to make computing and
computer usage a reality for people with disabilities. (for example, a sight-impaired
programmer who uses a screen reader to describe the components of a program's
graphical user interface, or a quadriplegic who depends on a hands-free pointing
device to update a spreadsheet.) These tools need access to the characteristics of
the displayed content. In other words, the screen reader needs to know that a
component is a button rather than a text field; the pointing device needs to
distinguish each column of the spreadsheet. And that's where Java technology
comes in. Through the Java Accessibility API, application developers can make the
characteristics of a program's user interface available to assistive technologies.
Java Access Bridge
It is a means by which already existing assistive technologies, operating on native
platforms, can access the information offered up by the Java Accessibility API within
a given applet or application. Java applications run on a wide variety of host
operating systems, many of which already have assistive technologies available for
them. In order for these existing assistive technologies to provide access to Java
applications, they need a bridge between themselves in their native environment(s),
and the Java Accessibility support that is available from within the Java Virtual
Machine (JVM). This bridge, by virtue of the fact that it has one end in the JVM and
the other on the native platform, will be slightly different for each platform it bridges
to.


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


                                                   Java            Java
                                 Weighting                                         Java Access
             Criteria                           Accessibility   Accessibility
                                  factor                                              Bridge
                                                    API           Utilities
     Support for
1.   heterogeneous                  High             Yes             Yes              Yes
     environments
2.   Persistence                    Low               -               -                 -



                                                                                            46
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




3.    Security                       Medium           -               -             -
4.    Load-balancing                    Low           -               -             -
      Preservation of
5.                                   Medium           -               -             -
      existing IT investments
6.    Maturity                          High         Yes             Yes           Yes
7.    Industry support                  High         Yes             Yes           Yes
8.    Time to market                 Medium           -               -             -
9.    Reusability                       High         Yes             Yes           Yes
10
      Modularity                        High         Yes             Yes           Yes
  .
11
      High availability              Medium           -               -             -
  .
12    Scalability and
                                        Low           -               -             -
  .   Adaptability to change
13    Total cost of
                                        High          -               -             -
  .   ownership
14
      Maintainability                   High         Yes             Yes           Yes
  .
      Splitting presentation
15    logic from business
                                     Medium           -               -             -
  .   and data logic (N-tier
      Architecture)



3.2.1.5 Software interface
In general, software interface describes collaboration between a Web
Product/Application and a Web Environment. Similarly the criteria relevant to
software interface are:
      −   Support for heterogeneous environments,
      −   Security,
      −   Preservation of existing IT investments,
      −   Maturity, Industry support,
      −   Time to market,
      −   Total cost of ownership.


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


                                                                                        47
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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


RMI over IIOP
This is part of the Java 2 Platform, Enterprise Edition. It provides the ability to write
CORBA applications for the Java platform without learning CORBA Interface
Definition Language (IDL). To work with CORBA applications in other languages, IDL
can be generated from Java programming language interfaces. RMI over IIOP
includes the full functionality of a CORBA Object Request Broker (ORB) and Java
CORBA code can be written without having to license any other software. RMI-IIOP
combines the best features of Java Remote Method Invocation (RMI) with the best
features of Common Object Request Broker Architecture (CORBA). It provides a
designer/developer with a powerful environment in which to do distributed
programming using the Java platform. Like RMI, RMI-IIOP speeds distributed
application development by allowing developers to work completely in the Java
programming language. When using RMI-IIOP to produce Java technology-based
distributed applications, there is no separate Interface Definition Language (IDL) or
mapping to learn. Like RMI, RMI-IIOP provides flexibility by allowing
developers/designers to pass any serializable Java object (Objects By Value)
between application components. Like CORBA, RMI-IIOP is based on open
standards defined with the participation of hundreds of vendors and users in the
Object Management Group. Like CORBA, RMI-IIOP uses Internet Inter-ORB
Protocol (IIOP) as its communication protocol. IIOP eases legacy application and
platform integration by allowing application components written in C++, Smalltalk,
and other CORBA supported languages to communicate with components running
on the Java platform. With RMI-IIOP, developers/designers can write remote
interfaces in the Java programming language and implement them simply using Java
technology and the Java RMI APIs. These interfaces can be implemented in any
other language that is supported by an OMG mapping and a vendor supplied ORB
for that language. Similarly, clients can be written in other languages using IDL
derived from the remote Java technology-based interfaces. Using RMI-IIOP, objects
can 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 capability
to the Java platform, providing standards-based interoperability and connectivity.
Java IDL enables distributed Web-enabled Java applications to transparently invoke
operations on remote network services using the industry standard IDL (Object
Management Group Interface Definition Language) and IIOP (Internet Inter-ORB
Protocol) defined by the Object Management Group. Runtime components include
Java ORB for distributed computing using IIOP communication.
Java 2 Platform, Enterprise Edition (J2EE) simplifies application programming for
distributed transaction management. J2EE includes support for distributed
transactions through two specifications, Java Transaction API (JTA) and Java
Transaction Service (JTS). JTA is a high level, implementation independent,
protocol independent API that allows applications and application servers to access
transactions. It specifies standard Java interfaces between a transaction manager
and the parties involved in a distributed transaction system: the resource manager,
the application server, and the transactional applications. JTS specifies the


                                                                                     48
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




implementation of a Transaction Manager that supports JTA and implements the
Java mapping of the OMG Object Transaction Service (OTS) 1.1 specification at the
level below the API. JTS propagates transactions using the Internet Inter-ORB
Protocol (IIOP). JTS is part of the Java 2 Platform, Enterprise Edition and provides
an implementation of the Java Transaction API (JTA). JTS uses the standard
CORBA ORB/TS interfaces and Internet Inter-ORB Protocol (IIOP) for transaction
context propagation between JTS Transaction Managers. A JTS Transaction
Manager provides transaction services to the parties involved in distributed
transactions: the application server, the resource manager, the standalone
transactional application, and the Communication Resource Manager (CRM).
JTA and JTS allow application servers built on the Java 2 Platform, Enterprise
Edition to take the burden of transaction management off of the component
developer. Developers can define the transactional properties of Enterprise
JavaBeans technology based components during design or deployment using
declarative statements in the deployment descriptor. The application server takes
over 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 message
        and how to process it,
    •   a set of encoding rules for expressing instances of application-defined
        datatypes, and
    •   a convention for representing remote procedure calls and responses.
SOAP can potentially be used in combination with a variety of other protocols such
as HTTP.
SOAP provides a simple and lightweight mechanism for exchanging structured and
typed information between peers in a decentralized, distributed environment using
XML. SOAP does not itself define any application semantics such as a programming
model or implementation specific semantics; rather it defines a simple mechanism
for expressing application semantics by providing a modular packaging model and
encoding mechanisms for encoding data within modules. This allows SOAP to be
used in a large variety of systems ranging from messaging systems to Remote
Procedure Calls (RPC).
SOAP consists of three parts:
    •   The SOAP envelope construct defines an overall framework for expressing
        what is in a message; who should deal with it, and whether it is optional or
        mandatory.
    •   The SOAP encoding rules (see) defines a serialization mechanism that can
        be used to exchange instances of application-defined datatypes.
    •   The SOAP RPC representation (see) defines a convention that can be used
        to represent remote procedure calls and responses.
Although these parts are described together as part of SOAP, they are functionally
orthogonal. In particular, the envelope and the encoding rules are defined in different
namespaces in order to promote simplicity through modularity.


                                                                                   49
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




In addition to the SOAP envelope, the SOAP encoding rules and the SOAP RPC
conventions, this specification defines two protocol bindings that describe how a
SOAP message can be carried in HTTP messages either with or without the HTTP
Extension Framework.
A major design goal for SOAP is simplicity and extensibility. This means that there
are several features from traditional messaging systems and distributed object
systems 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 of
the different criteria with respect to the software interface. In the following table, all
the technologies mentioned above are presented with respect to the evaluation
criteria (with their associated weighting factors).


                              Weighting
               Criteria                    CORBA         JTA/JTS      RMI-IIOP      SOAP
                               factor
          Support for
 1.       heterogeneous         High         Yes             Yes         Yes          Yes
          environments
 2.       Persistence           Low            -              -            -          Yes
 3.       Security              High         Yes             Yes         Yes          Yes
 4.       Load-balancing        Low            -              -            -           -
          Preservation of
 5.       existing IT           High         Yes             Yes         Yes          Yes
          investments
 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           -              -            -           -
          Scalability and
12.       Adaptability to       Low            -              -            -           -
          change
          Total cost of
13.                             High         Yes             Yes         Yes          Yes
          ownership
14.       Maintainability     Medium           -              -            -           -




                                                                                      50
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




          Splitting
          presentation
          logic from
15.                             Low            -             -             -          -
          business and
          data logic (N-tier
          Architecture)



3.2.2 DfA Support
From the information technology point if view, the DfA Support functional
components can be developed in the form of either stand-alone, thin-client or even
complex client-server multi-tier application while the criteria relevant to these
modules are:
      −   Support for heterogeneous environments (It is crucial to choose a unifying
          programming language that can work equally well throughout the enterprise
          without having to use inefficient translation mechanisms),
      −   Preservation of existing IT investments,
      −   Platform maturity, Industry support (It is important to choose a technologies
          that are well-supported by numerous vendors and organizations),
      −   Reusability (Technologies used in application development must be based on
          advanced 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 these
modules with respect to the criteria mentioned above. Actually, J2EE applications
developer/designers write J2EE application components. A J2EE component is a
self-contained functional software unit that is assembled into a J2EE application and
interfaces with other application components. The J2EE specification defines the
following application components: Application client components, Enterprise
JavaBeans components, Servlets and JavaServer Pages (JSP) components (also
called Web components), Applets.
A Java Applet is a program written in the Java programming language that can be
included in an HTML page, much in the same way an image is included. When using
a Java technology-enabled browser to view a page that contains an applet, the
applet's code is transferred to client system and executed by the browser's Java
Virtual Machine (JVM). Applets are a powerful tool in supporting client-side
programming, a major issue for the Web. Programming within an applet is very
restrictive since there is the Java run-time security system. Java offers digital signing
for applets so a developer/designer can choose to allow trusted applets to have
access to local machine. To support more complex user interactions, it may be
necessary to provide functionality directly in the client tier. This functionality is
typically implemented as JavaBeans components that interact with the service in the


                                                                                     51
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




middle tier via servlets. Client-tier JavaBeans components would typically be
provided by the service as an applet that is downloaded automatically into a user's
browser. To eliminate problems caused by old or non-standard versions of the JVM
in a user's browser, the J2EE application model provides special support for
automatically downloading and installing the Java Plug-in. Client-tier beans can also
be contained in a stand-alone application client written in the Java programming
language. In this case, we would typically make operating system specific installation
programs 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. Since
Java technology programs are portable across all environments, the service need
only maintain a single version of the client program. Although the client program
itself is portable, installation of the Java technology client typically requires OS-
specific code. There are several commercial tools that automate the generation of
these OS-specific installation programs. If desired, non-Java clients can present
J2EE services to users. Since the service is presented by servlets in the middle tier
to first-tier clients using the standard HTTP protocol, it is easy to access it from
practically any program running on any operating system.
Similarly the Component Library Delivery module will consist of all reusable
components used in IRIS applications. These components will be used to
encapsulate business logic of IRIS applications and will be deployed and executed in
context of application server (component container). The criteria relevant to
Component Library are :
−   Support for heterogeneous environments (An IRIS application typically needs to
    be customized at deployment time to each operational environment. Component
    architecture must allow the component developer/designer to separate the
    common application business logic from the customization logic performed at
    deployment time. It also must allow persistent components to be bound to
    different data sources. This persistence binding is done at deployment. The
    application developer/designer can write code that is not limited to a single type
    of data sources. Component architecture also facilitates the deployment of an
    application by establishing deployment standards, such as for data source
    lookup, other application dependencies, security configuration, and so forth. The
    standards enable the use of deployment tools. The standards and tools remove
    much of the possibility of miscommunication between the developer/designer and
    deployer),
−   Persistence,
−   Security (Components must rely on an architecture that will shift most of the
    responsibility for an application’s security from the developer/designer to the
    server vendor, or System Administrator etc. The people performing these roles
    are more qualified than the developer/designer to secure the application. This
    kind of approach to application’s security leads to better security of the
    operational applications),
−   Preservation of existing IT investments (Component architecture must simplify
    and standardize the integration of IRIS applications with any existing operational
    applications and systems at the target operational environment),
−   Maturity,
−   Industry support (Component architecture must be supported by great variety of
    software vendors, companies and organizations),


                                                                                   52
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




−   Reusability (An IRIS application will consist of components, a reusable building
    blocks. There are two essential ways to reuse a component: A component not
    yet deployed can be reused at application development time by being included in
    several different applications. The component can be customized for each
    application without requiring changes, or even access, to its source code. Other
    applications can reuse a component that is already deployed in a customer’s
    operational environment by making calls to its client-view interfaces. Multiple
    applications can make calls to the deployed component),
−   Modularity,
−   Scalability,
−   Maintainability,
−   Separation of business logic from presentation logic (This separation makes it
    possible to develop multiple presentation logic for the same business process, or
    to change the presentation logic of a business process without needing to modify
    the code that implements the business process)
The Enterprise JavaBeans (EJB) architecture provides extensive support for the
Component Library Module, with respect to the criteria mentioned above. The EJB
component architecture is the backbone of the J2EE platform. The core of a J2EE
application is comprised of one or several enterprise beans that perform the
application’s business operations and encapsulate the business logic of an
application. Other parts of the J2EE platform, such as the JavaServer Pages,
complement the EJB architecture to provide functions such as presentation logic and
client interaction control logic. The EJB specification defines a component model
and deployment environment to simplify the lifecycle of multi-tiered distributed
systems. EJB is a specification defined by JavaSoft, endorsed and implemented by
many vendors. It’s not an actual product. An EJB-compliant product is a product that
implements and adheres to the standards set out in the specification. The objective
of the EJB specification is to “make it easy to write [server-side] applications”. The
EJB specification achieves this objective by defining a set of design patterns for the
server-side code as well as roles, which various developers, administrators, and
system components play in the various phases of the lifecycle of a distributed
application. Through the use of a set of standard design patterns and roles, which
decouple business logic from system infrastructure- products which adhere to the
EJB specification make it possible to write applications without having to understand
these low-level system infrastructure issues such as transactions, caching
mechanisms, multi-threading and security. The definition of these roles and
components also gives the application developer vendor independence. EJB
vendors adhere and contribute to the one specification, hence Enterprise Java Bean
components are easily transferable between vendors tools and platforms and deliver
on Java’s promise of “Write Once, Run Anywhere” philosophy.
EJBeans are reusable components that are developed in accordance with the
Design Patterns highlighted in the EJB specification. EJBeans can be of two different
types, Entity Beans and Session Beans. EJB architecture supports persistence over
persistent objects called entity beans. An entity bean is an object representation of
some persistent data, such as a record stored in a database. When building an entity
bean, a developer/designer can either write her/his own code to retrieve the object
data from the persistent data store and write back any updates when the transaction
completes. EJB will automatically manage the persistence of the data on behalf of
the object. If EJB manages the persistence, the object is portable across any data


                                                                                   53
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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

3.2.2.1 Ranking of Technologies
Heuristic weighting factors are also devised here to measure the relative importance
of the different criteria with respect to the component library. In the following table, all
the technologies mentioned above are presented with respect to the evaluation
criteria (with their associated weighting factors).


                                          Weighting
                  Criteria                                       EJB
                                           factor
       Support for heterogeneous
 1.                                          High                Yes
       environments
 2.    Persistence                           High                Yes
 3.    Security                              High                Yes
 4.    Load-balancing                        Low                   -
       Preservation of existing IT
 5.                                          High                Yes
       investments
 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                   -
       Scalability and Adaptability
12.                                          High                Yes
       to change
13.    Total cost of ownership             Medium                  -
14.    Maintainability                       High                Yes
       Splitting presentation logic
15.    from business and data                High                Yes
       logic (N-tier Architecture)



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


                                                                                        54
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




systems, and other legacy information systems), IRIS will run its services using the
information stored in such systems; the success of the system critically depends on
this information. The IRIS system cannot afford to have an application cause
inconsistent data or compromise the integrity of data stored in these systems. This
leads to a requirement for ensuring transactional access to enterprise information
systems from various applications. The criteria relevant to Knowledge Repository
are:
−   Support for heterogeneous environments (Many large corporations have a
    heterogeneous server-side deployment environment, with a wide variety of
    operating systems, hardware and middleware products.);
−   Security (A mechanism to authenticate clients as well as authorize clients must
    be provided.);
−   Load-balancing (In order to accommodate heavy traffic, a multi-tier system must
    be able to scale any tier by adding additional machines to that tier. Adding
    additional machines requires logic to load-balance client requests across
    machines. There must be logic to load-balance incoming requests to the
    presentation tier, as well as load-balance requests from the presentation tier to
    the business tier, and so on.);
−   Preservation of existing IT investments (It is important to leverage investments in
    existing enterprise information systems.);
−   Maturity;
−   Industry support (Technologies that will be used must support as much as
    possible standards, specifications and recommendations in order to avoid single
    vendor 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 by
    choosing open-source and vendor-independent technologies);
−   Maintainability.
The Java technologies such as JDBC and JNDI provide extensive support for
Knowledge Repository with respect to the criteria mentioned above.
The Java Database Connectivity (JDBC) technology is an API that lets
developer/designer to access virtually any tabular data source from the Java
programming language. It provides cross-DBMS connectivity to a wide range of SQL
databases, and provides 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's capabilities for industrial strength, cross-platform applications that
require access to enterprise data. With a JDBC technology-enabled driver, a
developer/designer can easily connect all corporate data even in a heterogeneous
environment.
These are advantages of JDBC Technology:
•   Leverage Existing Enterprise Data (With JDBC technology, businesses are not
    locked in any proprietary architecture, and can continue to use their installed
    databases and access information easily - even if it is stored on different
    database management systems);


                                                                                   55
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




•   Simplified Enterprise Development (The combination of the Java API and the
    JDBC API makes application development easy and economical. JDBC hides the
    complexity of many data access tasks, doing most of the "heavy lifting" for the
    developer 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 configuration
    is required on the client side. With a driver written in the Java programming
    language, all the information needed to make a connection is completely defined
    by the JDBC URL or by a DataSource object registered with a Java Naming and
    Directory Interface (JNDI) naming service. Zero configuration for clients supports
    the 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 enables
    the development of sophisticated applications that need to understand the
    underlying facilities and capabilities of a specific database connection.);
•   No Installation (A Pure JDBC technology-based driver does not require special
    installation; it is automatically downloaded as part of the applet that makes the
    JDBC calls.);
•   Database Connection Identified by URL (JDBC technology exploits the
    advantages of Internet-standard URLs to identify database connections. The new
    JDBC 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 to
    maintain. In addition to this important advantage, DataSource objects can
    provide connection pooling and distributed transactions, essential for enterprise
    database computing. This functionality is provided transparently to the
    programmer.);
•   Included in the Java Platform (As a core part of the Java 2 Platform, the JDBC
    2.0 core API is available anywhere that the platform is. This means that Java
    applications can truly write database applications once and access data
    anywhere. The Java 2 Platform, Enterprise Edition (J2EE), includes both the
    JDBC core API and the JDBC Optional Package API. The Optional Package API
    contains server-side functionality for industrial strength scalability.);
•   Requirements (Software: The Java 2 Platform, either the Java 2 SDK, Standard
    Edition, or the Java 2 SDK, Enterprise Edition, an SQL database, and a JDBC
    technology-based driver for that database. Hardware: Same as the Java 2
    Platform.);
•   Availability (The JDBC API specification is available on the Java Software web
    site. The JDBC API and a reference implementation of the JDBC-ODBC Bridge
    and related documentation are shipping now with the Java 2 SDK, Standard
    Edition, and the Java 2 SDK, Enterprise Edition.).
The Java Naming and Directory Interface (JNDI) is a standard extension to the
Java platform, providing Java technology-enabled applications with a unified
interface to multiple naming and directory services in the enterprise. As part of the
Java Enterprise API set, JNDI enables seamless connectivity to heterogeneous
enterprise naming and directory services. Developers/designers can now build
powerful and portable directory-enabled applications using this industry standard.
JNDI is an API specified in Java that provides naming and directory functionality to


                                                                                   56
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




applications written in Java. It is designed especially for Java by using Java's object
model. Using JNDI, Java applications can store and retrieve named Java objects of
any type. In addition, JNDI provides methods for performing standard directory
operations, such as associating attributes with objects and searching for objects
using their attributes. JNDI is also defined independent of any specific naming or
directory service implementation. It enables Java applications to access different,
possibly multiple, naming and directory services using a common API. Different
naming and directory service providers can be plugged in seamlessly behind this
common API. This allows Java applications to take advantage of information in a
variety of existing naming and directory services, such as LDAP, NDS, DNS, and
NIS (YP), and allows Java applications to coexist with legacy applications and
systems. Using JNDI as a tool, the Java application developer/designer can build
new powerful and portable applications that not only take advantage of Java's object
model but also are well-integrated with the environment in which they are deployed.
Directory-enabled applications and applets (application like IRIS that uses a naming
or directory service), like any other program running on the network, can use the
directory in the traditional way, that is, to store and retrieve attributes of directory
objects. (For example, a mail client program can use the directory as an address
book for retrieving the addresses of mail recipients. A mail transfer agent program
can use it to retrieve mail routing information. And a Java calendar program can use
it to retrieve user preference settings.) Applications can share the common
infrastructure provided by the directory. This sharing makes applications that are
deployed across the system, and even the network, more coherent and manageable
(For example, printer configuration and mail routing information can be stored in the
directory so that it can be replicated and distributed for use by all printer-related and
mail-related applications and services) In addition to using the directory in the
traditional way, applications can also use it as a repository for objects that is to store
and retrieve objects (For example, a print client program should be able to look up a
printer object from the directory and send a data stream to the printer object for
printing.)
As a conclusion, naming and directory services play a vital role in intranets and the
Internet by providing network-wide sharing of a variety of information about users,
machines, networks, services, and applications. Finding resources is of particular
importance in large-scale enterprise environments, where the applications may
depend on services provided by applications written by other groups in other
departments. 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 different
criteria with respect to the knowledge repository. In the following table, all the
technologies mentioned above are presented with respect to the evaluation criteria
(with their associated weighting factors).


                                         Weighting
                 Criteria                                      JDBC                JNDI
                                          factor
       Support for heterogeneous
 1.                                         High                Yes                Yes
       environments
 2.    Persistence                          Low                  -                  -



                                                                                         57
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




 3.    Security                             High                Yes                Yes
 4.    Load-balancing                       High                Yes                Yes
       Preservation of existing IT
 5.                                         High                Yes                Yes
       investments
 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
       Scalability and Adaptability
12.                                         Low                  -                  -
       to change
13.    Total cost of ownership              High                Yes                Yes
14.    Maintainability                      High                Yes                Yes
       Splitting presentation logic
15.    from business and data               Low                  -                  -
       logic (N-tier Architecture)

3.2.4 Comparison of JavaServer Pages (JSP) and Microsoft Active
      Server Pages (ASP) Technologies
At first glance, these technologies have many similarities because both are designed
to 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 the
use of components that are called from the page itself. And both provide an
alternative to creating CGI scripts that make page development and deployment
easier and faster.
In many ways, the biggest difference between JSP and ASP technologies lies in the
approach to the software design itself. JSP technology is designed to be both
platform and server independent, created with input from a broader community of
tool, server, and database vendors. In contrast, ASP is a Microsoft technology that
relies primarily on Microsoft technologies.
Instead of being tied to a single platform or vendor, JSP technology can run on any
Web server and is supported by a wide variety of tools from multiple vendors.
Because it uses ActiveX controls for its components, ASP technology is basically
restricted to Microsoft Windows-based platforms. Offered primarily as a feature of
Microsoft IIS, ASP technology does not work easily on a broader range of Web
servers because ActiveX objects are platform specific. Although ASP technology is
available on other platforms through third-party porting products, to access
components and interact with other services, the ActiveX objects must be present on
the selected platform. If not present, a bridge to a platform supporting them is
required.
Because Sun developed JSP technology using the Java Community Process, as well
as Apache development process, JSP API has undoubtedly benefited - and will
continue to benefit - from the input of this extended community. In contrast, ASP
technology is a specifically Microsoft initiative, developed in a proprietary process.


                                                                                         58
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




JSP technology provides a flexible, open choice that works with a wide variety of
vendor tools and reflects industry input and collaboration.
From developer's perspective, both ASP and JSP technologies let developers
separate content generation from layout by accessing components from the page.
ASP supports the COM model, while JSP technology provides components based on
JavaBeans technology or JSP tags.
The first difference apparent to any page author is the JSP tags themselves. While
both ASP and JSP use a combination of tags and scripting to create dynamic Web
pages, JSP technology enables developers to extend the JSP tags available. JSP
developers can create custom tag libraries, so page authors can access more
functionality using XML-like tags and depend less on scripting. With custom tags,
developers can shield page authors from the complexities of page creation logic and
extend 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 Enterprise
JavaBean component accessing legacy databases can serve distributed systems on
both UNIX and Microsoft Windows platforms. And the tag extension capability of JSP
technology gives developers an easy, XML-like interface for sharing packaged
functionality with page designers throughout the enterprise. This component-based
model speeds application development because it enables developers to build quick
prototype applications using lightweight subcomponents, then integrate additional
functionality as it becomes available, and to leverage work done elsewhere in the
organization and encapsulate it in a JavaBean or Enterprise JavaBean component.
JSP technology uses the Java language for scripting, while ASP pages use Microsoft
VBScript or JScript. The Java language is a mature, powerful, and scalable
programming language that provides many benefits over the interpreted Basic-based
scripting languages. Because they use Java technology and are compiled into Java
servlets, JSP pages provide a gateway to the entire suite of server-side Java
libraries for HTTP-aware applications. Furthermore, Java language helps protect
against system crashes, while ASP applications on Windows NT systems are
susceptible to crashing. It also helps in the area of memory management by
providing protection against memory leaks and pointer-related bugs that can slow
application deployment. Additionally, JSP provides the robust exception handling
necessary for real-world applications.
Applications using JSP technology are easier to maintain over time than ASP-based
applications. Scripting languages are fine for small applications, but do not scale well
to manage large, complex applications. Because the Java language is structured, it
is easier to build and maintain large, modular applications with it. JSP technology's
emphasis on components over scripting makes it easier to revise content without
affecting logic, or revise logic without changing content. The Enterprise JavaBeans
architecture encapsulates the enterprise logic, such as database access, security,
and transaction integrity, and isolates it from the application itself. Because JSP
technology is an open, cross-platform architecture, Web servers, platforms, and
other components can be easily upgraded or switched without affecting JSP-based
applications. This makes JSP suitable for real-world Web applications, where
constant change and growth is the norm.
As part of J2EE, JSP pages have access to all J2EE components, including
JavaBeans and Enterprise JavaBeans components and Java servlets. JSP pages
have access to all of the standard J2EE services. Through J2EE, JSP pages can



                                                                                    59
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




interact with enterprise systems in many ways. J2EE supports two CORBA-
compliant technologies: Java IDL and RMI-IIOP. With Enterprise JavaBeans
technology, JSP pages can access databases using high-level, object-relational
mappings.
Finally, because JSP technology was developed through the Java Community
Process, 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
                              Microsoft IIS or Personal    Any Web server, including
Web Server
                              Web Server                   Apache, Netscape, and IIS
                                                           Most popular platforms,
                              Microsoft Windows            including the Solaris Operating
                              (Accessing other platforms   Environment, Microsoft
Platforms
                              requires third-party ASP     Windows, Mac OS, Linux, and
                              porting products.)           other UNIX platform
                                                           implementations
Reusable, Cross-Platform                                   JavaBeans, Enterprise
                              No
Components                                                 JavaBeans, custom JSP tags
Security Against System
                              No                           Yes
Crashes
Memory Leak Protection        No                           Yes
Scripting Language            VBScript, Jscript            Java
Customizable Tags             No                           Yes
Compatible with Legacy
                              Yes (COM)                    Yes (using JDBC API)
Databases
                                                           Works with any ODBC- and
Ability to Integrate with     Works with any ODBC-
                                                           JDBC technology-compliant
Data Sources                  compliant database
                                                           database
                                                           JavaBeans, Enterprise
Components                    COM components               JavaBeans, or extensible JSP
                                                           tags
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 a
generic protocol layered on the distributed computing environment (DCE) RPC
specification and facilitates the construction of task-specific communication protocols
through features. DCOM extends the Component Object Model (COM) to support
communication among objects on different computers-on a LAN, a WAN, or even
the Internet. With DCOM, an application can be distributed at locations that make the
most sense to customer and to the application. Because DCOM is a seamless
evolution of COM, developers can leverage their existing investment in COM-based


                                                                                        60
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




applications, components, tools, and knowledge to move into the world of standards-
based distributed computing. DCOM handles low-level details of network protocols
so developers can focus on their real business: providing great solutions to their
customers.
Both middleware technologies provide integration frameworks for object-based,
distributed client/server development. As such, both technologies provide full support
for 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 on
the desktop. Since 1989, CORBA has followed the path of developing the
architecture first and then the implementation. Microsoft, on the other hand, follows
the opposite path of “build first, then architect.” Unfortunately, CORBA’s “architect
first” distinction does not necessarily hold with the vendors of ORB products. As a
result, ORB vendors often provide services that are not in full compliance with the
CORBA specification.
From the outset, CORBA has concentrated on providing an open architecture to
support interoperability with both existing and new technologies. As evidence, neither
Java nor DCOM were defined at the time CORBA was originally specified; however,
significant progress has been made toward integrating these into the standard. This
is a testament to open nature of the CORBA reference architecture and the
collaborative nature of the OMG as a standards body.
DCOM has approached distribution and interoperability as an afterthought. This is
evident in the way that DCOM has evolved from DDE to OLE to OLE2 to ActiveX and
so on. However, this makes DCOM’s significance as a limited platform middleware
no less important. The often-cited problem with this approach is disruption to
previous iterations of technology and lack of interoperability.
Finally, CORBA has traditionally been heavily concentrated toward the mixed
platform server domain. The recent collaborations with Java have given CORBA
products a way to realize support for the client tier also. With ActiveX, DCOM
incorporates both client-side and server-side features. The homogenous nature of
the desktop has given DCOM less motivation for cross-platform support. With NT’s
maturation in the middle-tier, DCOM will most likely continue this trend.
As a conclusion, CORBA continues to be seen as the middleware of choice where
enterprise systems are made up of a wide variety of languages, platforms, and
operating systems. Although DCOM is rapidly evolving into a viable middleware for
NT platforms, it has yet to become practicable for real-world, heterogeneous
enterprise environments.



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


                                                                                   61
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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


                                             MTS                           EJB
                                 MTS supports Java, C++,
                                                                EJB supports platform-
                                 C, Visual Basic, Delphi, and
Language support                                                independent Java
                                 practically any other
                                                                programming language.
                                 development language.
                                                                EJB can run on any
                                                                platform. Implementations
                                                                are currently available on
                                                                Windows 95, NT, AS/400,
Platform support                 MTS runs only on NT.
                                                                and many flavors of Unix.
                                                                EJB implementations can be
                                                                find for almost every
                                                                operating system.
                                                                EJB supports Java clients
                                                                on any platform through
                                                                RMI, CORBA clients on any
                                 MTS supports ActiveX           platform through IIOP, and
                                 clients on Win32, WinCE,       Web clients through
Client support
                                 Internet Explorer, and IIS     servlets, Java Server Pages,
                                 Active Server Pages.           or similar Web extensions.
                                                                At least one EJB server
                                                                implementation (WebLogic)
                                                                supports ActiveX clients.
                                                                EJB components can be
                                 MTS components can run
Portability                                                     ported to any EJB-compliant
                                 only in MTS.
                                                                application server.
                                 EJB allows developers to override any EJB automatic
Flexibility                      service, including transactions, security, state
                                 management, and persistence. MTS doesn’t.




                                                                                         62
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




                                                                EJB supports both transient
                                                                and persistent objects
                                                                (Transient objects, called
                                 MTS views all objects as       session beans, can be
                                 stateless transient objects.   defined as either stateless
Type of objects                  A new object is created for    or stateful. State-less
                                 each user and for each         session beans are treated
                                 method call.                   exactly like MTS
                                                                components.) No code is
                                                                required within the object to
                                                                save the state.
                                 MTS doesn’t support            EJB persistent objects are
Persistence
                                 persistent objects.            called entity beans.
                                 EJB transactions are more versatile and simpler to use
Transactions
                                 than MTS.
As a conclusion, the architectures of MTS and EJB provide mechanisms for
developing distributed enterprise components. Though the mechanisms that they
employ to achieve their objective may be different, the approach each of them take
is more or less similar. But, EJB technology model delivers benefits that address the
most pressing concerns of enterprise development teams. EJB server-side
component model simplifies development of middleware components that are
transactional, scalable, and portable. EJB servers reduce the complexity of
developing middleware by providing automatic support for middleware services such
as transactions, security, database connectivity, and more. These include reduced
time-to-market for mission-critical applications, effortless scalability and portability,
reduced reliance on hard to find develop/designer skill sets, and an overall increase
in developer/designer productivity. EJB technology reduces the cost of developing
enterprise-scale applications, 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
supports the EJB standard, and any operating system.




                                                                                          63
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




4 Conclusions
This 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 IRIS
    design aid architecture;
The first objective was addressed by a brief presentation of the need for the IRIS
DSE and a discussion regarding the IRIS DSE position into the landscape of current
design aid tools, in reference to end-user and designer needs. Section 2 overviewed
the 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 people
with special needs) and will be further enhanced in terms of D0501int (Review of
directory services design approaches and technologies) and D0601int (Review of
directory services design approaches and technologies)) and illustrated the aspects
and the manner by which this work has started to be adopted, implemented and
extended.
Furthermore the positioning of the IRIS DSE in the context of other relevant
initiatives originating from other fora was made. It is identified that, at the business
level, IRIS does not directly compete with large IT vendors of Web development
software (e.g. such as Microsoft, or Macromedia) and tools because IRIS is not
building a classical Web development environment or tool, although there is some
degree of overlapping. The IRIS design support environment focuses on
functionalities that are not typical of classic development tools and therefore can act
synergistically with existing Web development environments and tools in order to
provide ‘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 these
issues: the work in terms of other workpackages is not yet finished and their input is
not finalized. The final view of the IRIS DSE architecture will be documented in
D0402 (Architectural design of design aid environment). However this first view is a
very important step in the project, as it will provide the initiating point of work on the
IRIS approach for design aid, architecture and technology.
At the conceptual level, the emphasis has been on to discussing the essence of the
IRIS DSE, its relationship with other basic elements of its environment and its
originating basic concepts. The IRIS Design Support Environment can be defined as
an organized set of methods, tools, guidelines, software applications, provided via
the 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 environment
is a new element in a typical design process, where a designer aims to understand a
design problem and produce a Web product with the use of a (set of) Web
development tool(s). The need for the design support environment is created from
the observation that the designer is engaged to solve a design problem that requires
a ‘Design for All’ approach, which cannot be offered by existing Web development
tools.
At the functional level, a first view of the IRIS DSE functional architecture was
presented. The presentation was made in terms of domains (a set of functional
components that have a similar purpose) and functional components (a concrete (set


                                                                                      64
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




of) component(s) that perform a specific function). The architecture identifies three
basic domains: interaction, design support and ‘Design for all’ knowledge. For each
domain, the top level functional components have been identified and discussed in a
manner independent of technology. This work however, is work in progress: the
functional components identified so far will be revisited during project developments
and external evaluations according to the project workplan.
At the technical level, an overview and discussion of existing services architectures
and technologies was made in order to identify the basic technologies to be used per
functional domain. This discussion compared three possible service architectures
upon a number of technical issues: a) Java 2 Enterprise Edition, b) Microsoft
Windows DNA and c) Java 2 Enterprise edition with COM support and secondly, at a
lower level of abstraction the criteria for technology selection were identified and a
number 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 dynamic
web scripting/programming that offer platform independence, enhanced
performance, separation of logic from display, ease of administration, extensibility
into the enterprise and most importantly, ease of use. Java and XML are a natural
match for the creation of applications that exploit the web of information where
different classes of clients consume and generate information that is exchanged
between different servers that run on varied system platforms.
Although DCOM is rapidly evolving into a viable middleware for NT platforms, it has
yet to become practicable for real-world, heterogeneous enterprise environments.
Therefore, CORBA continues to be seen as the middleware of choice where
enterprise systems are made up of a wide variety of languages, platforms, and
operating systems.
JTA and JTS allow application servers built on the Java 2 Platform, Enterprise
Edition to take the burden of transaction management off of the component
developer. Developers can define the transactional properties of Enterprise
JavaBeans technology based components during design or deployment using
declarative statements in the deployment descriptor. The application server takes
over the transaction management responsibilities.
SOAP has been developed to solve an old problem that arises when developing
applications for the Internet: interoperability. It facilitates accessing objects and
services on remote servers in a platform-independent manner. In order to
interoperate across the Internet both the client and server need to understand each
other’s security types and trusts, service deployment schemas, and implementation
details, and the same platform language. A major design goal for SOAP is simplicity
and extensibility. The client sends a request to a server to invoke an object, and the
server sends back the results. The messages themselves are formatted in XML, and
encapsulated in HTTP protocol messages. SOAP works with the existing Internet
infrastructure. 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 enterprise
components. This model delivers benefits that address the most pressing concerns
of enterprise development teams. EJB server-side component model simplifies
development of middleware components that are transactional, scalable, and
portable. EJB servers reduce the complexity of developing middleware by providing
automatic support for middleware services such as transactions, security, database



                                                                                   65
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




connectivity, and more. These include reduced time-to-market for mission-critical
applications, effortless scalability and portability, reduced reliance on hard to find
develop/designer skill sets, and an overall increase in developer/designer
productivity. EJB technology reduces the cost of developing enterprise-scale
applications, 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 supports
the EJB standard, and any operating system.
JDBC provides cross-DBMS connectivity to a wide range of SQL databases, and
provides 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's
capabilities for industrial strength, cross-platform applications that require access to
enterprise data. With a JDBC technology-enabled driver, a developer/designer can
easily connect all corporate data even in a heterogeneous environment.
Naming and directory services play a vital role in intranets and the Internet by
providing network-wide sharing of a variety of information about users, machines,
networks, services, and applications. Finding resources is of particular importance in
large-scale enterprise environments, where the applications may depend on services
provided by applications written by other groups in other departments.




                                                                                    66
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5 APPENDIX A: An in depth examination of technical
  components considered for IRIS DSE system
5.1 J2EE Platform Overview
The J2EE platform represents a single standard for implementing and deploying
enterprise applications. The J2EE platform has been designed through an open
process, engaging a range of enterprise computing vendors, to ensure that it meets
the widest possible range of enterprise application requirements.
The J2EE platform provides a multitier distributed application model. This means that
the various parts of an application can run on different devices. The J2EE
architecture 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 tier
supports a variety of client types, both outside and inside of corporate firewalls. The
middle tier supports client services through Web containers in the Web tier and
supports business logic component services through Enterprise JavaBeans (EJB)
containers in the EJB tier. The enterprise information system (EIS) tier supports
access 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 of
containers. Containers are standardized runtime environments that provide specific
component services. Components can expect these services to be available on any
J2EE platform from any vendor. For example, all J2EE Web containers provide
runtime support for responding to client requests, performing request time
processing (such as invoking JSP or servlet behavior), and returning results to the
client. All EJB containers provide automated support for transaction and life cycle
management of EJB components, as well as bean lookup and other services.
Containers also provide standardized access to enterprise information systems; for
example, providing RDBMS access through the JDBC API.
While the J2EE specification defines the component containers that must be
supported, 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 one
platform and EJB containers on another, or a J2EE platform can be made up of
multiple 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 the
enterprise firewall and outside. Clients can be offered through Web browsers by
using plain HTML pages, dynamic HTML generated with JavaServer Pages (JSP)
technology, or Java applets. Clients can also be offered as stand-alone Java
language applications. J2EE clients are assumed to access the middle tier primarily
using Web standards, namely HTTP, HTML, and XML.
To support more complex user interactions, it may be necessary to provide
functionality directly in the client tier. This functionality is typically implemented as
JavaBeans components that interact with the service in the middle tier via servlets.
Client-tier JavaBeans components would typically be provided by the service as an
applet that is downloaded automatically into a user's browser. To eliminate problems


                                                                                     67
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




caused by old or non-standard versions of the Java virtual machine in a user's
browser, the J2EE application model provides special support for automatically
downloading and installing the Java Plug-in.
Client-tier beans can also be contained in a stand-alone application client written in
the Java programming language. In this case, the enterprise would typically make
operating system specific installation programs for the client available for users to
download via their browsers. Users execute the installation file and are then ready to
access the service. Since Java technology programs are portable across all
environments, the service need only maintain a single version of the client program.
Although the client program itself is portable, installation of the Java technology
client typically requires OS-specific code. There are several commercial tools that
automate 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 as
Enterprise JavaBeans components (also referred to as enterprise beans). Enterprise
beans allow the component or application developer to concentrate on the business
logic while the complexities of delivering a reliable, scalable service are handled by
the EJB server.
The J2EE platform and EJB architecture have complementary goals. The EJB
component model is the backbone of the J2EE programming model. The J2EE
platform complements the EJB specification by:
•   Fully specifying the APIs that an enterprise bean developer can use to
    implement enterprise beans.
•   Defining the larger, distributed programming environment in which
    enterprise 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 among
these the J2EE specification, the EJB specification, the Servlet specification, and the
JSP specification. Together, these specifications define the architecture described in
this discussion. In addition to the specifications, several other offerings are available
to support the J2EE standard, including the J2EE Compatibility Test Suite and the
J2EE SDK. The J2EE Compatibility Test Suite (CTS) helps maximize the portability
of applications by validating the specification compliance of a J2EE platform product.
The J2EE SDK is intended to achieve several goals. First, it provides an operational
definition of the J2EE platform, used by vendors as the "gold standard" to determine
what their product must do under a particular set of application circumstances. It can
be used by developers to verify the portability of an application. And it is used as the
standard platform for running the J2EE Compatibility Test Suite.
Another important role for the J2EE SDK is to provide the developer community with
a freely available implementation of the J2EE platform to help expedite adoption of
the J2EE standard. Although it is not a commercial product and its licensing terms
prohibit its commercial use, the J2EE SDK is freely available in binary form to use in
developing application demos and prototypes. The J2EE SDK is also available in
source form.




                                                                                     68
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




The J2EE specifications have, by design, set the platform-compatibility-bar at a level
that's relatively easy to clear. Owing to the collaborative way in which the platform
specifications have been developed, it was deemed important to give platform
vendors 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 supporting
services not defined in the specifications.
It should therefore not be surprising that J2EE component portability is primarily a
function of the dependency a component has on the underlying container.
Components using a vendor-specific feature that falls outside of the J2EE
requirements may have limitations in the area of portability. The J2EE specifications
do 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 be
able to achieve. Needless to say, an application developer expecting to deploy on a
specific vendor implementation of the J2EE platform, should be able to do so across
a 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 distributed
application 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 application
development productivity in a number of ways.
Maps easily to application functionality: Component-based application models
map easily and flexibly to the functionality desired from an application. The J2EE
platform 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 data
sources, and other considerations. Component-based design also simplifies
application maintenance, since components can be updated and replaced
independently--new functionality can be shimmed into existing applications simply by
updating selected components.
Enables assembly- and deploy-time behaviors: Components can expect the
availability of standard services in the runtime environment, and can be dynamically
connected to other components providing well-defined interfaces. As a result, many
application behaviors can be configured at the time of application assembly or
deployment, without any recoding required. Component developers can



                                                                                   69
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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 application
development among specific skill sets, enabling each member of a development
team to focus on his or her ability. Thus, JSP templates can be created by graphic
designers, their behavior by Java programming language coders, business logic by
domain experts, and application assembly and deployment by the appropriate team
members. This division of labour also helps expedite application maintenance. For
example, the user interface is the most dynamic part of many applications,
particularly on the Web. With the J2EE platform, graphic designers can tweak the
look and feel of JSP-based user interface components without the need for
programmer intervention.
A number of generic roles are discussed in the J2EE specifications, including
Application Component Provider, Application Assembler, and Application Deployer.
On some development teams, one or two people may perform all these roles, while
on others, these tasks may be further subdivided into more specific skill sets (such
as user interface designers, programmers, and so on).

5.1.7 Scales Easily
J2EE containers provide a mechanism that supports simplified scaling of distributed
applications, without requiring any effort on the part of the application development
team.
Because J2EE containers provide components with transaction support, database
connections, life cycle management, and other features that influence performance,
they can be designed to provide scalability in these areas. For example, by providing
database connection pooling, containers can ensure that clients will have access to
data quickly.
Because the J2EE specifications allow server providers freedom to configure
containers to run on multiple systems, Web containers can be implemented to
perform automatic load balancing as the demand for a particular application
fluctuates.

5.1.8 Integrating Existing Enterprise Information Systems
The J2EE platform, together with the J2SE platform, includes a number of industry
standard APIs for access to existing enterprise information systems. Basic access to
these 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 coordinating
    transactions across heterogeneous enterprise information systems.
•   The Java Naming and Directory Interface (JNDI) is the API for accessing
    information in enterprise name and directory services.
•   The Java Message Service (JMS) is the API for sending and receiving
    messages via enterprise messaging systems like IBM MQ Series and
    TIBCO Rendezvous.
•   JavaMail is the API for sending and receiving email.
•   Java IDL is the API for calling CORBA services.


                                                                                   70
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




In addition, specialized access to enterprise resource planning and mainframe
systems such as IBM's CICS and IMS will be provided in future versions of J2EE
through the Connector architecture. Since each of these systems is highly complex
and specialized, they each require unique tools and support to ensure utmost
simplicity to application developers. As J2EE evolves, enterprise beans will be able
to combine the use of connector access objects and service APIs with middle-tier
business 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 for
servers, tools, and components. The J2EE brand on a server product ensures the
kind 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 expect
J2EE branded platforms from a variety of vendors, providing a range of choices in
hardware platforms, operating systems, and server configurations. This ensures that
businesses get a choice of servers appropriate to the strategic purpose of the
applications they need.
Designed for tool support: Both EJB and JSP components are designed to be
manipulated by graphical development tools, and to allow automating many of the
application development tasks traditionally requiring the ability to write and debug
code. Both J2EE server providers and third-party tool developers can develop tools
that conform to J2EE standards and support various application development tasks
and styles. Application developers get a choice of tools to manipulate and assemble
components, and individual team members may choose tools that suit their specific
requirements best.
A marketplace for components: Component-based design ensures that many
types of behavior can be standardized, packaged, and reused by any J2EE
application. Component vendors will provide a variety of off-the-shelf component
solutions, including accounting beans, user interface templates, and even vertical
market functionality of interest in specific industries. Application architects get a
choice of standardized components to handle common or specialized tasks.
The J2EE standard and associated branding programming ensure that solutions are
compatible. By setting the stage for freedom of choice, J2EE makes it possible to
develop 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 application
services. Component developers can specify the security requirements of a
component at the method level, to ensure that only users with appropriate
permissions can access specific data operations. While the EJB and Java Servlet
APIs both provide mechanisms for building security checks into code, the basic
mechanism for matching users with roles (groups of users having specific
permissions) is performed entirely at application deployment time. This provides both
greater flexibility and better security control.




                                                                                   71
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5.2 Web Server
5.2.1 Introduction
In general, Web servers serve content over the Internet using the Hyper Text
Markup Language (HTML). The Web server accepts requests from client-side user
agents, 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 power
of the server beyond its ability to deliver standard HTML pages. These include CGI
scripts, server-side includes, SSL security, JavaServer Pages, PHP and Active
Server Pages (ASPs).

5.2.2 Apache Project
The Apache Project is a collaborative software development effort aimed at creating
a robust, commercial-grade, full featured, and freely-available source code
implementation of an HTTP (Web) server. The project is jointly managed by of
volunteers located around the world, using the Internet and the Web to
communicate, plan, and develop the server and its related documentation. In
addition, hundreds of users have contributed ideas, code, and documentation to the
project. There is a core group of contributors that was formed from the project
founders and is augmented from time to time when core members nominate
outstanding contributors and the rest of the core members agree. The core group
focus is more on "business" issues and limited-circulation things like security
problems 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 HTTP
server for various modern desktop and server operating systems, such as UNIX and
Windows NT. The goal of this project is to provide a secure, efficient and extensible
server that provides HTTP services in sync with the current HTTP standards.

5.2.3 Apache HTTP Server
The Apache HTTP server is a powerful, flexible, HTTP/1.1 compliant web server. It
implements the latest protocols, including HTTP/1.1 (RFC2616).
It’s highly configurable and extensible with third-party modules and can be
customized by writing “modules” using the Apache module API. It provides full
source code and comes with an unrestrictive license and is actively being developed
and encourages user feedback through new ideas, bug reports and patches. It runs
on Windows NT/9x, Netware 5.x, OS/2, and most versions of Unix, as well as
several 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, without
        bogging 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 errors
        and problems, e.g. setup a script to intercept 500 Server Errors and perform
        on-the-fly diagnostics for both users and the administrator.


                                                                                   72
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




    •   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 the
        configuration files. In addition, a powerful rewriting engine can be used to
        solve most URL manipulation problems.
    •   Content negotiation i.e. the ability to automatically serve clients of varying
        sophistication and HTML level compliance, with documents which offer the
        best representation of information that the client is capable of accepting.
    •   Virtual Hosts. A much requested feature, sometimes known as multi-homed
        servers. This allows the server to distinguish between requests made to
        different IP addresses or names (mapped to the same machine). Apache
        also offers dynamically configurable mass-virtual hosting.
    •   Configurable Reliable Piped Logs. You can configure Apache to generate
        logs 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 DNS
        resolving on the fly.

5.2.4 Features and performances
Apache version 1.1 and above comes with a proxy module. If compiled in, this will
make Apache act as a caching-proxy server.
"Multiviews" is the general name given to the Apache server's ability to provide
language-specific document variants in response to a request. This is documented
quite thoroughly in the content negotiation description page.
SSL (Secure Socket Layer) data transport requires encryption, and many
governments have restrictions upon the import, export, and use of encryption
technology. If Apache included SSL in the base package, its distribution would
involve all sorts of legal and bureaucratic issues, and it would no longer be freely
available. Also, some of the technology required to talk to current clients using SSL
is patented by RSA Data Security, who restricts its use without a license. Some SSL
implementations of Apache are available, however.
Apache does not include a search engine, but there are many good commercial and
free search engines which can be used easily with Apache.
Apache has been shown to be substantially faster, more stable, and more full
featured than many other web servers. Apache is run on sites that get millions of hits
per day, and they have experienced no performance difficulties.
Apache is run on over 6 million Internet servers (as of February 2000). It has been
tested thoroughly by both developers and users. The Apache Group maintains
rigorous standards before releasing new versions of their server. When bugs do
show 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 on
the Internet are using Apache (around 62% if Apache derivatives are included), thus
making 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 connected
computers.


                                                                                          73
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5.3 Web Applications and Web Containers
5.3.1 Introduction
In 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 directory
structure or archived format known as a Web ARchive (WAR) file. A Web application
is 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 application
runs within a Web container of a Web server. A Web container provides Web
components with a naming context and life cycle management. Some Web servers
may also provide more services, such as security, concurrency, transactions, and
swapping to secondary storage. A Web server may work with an EJB server to
provide such services. A Web server need not be located on the same machine as
the EJB server. In some cases, a Web container may communicate with other Web
containers.

5.3.2 JavaServer Pages (JSP) and Java Servlet Technologies
JavaServer Pages (JSP) technology allows web developers and designers to
rapidly develop and easily maintain, information-rich, dynamic web pages that
leverage existing business systems. As part of the Java family, JSP technology
enables rapid development of web-based applications that are platform independent.
JavaServer Pages technology separates the user interface from content generation
enabling designers to change the overall page layout without altering the underlying
dynamic content.
Java Servlet technology provides web developers with a simple, consistent
mechanism for extending the functionality of a web server and for accessing existing
business systems. A servlet can almost be thought of as an applet that runs on the
server side -- without a face. Java servlets have made many web applications
possible. Servlets have access to the entire family of Java APIs, including the JDBC
API to access enterprise databases. Servlets can also access a library of HTTP-
specific calls and receive all the benefits of the mature Java language, including
portability, performance, reusability, and crash protection.

5.3.3 Tomcat as JSP/Servlet Container
Tomcat is the Reference Implementation for the Java Servlet 2.2 and JavaServer
Pages 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 from
around the world. Sun will continue responsibility for the Servlet API and JavaServer
Pages specifications, which are being developed under the Java Community
Process.
Tomcat is a servlet container and JavaServer Pages implementation. It may be used
either 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 or
later - Microsoft Personal Web Server, version 4.0 or later - Netscape Enterprise
Server, version 3.0 or later.



                                                                                   74
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5.3.4 Conjunction With Apache
Tomcat currently supports three modes of execution. Although it is entirely possible
to have Tomcat serve both static and dynamic document provision needs, there are
several 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 in
        Apache 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 as
a Servlet/JSP add-on.
In a nutshell a web server is waiting for requests. When these requests arrive the
server does whatever is needed to serve the requests by providing the necessary
content. Adding Tomcat to the mix may somewhat change this behaviour. Now the
web server needs to perform the following:
    •   Before the first request can be served, Apache needs to load a web server
        adapter (how Tomcat will communicate with Apache) library and initialise it.
    •   When a request arrives, Apache needs to check and see if it belongs to a
        servlet, 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 html
        documents, and to forward all requests for dynamic content to Tomcat.




                                                                                   75
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5.4 XML Processing
5.4.1 Introduction
XML (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 to
read, process, and generate. Java is an ideal companion to XML: both languages
share a similar historical background (C++, SGML); both have goals of simplicity,
portability, and flexibility; and both continue to be developed in groups that involve
industry, 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 and
Java make them the ideal choice for the flexibility and wide availability requirements
of this new web.

5.4.2 Java API for XML Parsing (JAXP) 1.1 Requirements
JAXP includes the industry standard SAX and DOM APIs, as well as a pluggability
API that allows SAX and DOM parsers and XSLT transform engines to be plugged
into the framework, and allows applications to find parsers that support the features
needed by the application.
All J2EE products must meet the JAXP conformance requirements and must provide
at least one SAX 2 parser, at least one DOM 2 parser, and at least one XSLT
transform engine. There must be a SAX parser or parsers that support all
combinations of validation modes and namespace support. There must be a DOM
parser or parsers that support all combinations of validation modes and namespace
support.

5.4.3 Apache XML Project
The goals of the Apache XML Project are:
    •   To provide commercial-quality standards-based XML solutions that are
        developed in an open and cooperative fashion,
    •   To provide feedback to standards bodies (such as IETF and W3C) from an
        implementation 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 on
a different aspect of XML: Xerces (XML parsers in Java, C++, with Perl and COM
bindings), Xalan (XSLT stylesheet processors, in Java and C++), Cocoon (XML-
based web publishing, in Java), FOP (XSL formatting objects, in Java), Xang (Rapid
development of dynamic server pages, in JavaScript), SOAP - Simple Object Access
Protocol, Batik - A Java based toolkit for Scalable Vector Graphics (SVG) and
Crimson - A Java XML parser derived from the Sun Project X Parser.

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


                                                                                    76
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




Cocoon is a 100% pure Java publishing framework that relies on new W3C
technologies (such as DOM, XML, and XSL) to provide web content.
The new Cocoon paradigm is based on the fact that document content, style and
logic are often created by different individuals or working groups. Cocoon aims for a
complete separation of the three layers, allowing the three layers to be
independently 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 be
separated out into different XML files, and uses XSL transformation capabilities to
merge them.
Even if the most common use of Cocoon is the automatic creation of HTML through
the processing of statically or dynamically generated XML files, Cocoon is also able
to 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 different
presentations of the same data depending on the requesting client (HTML clients,
PDF clients, WML clients) and separating out different contexts with different
requirements, skills and capacities.
To do this, the Cocoon model divides the development of web content into three
separate levels:
    •   XML creation - The XML file is created by the content owners. They do not
        require specific knowledge on how the XML content is further processed -
        they only need to know about the particular chosen "DTD" or tag set for their
        stage in the process. (As one would expect from a fully generic XML
        framework, DTDs are not required in Cocoon, but can be used and validated
        against). This layer is always performed by humans directly, through normal
        text editors or XML-aware tools/editors.
    •   XML processing - The requested XML file is processed and the logic
        contained in its logicsheet(s) is applied. Unlike other dynamic content
        generators, the logic is separated from the content file.
    •   XSL rendering - The created document is then rendered by applying an XSL
        stylesheet 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 to
process the document layers are complex and not designed for real-time operation
on the server side. For this reason, Cocoon is designed to be a page compiler for
dynamic pages, trying to hardcode, whenever possible, those layers in precompiled
binary code coupled with an adaptive and memory-wise cache system for both static
and dynamic pages. A key development goal is performance improvement of both
processing subsystems as well as the creation and testing of special cache systems.

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


                                                                                   77
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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




                                                                                   78
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5.5 Enterprise JavaBeans (EJB) Container
5.5.1 Introduction
In a multitier J2EE application, the EJB-tier hosts application-specific business logic
and system-level services such as transaction management, concurrency control,
and security. EJB technology provides a distributed component model that enables
developers to focus on solving business problems while relying on the J2EE platform
to handle complex system-level issues. This separation of concerns allows rapid
development of scalable, accessible, and highly secure applications. In the J2EE
programming model, EJB components are a fundamental link between presentation
components hosted by the Web tier and business-critical data and systems
maintained in the enterprise information system tier.

5.5.2 EJB container
Enterprise Java Beans run within a container, which controls the beans and provides
them with system services. The services a container offers are:
    •   Transactions. The EJB specification provides transactional semantics for
        components, allowing the component developer to specify transactional
        properties of components.
    •   Security.
    •   Remote access (RMI).
    •   Life cycle management.
    •   Database connection pooling. To provide efficient access to databases it is
        better to make clients share database connections – this means a new
        database 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 a
        database connection it gets an already opened connection to use so there is
        no start-up time. When the client doesn't need the connection any more, it's
        returned to the pool so that it can be reused. The EJB server handles this
        pooling.

5.5.3 JBoss/Server As EJB Container
The JBoss/Server is an Open Source, standards-compliant, EJB application server
implemented in 100% Pure Java, as is our full product suite. The JBoss community
of over 500 developers worldwide is working to deliver the full range of J2EE tools as
the premier Enterprise Java application server for the Java 2 Enterprise Edition
(J2EE) platform. The JBoss/Server and complement of products are delivered under
a public license.
JBoss 2.0 also standardizes on JMX (Java Management eXtension) to offer
standard interfaces to the management of its components as well as the applications
deployed on it.
JBoss is an implementation of the EJB 1.1 (and parts of 2.0) specification, that is, it
is a server and container for EJB. In this it is similar to Sun's “J2SDK Enterprise
Edition” (J2EE), but JBoss is much more single-minded than J2EE. The JBoss core
server provides only an EJB server; it does not include support for JSP, SSL, and all


                                                                                   79
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




the other protocols that the Sun product can handle. Because of its small memory
footprint, JBoss starts up about 10 times faster than Sun’s J2EE. There is a built-in
SQL database server for handling persistent beans, and this starts up automatically
with the server (J2EE ships with the CloudScape SQL server, which has to be
started separately).
One of the nicest features of JBoss is its support for “hot” deployment. What this
means is that deploying a Bean is a simple as copying its JAR file into the
deployment directory. If this is done while the Bean is already loaded, JBoss
automatically unloads it, then loads the new version. Contrast this with the rigmarole
that 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 that
way. You get no support, of course.
Being both open and standards-compliant, JBoss/Server supports both EJB Session
Beans and Entity Beans.

5.5.4 Modular Server Design
Modularly developed from the ground up, the JBoss server and container are
completely implemented using component-based plug-ins.
The modularisation effort is supported by the use of JMX, the Java Management
eXtension API. Using JMX, industry-standard interfaces help us manage both
JBoss/Server components and the applications deployed on it. Ease of use is still the
number one priority here at JBoss.org, and JBoss/Server 2.0 sets a new standard for
both 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 that
must have a very small footprint. For example, if EJB passivation is unnecessary in
your application, simply take the feature out of the server. However, if you later
decide to deploy the same application under an Application Service Provider (ASP)
model, simply enable the server's passivation feature for that Web-based
deployment.

5.5.5 Features That Speed Development
In 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 grunt
work out of EJB application development.
First there's dynamically, runtime-generated stub and skeleton classes. In many
commercial EJB servers the generation of these classes must be performed in an
additional step prior to deployment. It goes without saying that this extra step
requires 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 each
deployment. As an added benefit, the method used by JBoss/Server to accomplish
this time- and effort-savings feature also saves memory and other server resources
since only a single server object supports every deployed Enterprise JavaBeans
component.




                                                                                   80
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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 order
to successfully deploy your application changes. However, JBoss/Server allows you
to deploy new applications and redeploy existing applications without stopping and
restarting the server. In fact, the feature is as easy as copying your newly built EJB
JAR file to the server deployment directory where JBoss/Server picks up the new
file, automatically undeploys the old JAR (if any) and deploys the new JAR within
seconds. This feature definitely provides the benefit of slicing minutes off of each
change-compile-deploy cycle.

5.5.6 Tomcat and JBoss - A Full J2EE Stack
The JBoss organization wants to deliver a complete J2EE based product to the
market. The JBoss organization decided to integrate the Tomcat engine stack with a
running version of JBoss in a single VM.
Now, they run optimised stacks the JSP/Servlet engine talks natively with the EJB
engine resulting in dramatic speed increases. Without the optimisation the invocation
is through the network layer. With the optimised layers the invocation is native, inVM,
within the same stack of APIs.

5.5.7 Data Sources
One of the most common requirements is to create one or more data sources for
your EJBs. A data source for CMP entity beans must be created, and it is the
recommended way to interact with a database for BMP entity beans and session
beans.
JBoss data sources provide database connection pooling. This means that when
application 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 reuse
the same connection. This saves you the overhead of opening new database
connections for every request, and since normal web applications use connections
very 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 database
connection that is left unused in the pool for a long period of time may timeout. The
JBoss 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-ODBC
bridge (type 1).
The mappings available for CMP that have been tested extensively include
PostgreSQL, InstantDB, Hypersonic SQL, Oracle 7, Oracle 8, Sybase, DB2, and
InterBase. Additional contributed mappings include PointBase, SOLID, mySQL, MS
SQL Server, and DB2/400.




                                                                                   81
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5.6 Interoperability Assurance
The interoperability of the variety of services that the IRIS DSE will support can be
ensured by the use of the Simple Object Access Protocol and the Web Services
Description Language.

5.6.1 SOAP
Simple Object Access Protocol (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 message and how to process it, a set of encoding rules for expressing
instances of application-defined datatypes, and a convention for representing remote
procedure calls and responses. SOAP can potentially be used in combination with a
variety of other protocols.
SOAP has been developed to solve an old problem that arises when developing
applications for the Internet: interoperability. It facilitates accessing objects and
services on remote servers in a platform-independent manner. In order to
interoperate across the Internet both the client and server need to understand each
other’s security types and trusts, service deployment schemas, and implementation
details, and the same platform language (e.g. COM to COM, ORB to ORB, EJB to
EJB, etc.).
SOAP is simple. The client sends a request to a server to invoke an object, and the
server sends back the results. The messages themselves are formatted in XML, and
encapsulated in HTTP protocol messages. SOAP works with the existing Internet
infrastructure. You don't need to make any special accommodations on any of your
routers, 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.1
      Host: www.stockquoteserver.com
      Content-Type: text/xml; charset="utf-8"
      Content-Length: nnnn
      SOAPAction: "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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




The XML code is straightforward, as well: the elements Envelope and Body provide a
generic payload packaging mechanism; the element <GetLastTradePrice> contains
an element called <symbol>, which contains a stock ticker symbol. The purpose of
this request is obvious: get the last trading price for a specific stock -- in this case
Disney (DIS).
The program that sends this message needs to understand only how to format a
SOAP request: the HTTP header formation, and the XML formats needed to frame
the request. In this case, the program knows this is the way to format a request for a
stock price. The HTTP server receiving this message knows that it is a SOAP
message because it recognizes the HTTP header SOAPMethodName; it then does
something to deliver or process the message appropriately. For example, a typical
response may be:

      HTTP/1.1 200 OK
      Content-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 XML
standard, SOAP bridges the gap between competing object RPC technologies and
provides a light-weight messaging format that works with any operating system, any
programming language, and any platform.
In order to utilize a service on a remote server using SOAP, a program needs to
understand what the remote service is capable of and not understanding the remote
service's implementation (platform specific information). SOAP provides a way to
query the remote service and learn about its capabilities, such as how it represents
data types and commands.

5.6.2 Apache SOAP
Apache SOAP is an open-source implementation of the SOAP v1.1 and SOAP
Messages with Attachments specifications in Java. Apache SOAP is developed by
the Apache SOAP community.
Apache SOAP can be used as a client library to invoke SOAP services available
elsewhere or as a server-side tool to implement SOAP accessible services. As a
client library it provides an API for invoking SOAP RPC services as well as an API for
sending and receiving SOAP messages. As a mechanism to write new RPC
accessible services or message accessible services, it expects to be hosted by a
servlet container (such as Apache Tomcat, for example). While the codebase can be
extended to support non-HTTP transports, the provided code only has limited
support for non-HTTP transports (specifically, only for SMTP).




                                                                                    83
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




5.6.2.1 Requirements & Limitations
Apache SOAP has the following requirements:
    •   Java 1.1 or higher, and a servlet engine supporting version 2.1 or higher of
        the 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 that
        order.
    •   Implementing services in scripting languages requires the use of Bean
        Scripting Framework.
    •   SSL (HTTPS) support requires Java 1.2.1 or later and the Java Secure
        Socket 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 section
        4.1.1 of the spec)
    •   mustUnderstand attribute support - only supports checking for and rejecting
        requests 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) / Web
    services
Web services using XML standards is a new paradigm in the way B2B collaborations
are modeled. It provides a conceptual and architectural foundation, which can be
implemented using a variety of platforms and products. Today, developers can use
the Java 2 Enterprise Edition (J2EE) to build XML-based web services. They can
leverage existing J2EE technologies to build a complete and fully interoperable web
service that complies with XML standards.
Web Services can be described as follows:




                                                                                   84
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




    •   Web Services are self-contained, modular applications that can be described,
        published, located, and invoked over a network, generally, the World Wide
        Web.
    •   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 as
        service category, service description, and expiration date, as well as business
        information about the service provider, such as company name, address, and
        contact information. A Network-Accessible Service Specification Language
        (NASSL) document describes operational information about the service, such
        as service interface, implementation details, access protocol, and contact
        endpoints.
    •   A Web Services architecture implementation should allow for incremental
        security and quality of service models facilitated by configuring a set of
        environmental prerequisites (for example, authentication mechanism, billing,
        and so on) to control and manage the interactions.
    •   Web Services can be dynamically composed into applications stemming from
        capabilities-based look-up at runtime, instead of the traditional static binding.
        The dynamic nature of the collaborations allow the implementations to be
        platform- and programming language-neutral, and communications
        mechanism-independent, while creating innovative products, processes, and
        value chains.

5.7.1 WSDL
As communications protocols and message formats are standardized in the web
community, it becomes increasingly possible and important to be able to describe
the communications in some structured way. WSDL addresses this need by defining
an XML grammar for describing network services as collections of communication
endpoints capable of exchanging messages. WSDL service definitions provide
documentation for distributed systems and serve as a recipe for automating the
details 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 a
business with the service needed, discover the call interface and semantics, and
write or configure software on their end to collaborate with the service. Therefore a
vehicle to publish web services is required.
UDDI is a project aimed towards providers and seekers of web services. The
members of the UDDI Project operate a web service called the UDDI Business
Registry (UBR), which is global, public directory of businesses and services. Web
service providers can register and describe their services in the UBR. Users can
query the UBR to discover web services and to locate information needed to
interoperate with the services.
UDDI is a mechanism to direct systems looking for certain services to documentation
that describes them. UDDI contains the standard “white pages”- type business



                                                                                     85
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




search and “yellow pages”- type topical search, as well as a “green pages”- type
service type search. It is this “green pages” search that will allow a developer to find
all 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 XML
schema for encapsulating the various types of data that may be returned or sent to
the registry service.




                                                                                    86
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




6 References
Anne Thomas, Comparing MTS and EJB, December 1998, Available at: http://java.sun.com/
Anne Thomas, Java™ 2 Platform, Enteprise Edition, Ensuring Consistency, Portability and
    Interoperability, 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 Draft
      3, 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 Note
     08 May 2000. Available at: http://www.w3.org/TR/SOAP/
Chisholm, W. Vanderheiden, G. Jacobs, I. (editors) (1999) Web Content Accessibility
     Guidelines (WCAG), W3C Recommendation 5 May 1999.
Christensen, E., Curbera, F., Meredith, G. and Weerawarana, S. (2001). Web Services
     Description 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 Analysis
   of 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 over
    COM+ and Windows DNA, Prepared for Sun Microsystems Inc., The Middleware
    Company December 1999, Available at: http://java.sun.com/
Ed Roman and Rickard Öberg, The Technical Benefits of EJB and J2EE Technologies over
    COM+ and Windows DNA, Prepared for Sun Microsystems Inc., The Middleware
    Company 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
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




     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) Designing
    Internet-based Systems and Services for All: Problems and Solutions, to appear in
    Proceedings of 1st International Conference on Universal Access in Human-Computer
    Interaction, 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&D
     recommendations, 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 Tool
     Accessibility 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 accessibility
    issues. 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 and
    Francis (London).
Velasco, C.A. (2001b) Evaluation and training on accessibility guidelines; to appear in
    Proceedings of 1st International Conference on Universal Access in Human-Computer
    Interaction, August 5-10, 2001 New Orleans, LA, USA.




                                                                                            88
IRIS Project IST-2000-26211
Deliverable number : D0401
Title of Deliverable: Recommendations for Design Aid Approaches and Technologies




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




                                                                                    89