oracle ra user interaction r3!0!359326

8/4/2019 Oracle Ra User Interaction r3!0!359326

1/62

Oracle Reference Architecture User Interaction Release 3.0

E16349-03

April 2011


2/62

ORA User Interaction, Release 3.0

E16349-03

Copyright 2011, Oracle and/or its affiliates. All rights reserved.

Primary Author: Bob Hensle

Contributing Author: Cliff Booth, Dave Chappelle, Jeff McDaniels, Mark Wilkins, Steve Bennett

Contributor: Tim Breeden, Ron SchweikertWarranty Disclaimer

THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") ISPROVIDED ON AN "AS IS" BASIS AND FOR GENERAL INFORMATION PURPOSES ONLY. ORACLEEXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESSFOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. ORACLE MAKES NO WARRANTY THATTHE INFORMATION IS ERROR-FREE, ACCURATE OR RELIABLE. ORACLE RESERVES THE RIGHT TOMAKE CHANGES OR UPDATES AT ANY TIME WITHOUT NOTICE.

As individual requirements are dependent upon a number of factors and may vary significantly, you shouldperform your own tests and evaluations when making technology infrastructure decisions. This documentis not part of your license agreement nor can it be incorporated into any contractual agreement with OracleCorporation or its affiliates. If you find any errors, please report them to us in writing.

Third Party Content, Products, and Services Disclaimer

This document may provide information on content, products, and services from third parties. Oracle is notresponsible for and expressly disclaim all warranties of any kind with respect to third-party content,products, and services. Oracle will not be responsible for any loss, costs, or damages incurred due to youraccess to or use of third-party content, products, or services.

Limitation of Liability

IN NO EVENT SHALL ORACLE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL ORCONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR USE,INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT,ARISING FROM YOUR ACCESS TO, OR USE OF, THIS DOCUMENT OR THE INFORMATION.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarksof their respective owners.


3/62

iii

Contents

Send Us Your Comments ........................................................................................................................ ix

Preface ................................................................................................................................................................. xi

Audience....................................................................................................................................................... xiHow to Use This Document....................................................................................................................... xi

Document Structure.................................................................................................................................... xiRelated Documents .................................................................................................................................... xiiConventions ............................................................................................................................................... xiii

1 User Interaction Overview

1.1 User Interaction........................................................................................................................... 1-11.1.1 Rich Internet Apps............................................................................................................... 1-21.1.2 Collaboration........................................................................................................................ 1-21.1.3 Mobile.................................................................................................................................... 1-31.1.4 Desktop Apps....................................................................................................................... 1-31.1.5 Single Sign-on....................................................................................................................... 1-31.1.6 Application Access .............................................................................................................. 1-41.1.7 Worklist ................................................................................................................................. 1-41.1.8 Content Access ..................................................................................................................... 1-41.1.9 Notifications ......................................................................................................................... 1-51.1.10 Personalization and Customization.................................................................................. 1-51.2 Difference from Traditional User Interfaces ........................................................................... 1-61.2.1 Traditional User Interfaces................................................................................................. 1-61.2.2 Modern User Interface ........................................................................................................ 1-71.2.2.1 Display Devices ............................................................................................................ 1-81.2.2.2 Unified User Interface.................................................................................................. 1-81.2.2.3 User Interface Services................................................................................................. 1-81.2.2.4 Access and Incorporation............................................................................................ 1-81.2.2.5 Backend Systems .......................................................................................................... 1-91.3 Complementary Technologies .................................................................................................. 1-91.3.1 Enterprise 2.0 ........................................................................................................................ 1-91.3.2 Content Management.......................................................................................................... 1-91.3.3 Service Oriented Architecture......................................................................................... 1-101.3.4 Business Process Management ....................................................................................... 1-101.3.5 Interactive Voice Response.............................................................................................. 1-10


4/62

iv

1.3.6 Identity Management....................................................................................................... 1-10

2 User Interaction Principles

2.1 Display Device Support ............................................................................................................. 2-12.2 User Interaction Adaptability ................................................................................................... 2-12.3 Unified User Experience ............................................................................................................ 2-22.4 Physical Separation..................................................................................................................... 2-22.5 Secure Interactions...................................................................................................................... 2-22.6 Development for Disparate Display Devices.......................................................................... 2-32.7 Rapid Development.................................................................................................................... 2-32.8 Access to Functionality .............................................................................................................. 2-32.9 Meta-data Support ...................................................................................................................... 2-42.10 Performance................................................................................................................................. 2-4

3 Industry Standards

3.1 W3C Standards............................................................................................................................ 3-1

3.1.1 HTTP...................................................................................................................................... 3-13.1.2 URI ......................................................................................................................................... 3-13.1.3 HTML, XHTML, CSS........................................................................................................... 3-23.1.4 AJAX ...................................................................................................................................... 3-23.2 Java Standards ............................................................................................................................. 3-23.2.1 JSR 227: A Standard Data Binding & Data Access Facility for J2EE............................. 3-33.2.2 JSR 245: Java Server Pages 2.1 ............................................................................................ 3-33.2.3 JSR 286: Portlet Specification 2.0........................................................................................ 3-33.2.4 JSR 314: Java Server Faces 2.0............................................................................................. 3-43.2.5 JSR 315: Java Servlet 3.0 Specification............................................................................... 3-43.2.6 JSR 329: Portlet 2.0 Bridge for JavaServer Faces 1.2 Specification ................................ 3-4

3.2.7 JSR 333: Content Repository for Java Technology API Version 2.1.............................. 3-43.2.8 JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services....................................... 3-43.3 OASIS Standards......................................................................................................................... 3-53.3.1 WSRP 2.0 ............................................................................................................................... 3-53.3.2 CMIS ...................................................................................................................................... 3-53.4 Other Standards .......................................................................................................................... 3-53.4.1 MIME Types ......................................................................................................................... 3-53.4.2 Atom ...................................................................................................................................... 3-53.4.3 RSS 2.0 ................................................................................................................................... 3-6

4 User Interaction Reference Architecture4.1 Logical View ................................................................................................................................ 4-14.1.1 Display Devices.................................................................................................................... 4-24.1.2 Client Tier ............................................................................................................................. 4-24.1.2.1 Controller....................................................................................................................... 4-24.1.2.2 State Management ........................................................................................................ 4-24.1.2.3 Rendering ...................................................................................................................... 4-24.1.2.4 Composition .................................................................................................................. 4-34.1.2.5 Data Management ........................................................................................................ 4-3


5/62

v

4.1.2.6 Security Container........................................................................................................ 4-34.1.2.7 Communication Services............................................................................................. 4-34.1.3 Standard Communication Protocols................................................................................. 4-44.1.4 Service Tier ........................................................................................................................... 4-44.1.4.1 Service Invocation ........................................................................................................ 4-44.1.4.2 Personalization.............................................................................................................. 4-4

4.1.4.3 Customization............................................................................................................... 4-54.1.4.4 Collaboration................................................................................................................. 4-54.1.4.5 Search ............................................................................................................................. 4-54.1.4.6 Notification.................................................................................................................... 4-54.1.4.7 Tagging .......................................................................................................................... 4-54.1.4.8 Process Participation.................................................................................................... 4-64.1.4.9 Social Networking ........................................................................................................ 4-64.1.4.10 Syndication .................................................................................................................... 4-64.1.4.11 Page Flow....................................................................................................................... 4-64.1.4.12 Portal Framework......................................................................................................... 4-64.1.4.13 Presence & Location ..................................................................................................... 4-7

4.1.4.14 Administration.............................................................................................................. 4-74.1.4.15 Multi-Channel Delivery............................................................................................... 4-74.1.4.16 Federation ...................................................................................................................... 4-74.1.4.17 Analytics ........................................................................................................................ 4-84.1.4.18 Connectivity .................................................................................................................. 4-84.1.5 Resources .............................................................................................................................. 4-84.1.5.1 Content........................................................................................................................... 4-84.1.5.2 Databases ....................................................................................................................... 4-84.1.5.3 Business Intelligence.................................................................................................... 4-84.1.5.4 Applications .................................................................................................................. 4-84.1.5.5 Business Services .......................................................................................................... 4-94.1.5.6 Remote Providers ......................................................................................................... 4-94.1.6 Development Tools.............................................................................................................. 4-94.1.6.1 IDE .................................................................................................................................. 4-94.1.6.2 Declarative Development............................................................................................ 4-94.1.6.3 UI Frameworks .......................................................................................................... 4-104.1.6.4 Visual Development.................................................................................................. 4-104.1.7 MetaData Repository........................................................................................................ 4-104.1.8 Security............................................................................................................................... 4-114.1.8.1 Access Management.................................................................................................. 4-114.1.8.2 Credential Management ........................................................................................... 4-114.1.8.3 Identity Propagation ................................................................................................. 4-114.1.8.4 Message Security ....................................................................................................... 4-114.2 Development View .................................................................................................................. 4-114.2.1 MVC Pattern...................................................................................................................... 4-124.2.2 Modular Programming.................................................................................................... 4-134.2.3 Federation .......................................................................................................................... 4-134.3 Process View............................................................................................................................. 4-144.3.1 Simple User Request......................................................................................................... 4-144.3.2 Search Request .................................................................................................................. 4-15


6/62

vi

4.4 Deployment View .................................................................................................................... 4-164.4.1 Physical Deployment ....................................................................................................... 4-164.4.2 Federated Deployment .................................................................................................... 4-17

5 Product Mapping

5.1 Products Included....................................................................................................................... 5-15.2 Products as Resources ................................................................................................................ 5-35.2.1 Content .................................................................................................................................. 5-35.2.2 Databases .............................................................................................................................. 5-35.2.3 Business Intelligence ........................................................................................................... 5-45.2.4 Applications.......................................................................................................................... 5-45.3 Product Mapping ........................................................................................................................ 5-45.4 Deployment View ....................................................................................................................... 5-5

6 Summary

A Further Reading


7/62

vii


8/62


9/62

ix

Send Us Your Comments

ORA User Interaction, Release 3.0E16349-03

Oracle welcomes your comments and suggestions on the quality and usefulness of thispublication. Your input is an important part of the information used for revision.

Did you find any errors? Is the information clearly presented? Do you need more information? If so, where? Are the examples correct? Do you need more examples? What features did you like most about this document?

If you find any errors or have any other suggestions for improvement, please indicatethe title and part number of the documentation and the chapter, section, and pagenumber (if available). You can send comments to us at [email protected].


10/62

x


11/62

xi

Preface

This document describes concepts, standards, principles, and a reference architecturefor a modern user interface in an IT environment. The reference architecture isdescribed in a product agnostic way since the architecture does not require anyspecific products; rather, it is based on industry and Oracle best practices for userinteraction. The document describes the key capabilities of a modern user interfaceand how this differs from more traditional user interface approaches. The principlesthat are essential to a modern user interface are listed and described. These principlesprovide the foundation and requirements for the reference architecture which is thenillustrated and described. Finally, Oracle products are mapped onto the architecture toillustrate how to realize the architecture using Oracle products.

Audience This document is intended for Enterprise Architects and Solution Architects who wantto understand modern user interaction and how to create an architecture that supportsa rich, user-centric system interaction. Some level of understanding of user interfaceconcepts and design is required since this document is not intended to provide aprimer for user interface design.

How to Use This Document This document is intended to be read from start to finish. However, each section isrelatively self contained and could be read independently from the other sections. Thisdocument can be used to understand modern user interfaces or as a blueprint forcreating an architecture to support modern user interactions.

Document Structure This document is organized in sections that first introduce and describe userinteraction and then describes an architecture that is based on and supports a modernuser interface. Specifically, Chapter 1 provides a description of user interaction and how this differs from

more traditional user interface approaches. Chapter 2 identifies the principles that should be met by any architecture that

purports to support modern user interfaces. Chapter 3 identifies the standards that are of particular relevance to a user

interface architecture.


12/62

xii

Chapter 4 describes a reference architecture for modern user interfaces fromvarious viewpoints.

Chapter 5 maps Oracle products onto the architecture to illustrate how Oracleproducts can be used to realize the architecture.

Chapter 6 is a brief summary of the document contents.

Related Documents IT Strategies from Oracle (ITSO) is a series of documentation and supportingmaterial designed to enable organizations to develop an architecture-centric approachto enterprise-class IT initiatives. ITSO presents successful technology strategies andsolution designs by defining universally adopted architecture concepts, principles,guidelines, standards, and patterns.

ITSO is made up of three primary elements: Oracle Reference Architecture (ORA) defines a detailed and consistent

architecture for developing and integrating solutions based on Oracletechnologies. The reference architecture offers architecture principles and guidance

based on recommendations from technical experts across Oracle. It covers a broadspectrum of concerns pertaining to technology architecture, includingmiddleware, database, hardware, processes, and services.

Enterprise Technology Strategies (ETS) offer valuable guidance on the adoptionof horizontal technologies for the enterprise. They explain how to successfullyexecute on a strategy by addressing concerns pertaining to architecture,technology, engineering, strategy, and governance. An organization can use thismaterial to measure their maturity, develop their strategy, and achieve greaterlevels of adoption and success. In addition, each ETS extends the Oracle ReferenceArchitecture by adding the unique capabilities and components provided by thatparticular technology. It offers a horizontal technology-based perspective of ORA.

Enterprise Solution Designs (ESD) are industry specific solution perspectives based on ORA. They define the high level business processes and functions, andthe software capabilities in an underlying technology infrastructure that arerequired to build enterprise-wide industry solutions. ESDs also map the relevantapplication and technology products against solutions to illustrate howcapabilities in Oracles complete integrated stack can best meet the business,technical, and quality of service requirements within a particular industry.


13/62

xiii

This document is one of the series of documents that comprise Oracle ReferenceArchitecture. ORA User Interaction describes the important aspects of a modern userinterface and provides a reference architecture for delivering a robust, feature-rich userinterface .

Please consult the ITSO web site for a complete listing of ORA documents as well asother materials in the ITSO series.

Conventions The following typeface conventions are used in this document:

SOA Service - In order to distinguish the service of Service-Oriented Architecturefrom the wide variety of services within the industry, the term SOA Service(although somewhat redundant) will be used throughout this document to make anexplicit distinction for services that were created as part of an SOA initiative; thusdistinguishing SOA Services from other types of services such as Web Services, JavaMessaging Service, telephone service, etc.

Convention Meaning

boldface text Boldface type in text indicates a term defined in the text, the OFRA Master Glossary , or in both locations.

italic text Italics type in text indicates the name of a document or externalreference.

underline text Underline text indicates a hypertext link.
http://www.oracle.com/goto/itstrategieshttp://www.oracle.com/goto/itstrategies


14/62


15/62

1

User Interaction Overview 1-1

1User Interaction Overview

This section describes the core concepts of user interaction and explains why modernuser interaction brings new and expanded capabilities to the user than traditional userinterfaces provided.

1.1 User Interaction The primary goal of user interaction is to provide a user-centric, feature-rich, intuitiveinterface to end users tailored to the specific needs of each end user; thereby bringingmaximum productivity to the work environment. Realizing this goal requires aflexible, extensible architecture since different types of end users will have verydifferent needs. The user-centricity and breadth of capabilities that a modern userinteraction requires are illustrated in Figure 11 .

Figure 11 User Interaction Capabilities

The capabilities described here are not intended as the definitive list of all possiblecapabilities, nor must all of these capabilities be provided by a user interface to beconsidered modern. Nonetheless, the capabilities described here are the capabilitiesthat have become generally associated with state-of-the-art user interaction, and


16/62

User Interaction

1-2 ORA User Interaction

therefore should be considered when defining an architecture to support modern userinteraction.

As the various capabilities are described, it should become clear that the user interfacesurfaces the capabilities, but the underlying functionality may be provided by one ormore separate and distinct systems. This is a fundamental concept of the user-centricnature of modern user interaction. The end user should be insulated from this

complexity. As far as the end user can tell, it is one consistent, integrated interface thatprovides access to all the functionality required to complete their daily tasks.

1.1.1 Rich Internet Apps A Rich Internet Application (RIA) is a Web application that provides the type ofsophisticated user interface that has traditionally required a dedicated desktop client.There are a variety of technologies being applied to create RIAs, but all share thecommonality of providing a sophisticated user interface delivered through a browser.Using a browser as the delivery platform leverages the infrastructure of the internet toreduce client deployment and maintenance costs that became the achilles heel of thededicated desktop client. Thus, RIAs provide the richness of a dedicated desktop clientwith the ease of delivery provided by the Web.

Over the last few years Web applications have undergone dramatic improvements inuser interaction capabilities. Initially Web applications were relatively simple staticHTML pages. Dynamic HTML allowed Web applications to better respond to userrequests but did little to improve the richness of the user interface. Today, Webapplications frequently incorporate JavaScript or browser plug-ins to deliversophisticated user interaction capabilities.

Here the term RIA is used to describe user interaction capabilities that include thelatest technologies as well as the older, less sophisticated Web capabilities such asstatic and dynamic HTML. All of these technologies and techniques should be viewedas tools in the tool box and the tools should be chosen to best fits the needs of the enduser.

1.1.2 Collaboration The fundamental driver for the creation of the internet was to facilitate thecollaboration between people. For example, HTML was created to allow researchers atCERN to share documents and the World Wide Web infrastructure was created toallow sharing across the entire globe. Thus, it is no surprise that a key capability ofuser interaction is collaboration.

Initially the Web was used to publish information i.e. the owner of the Web siteprovided the content for the site. This is no longer the case. Many Web sites today aredesigned to host content provided by other Web citizens. Examples abound andinclude Wikipedia (reference), Facebook (social networking), eBay (commerce),Blogger (personal commentary), GMail (email), etc. Even Web sites that are still

publication focused (e.g. newspaper sites) usually include the ability for visitors topost comments. Thus, the Web has dramatically expanded the number of contributorsor participants. This new participatory Web is commonly referred to as Web 2.0.

Collaboration as used here encompasses all of the current collaboration focusedcapabilities including email, calendar, contacts, blogs, wikis, etc. This requires that theuser interface provides access to all of these types of collaboration capabilities. Asstated above, the underlying functionality may be provided by another system, but theuser interface must still incorporate these capabilities into a unified user experience.


17/62

User Interaction


1.1.3 Mobile The rollout of third and fourth generation (3G and 4G) mobile networks coupled withthe increasing capabilities of mobile devices has enabled the use of mobile devices fortasks that traditionally required a desktop or laptop computer.

The display capabilities (screen size, resolution, etc.) for mobile devices is markedlydifferent than for desktop or laptop computers. Therefore, providing a user friendlyinterface for a mobile device usually entails some development to create a mobiledevice appropriate interface. Since the differences are focused on usability notfunctionality, the development effort should be isolated to the display aspects of thesolution.

Transcoding is a technology that may be part of the mobile support for a solution.Transcoding automatically makes the necessary adjustments to the user interface tosupport the unique properties and idiosyncrasies of different mobile devices. Themobile market appears to be coalecing around a small number of mobile platforms(e.g. iPhone, Android) so trancoding has become less important than it was just a fewyears ago when there was a plethora of mobile device platforms.

1.1.4 Desktop Apps The widespread adoption of desktop computers (and later laptop computers) wasprimarily driven by the productivity gains resulting from the use of desktopapplications. Desktop applications can be widely applicable personal productivitytools (e.g. speadsheets, word processors) or may be custom applications targeted tospecific employee roles and tasks.

With the advent of Web applications and more recently with the growing deploymentof RIAs, the preeminence of desktop applications has faded, especially for customapplications. Nonetheless, there is little risk that desktop applications will vanish anytime soon if at all, especially the extremely widespread applications such asspreadsheets, word processors, etc. Therefore, user interaction must interact withthese desktop applications in a user friendly manner.

For example, it should be easy for the user to pull data that is stored remotely into aspreadsheet so that the data can be analyzed locally on the user s desktop. Thisremoves the need to copy data (with the attendant issues of staleness, consistency,security, etc.) by allowing a single source of the data to be analyzed locally.

Obviously there are many other types of interactions with desktop applications thatare possible. Fundamentally, modern user interaction must allow data andfunctionality to be integrated with desktop applications to allow end users to workmore efficiently.

1.1.5 Single Sign-on A user-centric interaction provides access to data and functionality from a variety of

sources to simplify and improve the user experience; thereby increasing end userproductivity. The sources of data and functionality are usually protected by some typeof security to ensure that only legitimate users get access. Requiring that the end userauthenticate individually to each source system not only burdens the user withrepetitive logon procedures, but actually annoys the end user.

Single sign-on is the solution to the problem of multiple source systems each protected by security. Using single sign-on the end user provides their authenticationcredentials (e.g. user name and password) once and the user interaction systempropagates the security credential as necessary so the end user can seemlessly accessdata and functionality from a variety of source systems.


18/62


19/62

User Interaction


possible for the user to organize the content using categories, and to tag contentonce it has been found so that it can be easily retrieved.

Providing comprehensive content access: increases employee productivity since less time is spent looking for the needed

content,

improves the quality of work since the work product is based on completeinformation, reduces re-work since previously completed efforts are readily available.

Comprehensive content access is a foundational element for building organizationalcompetency.

1.1.9 Notifications Instead of a user interaction that is totally passive that simply waits until the usertakes action, notifications provide the means to push information to the end user.Notifications come in a variety of types and for a wide variety of reasons. Somenotifications are based on a subscription approach where the end user subscribes to

receive notifications. Web feeds (e.g. RSS, Atom) are an example of this type ofnotification. Subscription notifications allows the end user to remain up to date ontopics of interest without having to regularly visit the topic site(s) to look for updates.

Unsolicited notifications are also important to providing a user-centric interaction.Unsolicited notifications are notifications that may be of interest to the end user basedon information known about the end user (i.e. their profile). Many e-commerce sitesare experts at providing these unsolicited notifications. For example, Amazonprovides unsolicited notifications (via email) of new books that may be of interest tothe user based on similarities to other users or past book purchases. End users should

be able to "opt out" of these unsolicited notifications.

Organizations can also leverage unsolicited notifications to improve corporatecommunications. Examples of using unsolicited notifications for corporatecommunication include notification of benefits open enrollment periods, corporatenews, relevant industry news, employee review periods, etc.

Notifications remove the burden from users of having to regularly check for newinformation or updates. Notifications improve the distribution of information andopportunities by proactively informing the end user.

1.1.10 Personalization and Customization No two people work in exactly the same way, even people in the same role within anorganization. Thus, to be truly user-centric, the user interaction must be tailorable todesires of the individual end user.

Customization allows the end user to change the interface (within allowedparameters) to better suit their needs or individual preferences. In addition tocustomization that is done by the end user, a modern interface should be readilycustomizable by administrators. This allows the administrators to change the interface

based on organization, department, role, etc. needs and desires. Customization isusually a static change i.e. once configured, the interface stays that way.

Personalization tailors the interface to the end user based on user profile information(e.g. location, role, demographic), past behavior (e.g. articles accessed, previouspurchases), and current context (e.g. time of day, open enrollment). Personalizationdiffers from customization in that the interface is tailored to the end user without the


20/62

Difference from Traditional User Interfaces


end user taking any action. Personalization is generally dynamic i.e. the interfacechanges based on decisions made at runtime.

Interface personalization and customization increases user productivity by allowingadministrators and end users the ability to create a user interaction that best meets theneeds of the end user. The days of a one-size-fits-all user interface are gone.

1.2 Difference from Traditional User Interfaces IT departments have been building user interfaces for decades. Many differenttechnologies have been used over the years to create user interfaces. This sectioncompares and contrasts traditional user interfaces with a modern user interfacedefined by this document.

1.2.1 Traditional User Interfaces Early user interfaces were text based with very limited display capabilities, usuallydriven by obtuse key stroke sequences, and each screen contained very limitedinformation. Client server technologies introduced much more capable displaydevices and graphical user interfaces that significantly improved the user experience.While these dedicated, client-server, desktop user interfaces are the gold standard forrich user interfaces, they have three major disadvantages:

1. The client application is specific to the desktop device. This requires thedevelopment of a different client application for each type of desktop that will besupported; thus increasing development and support costs.

2. The dedicated desktop client must be installed on each client device. Thisincreases initial deployment effort and costs. Additionally, whenever a newversion of the client is released each desktop device must be updated to the newversion; thereby increasing ongoing maintenance costs.

3. The dedicated desktop client has a relatively narrow focus for the capabilitiesprovided i.e. the dedicated desktop client is tied directly to a single application.

While this limitation is not inherent in dedicated desktop clients, it is howdedicated desktop clients have been architected, designed, and built. Thededicated desktop client has not been developed into a general purpose userinteraction delivery platform.

Figure 12 illustrates the traditional dedicated client where each client is connected toa single backend system.


21/62


22/62

Difference from Traditional User Interfaces


Figure 13 Conceptual View

While Figure 13 is a relatively simple diagram, there are a variety of concepts that areillustrated, as described below.

1.2.2.1 Display Devices The figure shows multiple screens but no specific display devices; thus illustrating thatthe type of display devices is indeterminate, i.e. the architecture supports any type ofdisplay device. Additionally, whereas the traditional user interface illustrated inFigure 12 shows one screen per backend system, this figure shows that the number ofscreens is independent from the number of backend systems. The screen contents aredefined by the needs of the user, not by the number or types of backend systems.

1.2.2.2 Unified User Interface The Unified User Interface layer provides the control and visual elements that definethe interaction the user has with the system. This layer separates the way the userinteracts with the system from the underlying functionality provided by the system.This has many advantages including allowing different display devices to besupported via control and visual elements specialized for the device since, forexample, mobile devices do not have nearly the screen real estate of a desktopcomputer.

1.2.2.3 User Interface Services The User Interface Services layer provides a set of functionality that can be used andreused in a variety of ways to deliver various user interfaces specialized to the needsof the end user. This illustrates that the underlying functionality is separated from thevisual and control elements built into the user interface. The services provided by thislayer may come from a variety of sources located anywhere that is network accessible.

1.2.2.4 Access and Incorporation The Access and Incorporation layer provides the capability to incorporate data andfunctionality from any number of backend systems into the user interface. Generally,there are two types of backend systems that need be incorporated into the userinterface: systems that are designed for use with user interface (e.g. LDAP, dedicateddatabase) and systems that are not (e.g. legacy applications). The former type of


23/62

Complementary Technologies


systems can be access directly by the user interface architecture. Ideally the latter typeshould be accessed via a robust integration architecture rather than relying onpoint-to-point integrations.

This distinction is the reason that the term incorporation is used in this ConceptualView instead of the term integration. A suitable integration architecture is describedin the ORA Service-Oriented Integration document.

1.2.2.5 Backend Systems Four different graphics are used to represent backend systems. This is done toillustrate that many different types of systems may be incorporated into the userinterface. Additionally, no attempt is made to define the types of backend systemsthat might be incorporated since the number and types of backend systems whichcould be incorporated is virtually limitless.

1.3 Complementary Technologies This section discusses types of technologies that are associated with user interaction.Categories of technologies are discussed not specific products. The categories of

technologies are not user interaction technologies per se, but rather they aretechnologies that impact or are impacted by a user interaction architecture.

1.3.1 Enterprise 2.0 Enterprise 2.0 is a nebulously defined term that refers to bringing Web 2.0 technologyinto the enterprise IT environment. A common theme for Enterprise 2.0 iscollaboration: collaboration within the enterprise as well as collaboration between theenterprise and customers or partners.

As discussed above, the primary distinction between Web 1.0 and Web 2.0 is thechange from a publishing paradigm to a participatory paradigm. There are a varietyof technologies that have become associated with Web 2.0 in that these technologieshave been used to create a rich user experience that facilitates participation. However,it is the capabilities provided to the end user that distinguishes Web 2.0 from Web 1.0,not the technologies themselves.

This document will discuss Web 2.0 technologies where they apply to the userinteraction architecture. However, this document does not address Web 2.0 orEnterprise 2.0 directly or completely. Rather, Enterprise 2.0 is an EnterpriseTechnology Strategy (ETS) and will be covered by dedicated set of collateral (ORAperspective, foundation document, maturity model, etc.).

1.3.2 Content Management Content Management technologies are used to manage content that is made availableto an end user by the user interface. As such, Content Management is verycomplementary to user interaction. However, Content Management is far more that

just making content available through a user interface. Content Management alsoincludes capabilities such as content lifecycle management, archival, approvalprocessing, document capture, etc.

This document will discuss the interaction between Content Management and the userinterface. However, this document will not detail Content Management capabilities;rather Content Management will be treated as a source system that is integrated intothe user interaction. A complete description of Content Management will be providedin a separate set of documents contained in the Content Management ETS.


24/62

Complementary Technologies


1.3.3 Service Oriented Architecture Service Oriented Architecture (SOA) is a strategy for constructing business-focused,software systems from loosely coupled, interoperable building blocks (called SOAServices) that can be combined and reused quickly. The user interaction architecturedefined within this document follows the principles of SOA. Specifically, the userinterface may surface data and functionality that is provided by external SOA Services,

and conversely, the user interaction architecture provides access to internal capabilitiesvia SOA Services.

Creating a SOA requires a holistic approach and encompasses far more than just theuser interaction elements that are the topic for this document. Thus, this documentwill touch on some SOA topics but only where directly applicable to the userinteraction. A comprehensive set of collateral for SOA is available from the SOAEterprise Technology Strategy.

1.3.4 Business Process Management Business Process Management (BPM) technologies are used to automate and manage

business processes. Frequently business processes include task that are completed bya human participant. This human interaction is a type of user interaction that the userinteraction architecture must support. However, BPM includes many capabilities thatare not directly visible to the business process participant. These capabilities includeprocess modeling, state management, process monitoring, integration to sourcesystems, etc.

This document will discuss the interaction between BPM and the user interface,specifically how the end user participates in a business process that is being managed

by BPM technologies. However, this document will not detail BPM capabilities; ratherBPM will be treated as a source system that is integrated into the user interaction. Acomplete description of BPM is provided by a separate set of material collectivelycalled the BPM Enterprise Technology Strategy..

1.3.5 Interactive Voice Response Interactive Voice Response (IVR) is technology that allows a computer to detect andrespond to voice (voice recognition) and touch-tone (telephone keypad) inputs. IVRcan be used to control almost any function where the interface can be broken downinto a series of simple menu choices. Thus, IVR is a type of user interaction. However,due to the limitation of simple menu choices, IVR addresses a narrow segment of thedesired user interaction spectrum.

For this document, IVR is viewed as a specialized case of user interaction that requiresspecific technologies which are not covered by this document. However, IVR doesaddress specific needs and should not be ignored totally when discussing userinteraction. Thus, this document does discuss IVR integration to the user interactionarchitecture.

1.3.6 Identity Management Identity Management (IdM) can be viewed as the integration of multiple identitiesand identity stores within an enterprise. The user interaction architecture can leverageIdM solutions where they exist. IdM provides a single source for authentication andauthorization that can significantly simplify security concerns, especially singlesign-on. In the context of this document, IdM solutions are considered source systemsfor security capabilities and user profile information.
http://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/SOA%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/SOA%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/SOA%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/SOA%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/SOA%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/BPM%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/BPM%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/BPM%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/BPM%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/BPM%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/BPM%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/SOA%20Enterprise%20Technology%20Strategyhttp://my.oracle.com/portal/page/myo/global/Messaging%20Home/Enterprise%20Architect%20Program/BPM%20Enterprise%20Technology%20Strategy


25/62

2

User Interaction Principles 2-1

2User Interaction Principles

This section defines the principles of modern user interaction. These principlesprovide the guidance for creating a sound architecture that will fully support amodern user interface.

The principles defined below provide sound guidance for creating an architecture foruser interaction. Each organization should evaluate the principles listed and derivetheir own set of principles that match the specific environment and goals of theirorganization.

The principles are:

2.1 Display Device Support

2.2 User Interaction Adaptability

Principle Display Device Support

Statement The architecture must support multiple different display devices.

Rationale An architecture that supports only a single display device isprohibitively limiting in todays connected world. Even if only asingle display device (e.g. personal computer) is the initial focus

for a business solution, the architecture must be designed toreadily support additional display devices; otherwise the cost ofsupporting another display device constrains the futureflexibility of the solution.

Implications The display device specific aspects of a business solutionshould be minimized.

Applicable standards should be followed to maximizeinteroperability.

The architecture must support multi-channel delivery ofcontent and functionality.

Principle User Interaction Adaptability

Statement The architecture must support the ability to adapt to the end userneeds and desires.


26/62

Unified User Experience


2.3 Unified User Experience

2.4 Physical Separation

2.5 Secure Interactions

Rationale The user interface should adapt to the needs of the end userrather than the user having to adapt to the interface. Thisadaptability has many different aspects including languagesupport (internationalization and localization), the ability of endusers to modify the interface (customization), and the interfacechanging implicitly to provide a better user experience(personalization).

Implications The architecture must provide multi-lingual support. The architecture must include both customization and

personalization.

Principle Unified User Experience

Statement The architecture must support pulling together information andfunctionality from multiple sources into a single unified userexperience.

Rationale The days of siloed, single purpose user interfaces are past.Ready access to information and functionality is a competitiveadvantage in todays information driven economy.

Implications The architecture must provide a means to incorporatemultiple sources of information and functionality.

The user interface must support modular display to allowmultiple components to display simultaneously.

Principle Physical Separation

Statement The architecture must support physical separation of the user

interface from the sources of information and functionality.Rationale The architecture must make no implicit assumptions about the

relative locations of the front-end user interface and the back-endresources. The front end may be a mobile device or a computeron the public internet. The network connection between thefront end and back end may be slow, unreliable, and unsecure.

Implications The user interface should minimize the frequency ofcommunications between the front end and the back end.

The front-end technology platform may be different fromthe back-end technology platform.

Other front-end components (e.g. WSRP portlets, mashupwidgets) may also by physically separated from the userinterface.

Principle Secure Interactions

Statement The architecture must provide secure interaction between theend user and the server-side resources.


27/62

Access to Functionality

User Interaction Principles 2-3

2.6 Development for Disparate Display Devices

2.7 Rapid Development

2.8 Access to Functionality

Rationale Security breaches can be costly to the business from a financialperspective, legal perspective, or brand perspective; therefore,the architecture must provide end-to-end security.

Implications The back-end resources must be protected from acompromised front end.

The front end must be protected from a malicious back end.

The architecture must provide secure communications overunsecure networks.

Principle Development for disparate display devices

Statement The architecture must provide for the development of userinterfaces for a variety of display devices.

Rationale Just as the architecture must be able to support multiple types ofdisplay devices, it also must facilitate development of userinterfaces hosted on different types of display devices. Thisincludes both browser-based (i.e. thin client) interfaces as wellas device-specific (i.e. fat client) user interfaces.

Implications The development environment should support differentdevelopment frameworks for the different device types.

Device emulation may be required to support developmentfor mobile devices.

Principle Rapid Development

Statement The architecture must provide rapid, guided development of theuser interface without needlessly exposing the developer toimplementation details.

Rationale Reducing the time and resources required to deliver businesssolutions is required for IT to better support and align with

business needs. Low level development is both time consumingand error prone.

Implications The architecture should provide an integrated developmentenvironment with integrated help and wizards to speed andsimplify development.

The developer should have access to the lowest level codeand configuration details when necessary, but the need toaccess this level of detail should be rare.

The development environment should facilitate code

debugging to rapidly identify and fix defects.

Principle Access to Functionality

Statement The architecture must support end user access to a wide varietyof server-side functionality.


28/62

Meta-data Support


2.9 Meta-data Support

2.10 Performance

Rationale Ultimately the goal of the user interface to provide the end useraccess to all the necessary information and functionalityregardless of the source of that information or functionality.

Implications The architecture should support the hosting of functionalitydesired by the end users.

The architecture should provide mechanisms to integratewith existing sources of information and functionality.

The end user should be isolated from the particulars of theactual source of information and functionality.

Principle Meta-data support

Statement The architecture must support separating configuration andother types of meta-data from the source code.

Rationale Source code modification is the least efficient mechanism tomodify behavior of a system. The ability to change the behaviorof the system by changing externalized meta-data providesmuch quicker response to business needs.

Implications The meta-data should be accessible both within thedevelopment environment (to support developers) and fromoutside the development environment (to support others).

Externalizing meta-data should to be incorporated into thedevelopment process.

Principle Performance

Statement The architecture must provide performance acceptable to the endusers.

Rationale Poor performance, especially high latency, is a commoncomplaint from end users. Poor performance results in lessproductivity and is a main contributor to end userdissatisfaction. The end user will blame the user interface for thepoor performance even if the actual source of the problem is one(or more) of the backend systems.

Implications The architecture should, where necessary, decouple the backend system response from the user interface responsee.g. asynchronous access to backend systems.

Performance must not be an afterthought; but rather must be considered throughout the development lifecycle.

The performance of the system should be tested inreal-world scenarios. Frequently testing is only done onlocal area networks with low latency and high bandwidth.This type of testing is insufficient for a user interfacedeployed to the public internet or a wide area network.


29/62

3

Industry Standards 3-1

3Industry Standards

This chapter identifies and briefly describes the industry standards that are applicableto the topic of user interaction. Some of the standards focus on defining howcomponents interact while other standards define how individual components behave.

3.1 W3C Standards The World Wide Web Consortium (W3C) defines the standards that help ensure theWorld Wide Web works for all. There are a wide variety of web standards under theW3C banner and only a few of the key standards of particular relevance to thearchitecture described in this document are listed below. Further information,including the full specification, for each of the listed Web standards can be found athttp://www.w3.org .

3.1.1 HTTP The HyperText Transfer Protocol (HTTP) and the related Secure HyperText TransferProtocol (HTTPS) provide the protocols upon which the Web is based. It is thewidespread adoption of these protocols that has made the ubiquitousness of the Webpossible. The HTTP standard is a joint effort between the W3C and the InternetEngineering Task Force (IETF).

HTTP(S) is but one of many Internet communication protocols (e.g. SMTP, FTP, Telnet), but it is by far the most important protocol for the user interface.

3.1.2 URIA Uniform Resource Identifier (URI) is a string of characters used to identify aresource on the Internet. Such identification enables interaction with representations ofthe resource over a network (e.g. Web) using specific protocols (e.g. HTTP). A UniformResource Locator (URL) is a specialization of a URI. In addition to identifying aresource, a URL specifies the means of acting upon or obtaining the representation ofthe resource. For example, the URL provided above for W3C ( http://www.w3.org )specifies that the HTTP protocol be used to access the resource.The primary functionality for a user interface is to allow the end user to interact withvarious resources. Hence, the URI specification is essential in that it provides themeans for a user interface to find and interact with a wide variety of resourcesaccessible via the Internet.
http://www.w3.org/http://www.w3.org/http://www.w3.org/http://www.w3.org/


30/62

Java Standards


3.1.3 HTML, XHTML, CSS The HyperText Markup Language (HTML) specification defines how web browsersuse the markup tags to interpret the content of a web page. Cascading Style Sheets(CSS) allow common formatting to be defined once and then used across multipleHTML pages; thereby providing uniformity to the look and feel of a particular website.

eXtensible HyperText Markup Language (XHTML) is based on the eXtensible MarkupLanguage (XML) (also a W3C specification). Because XHTML is base on XML,XHTML can be parsed by (widely available) XML parsers which providesimprovements for searching, indexing, and parsing.

These standards provide the lingua franca (at least from a technology point of view) forthe Web and, therefore, are essential to browser based user interfaces.

3.1.4 AJAX Asynchronous JavaScript and XML (AJAX) is not a W3C standard per se, but rather is agroup of interrelated W3C standards that facilitates the creation of interactive websites. Using AJAX, a web page can retrieve data from the server asynchronously (in

the background) without interfering with the display and behavior of the existingpage.

The primary W3C standards incorporated into AJAX include JavaScript, XML, andDOM (Document Object Model). It is also important to note that, despite the name,AJAX does not require XML, but may be based on other data interchange formats, forexample, JavaScript Object Notation (JSON).

AJAX (and similar technology) allows the web page to behave (from an end userperspective) more like a rich, desktop user interface i.e. AJAX is a key enabler for RichInternet Applications (RIAs).

3.2 Java Standards Java standards are defined by the Java Community Process (JCP) and each standard isnumbered. The Java standards that are of particular relevance to the architecturedescribed in this document are listed below. The Java standards are frequently referedto by the number assigned to the Java Specification Request (JSR). Some of the Javastandards have undergone several revisions, and most have undergone at least onerevision. Figure 31 illustrates the Java standards and the associated JSR numbers.


31/62

Java Standards


Figure 31 Java Standards

The standards shown above are listed below by the latest JSR number and, whereapplicable, the previous version of the standard has been identified to providetraceability. Further information, including the full specification, for each of the listed

Java standards can be found at http://jcp.org/en/jsr/all .

3.2.1 JSR 227: A Standard Data Binding & Data Access Facility for J2EE This specification defines a framework that standardizes the interactions betweentypical user interface components and classes that publish data objects and providemethods that manipulate the data objects. The framework decouples the user interfacefrom the data portions of the application.

In the nomenclature of the MVC pattern (see Section 4.2.1 ), this specificationstandardizes metadata and behavior for binding the model to both the view and thecontroller.

3.2.2 JSR 245: Java Server Pages 2.1This standard provides interoperability between Java Server Pages (JSPs) and thecontainer hosting the JSPs. JSPs are focused on simplifying the creation of dynamiccontent on web pages. This JSR is an update to JSR 152: Java Server Page 2.0 to bettersupport Java Server Faces.

In web applications, JSPs are frequently used to implement the view in the MVCpattern (see Section 4.2.1 ).

3.2.3 JSR 286: Portlet Specification 2.0 This standard provides interoperability between portlets and the portal framework bydefining a set of APIs between the portal and portal framework. The specified APIsaddress lifecycle, aggregation, personalization, presentation, and security. This JSR isan update to JSR 168: Portlet Specification .
http://jcp.org/en/jsr/allhttp://jcp.org/en/jsr/all


32/62

Java Standards


Embracing this standard provides portability between portals and the portalframework into which the portal is deployed. A portal can be developed once andthen be deployed to any compliant portal framework. Following this standard alsoprevents vendor lock-in by allowing the portal framework to be replaced withoutrequiring modification to all the portlets.

3.2.4 JSR 314: Java Server Faces 2.0 This standard provides a server-side, component framework for developing webapplications with rich user interfaces. This standard defines a framework of JSP tagsand Java classes that simplify building graphical user interfaces and is specificallydesigned to support graphical development tools. By providing a componentframework, this standard facilitates the creation and use of a wide variety of prebuilt,

JSF compliant components. This JSR is an update to JSR 252: Java Server Faces 1.2 which was a minor update to JSR 127: Java Server Faces 1.0 .

The Java Server Faces standard is based on the MVC pattern (see Section 4.2.1 ).

3.2.5 JSR 315: Java Servlet 3.0 Specification

This standard provides interoperability between Java Servlets and the containerhosting the servlet. Java Servlets were created to standardize programming whenfollowing a request-response paradigm. While applicable to any request-responseprogramming, Java Servlets are most widely used in web applications using theHTTP(S) protocol. This JSR is an update to JSR 154: Java Servlet 2.4 Specification

In web applications, Java Servlets are frequently used to implement the controller inthe MVC pattern (see Section 4.2.1).

3.2.6 JSR 329: Portlet 2.0 Bridge for JavaServer Faces 1.2 Specification This standard provides the ability to expose a Java Server Faces (JSF) application as aportlet including the ability to remote the portlet using WSRP (see Section 3.3.1 ). Thisstandard allows the JSF based web interface to be easily incorporated into a portalframework. This JSR is an update to JSR 301: Portlet 1.0 Bridge for Java Server Faces1.2.

3.2.7 JSR 333: Content Repository for Java Technology API Version 2.1This standard provides a way to access content from a content repository in astandardized way. The specified API focuses on transactional read/write access,

binary content (stream operations), textual content, full-text searching, filtering,observation, versioning, and handling of both hard and soft structured content. This

JSR is an update to JSR 283: Content Repository for Java Technology API 2.0 whichwas an update to JSR 170: Content Repository for Java Technology API .

Since ready access to a variety of content is a primary concern in many user interactionscenarios, having a standard way to interact with content repositories is a bigadvantage. It significantly reduces the effort required to incorporate a contentrepository and provides a consistent mechanism to access multiple contentrepositories.

3.2.8 JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services This standard provides a high-level, easy-to-use API for developing RESTful webservices running on the Java platform. The standard provides a declarative style ofprogramming using annotations and also enables low level access in the cases where


33/62

Other Standards


needed. This JSR is an update to JSR 311: JAX-RS: The Java API for RESTful WebServices .

RESTful web services provide an alternative to SOAP based web services. RESTfulweb services are more aligned with the stateless request-response paradigm used inthe majority of HTTP based web applications.

3.3 OASIS Standards The Organization for the Advancement of Structured Information Standards (OASIS)has also published some standards that are of particular relevance to the architecturedescribed in this document and are listed below. Further information, including thefull specification, for each of the listed OASIS standards can be found athttp://www.oasis-open.org .

3.3.1 WSRP 2.0 The Web Services for Remote Portlets (WSRP) specification defines a set of interfacesand related semantics designed to simplify incorporating user interface componentsexposed via web services; thereby providing a portion of the overall user interfacewithout writing any code. The WSRP standard is layered upon the web services stackand therefore leverages the existing web service standards.

The WSRP specification is a key enabler to federated portals (see Section 4.2.3).

3.3.2 CMIS The Content Management Interoperability Services (CMIS) specification defines a webservice interface providing greater interoperability of content management systems.CMIS defines web services interfaces to enable rich information to be shared, instandardized formats, between document systems, publishers, and repositories.

This standard plays a role similar to the Content Repository for Java Technologystandard listed above with the notable difference that it is based on web services ratherthan Java; therefore it is equally applicable to non-Java environments.

3.4 Other Standards There are a few other standards that are of particular interest to the user interactionarchitecture. These standards are listed below:

3.4.1 MIME Types Multipurpose Internet Mail Extensions (MIME) is an IETF standard that supports: textin non-ASCII character sets, not-text attachments, message bodies with multiple parts,and header information in non-ASCI character sets. The MIME standard is a set of

IETF RFCs available on the IETF web site ( http://www.ietf.org ).The MIME types standard allows multiple different types of content (e.g. graphics,sounds) to be transmitted and displayed correctly by web browsers and other userinterface applications.

3.4.2 Atom The Atom standard is actually two related standards, the Atom Syndication Formatstandard and the Atom Publishing Protocol standard. Together these two standardsprovide the mechanism to allow applications to check for updates of published
http://www.oasis-open.org/http://www.ietf.org/http://www.ietf.org/http://www.oasis-open.org/


34/62

Other Standards


content (e.g. blog entries, news items) on a website. The Atom standard is composedof two IETF RFCs available from the IETF web site ( http://www.ietf.org ).

The Atom standard is one of the approaches used to provide syndicated content (seeSection 4.1.4.10) to a user interface.

3.4.3 RSS 2.0 The Really Simple Syndication (RSS) standard provides the mechanism to allowapplications to check for updates of published content (e.g. blog entries, news items)on a website. The RSS 2.0 standard is available athttp://cyber.law.harvard.edu/rss/rss.html .

The RSS 2.0 standard is a direct competitor to the Atom standard and is also one of theapproaches used to provide syndicated content (see Section 4.1.4.10) to a userinterface.
http://www.ietf.org/http://cyber.law.harvard.edu/rss/rss.htmlhttp://cyber.law.harvard.edu/rss/rss.htmlhttp://www.ietf.org/


35/62

4

User Interaction Reference Architecture 4-1

4User Interaction Reference Architecture

This section describes a high-level architecture for user interaction. Each sectionprovides a view of the architecture from a particular perspective.

4.1 Logical View The Logical View of the architecture describes the various layers in the architecture.Each layer encapsulates specific capabilities for the overall architecture. Upper layersin the architecture leverage the capabilities provided by the lower layers. Generally,upper layers call lower layers in the architecture and the reverse (i.e. lower levelscalling upper layers) is prohibited. Upper layers are allowed to call capabilitiesprovided by any lower layer and, therefore, may skip any intermediate layers. TheLogical View of the architecture is shown in Figure 41 .

Figure 41 Logical View

Each layer in the architecture beginning at the top and progressing to the bottom isdescribed in subsequent sections. The description of each layer does not attempt to


36/62

Logical View


enumerate every possible capability provided by the layer; rather, only the key(essential) capabilities provided by the layer are listed and described.

4.1.1 Display Devices The display devices are used by the end user to interact with the user interface. Whichtypes of display devices to support is an important design decision for any userinteraction architecture. This architecture is designed such that the vast majority ofprovided capability is display device independent; therefore adding support foradditional display devices is not particularly difficult. Display devices includedesktop and laptop computers, mobile phones, tablets, etc. The architecture supports

both browser based interfaces and client hosted applications.

This is not formally a layer in the user interaction architecture. Rather the entirepurpose of the architecture is to provide a feature-rich user interface that can beaccessed by a variety of display devices. Conversely, a single display device may hostmultiple different user interfaces and may access multiple different Service Tiers.

4.1.2 Client Tier

The Client Tier is hosted on the display device. As mentioned above, this may be a browser or an thick client specific to the display device. A browser based interfacemay be a simple HTML web site, a complex rich-internet application (RIA), or ahybrid of the two. The design of the Client Tier is driven by the requirements of theend user interface with the other layers in the architecture equally supporting anyClient Tier choice. In fact, the other layers in the architecture are intended toconcurrently support many different types of interfaces in the Client Tier.

Regardless of the choice for the Client Tier, there are standard capabilities provided bythis tier in the architecture. These key capabilities are described below.

4.1.2.1 Controller The Controller accepts input from the user and performs actions based on that input.Nearly all of the actions will result in calls being made to other components in theClient Tier. Many of the actions will result in calls to the Communication Serviceswhich will, in turn, result in actions being invoked on the Service Tier of thearchitecture.

4.1.2.2 State Management The State Management component is responsible for maintaining the current state ofthe user interface. For browser interfaces, this is frequently implemented via cookies.For native applications this component may be more complex and may maintain, forexample, the current step being executed in a series of user input actions.

The State Management component is not used to maintaining the state of data entitiesthat the user interface operates upon. Data entity state management is handled by

both the Data Management capability in the Client Tier and by capabilities provided by the Service Tier.

4.1.2.3 Rendering The Rendering component is responsible for delivering a view of the interface suitablefor the end user. Rendering is a capability provided by the display device via astandard programming interface. Rendering may be provided by a browser (e.g.HTML), a browser plug-in (e.g. Flash), or a native application (e.g. Java Platform,Micro Edition).


37/62

Logical View


4.1.2.4 Composition Composition provides the end user with the ability to combine different interfacecontent in an ad hoc manner. For browsers, this capability is usually referred to asmashups and has gained widespread acceptance as an effective mechanism toempower end users. Ultimately, the goal of Composition is to allow the end user toadjust the way information is combined and presented to better support the needs ofthe end user.

4.1.2.5 Data Management Data Management is focused on providing temporary storage of data entities so thatthey may be efficiently manipulated by the user via the user interface withoutrequiring incessant calls to the Service Tier. Once all necessary changes have beenmade, the data entities are persisted via calls to the Service Tier. Using client-side DataManagement makes the user interface much more responsive by dramaticallyreducing the number of calls to the Service Tier.

An example of extensive use of this Data Management capability is Asynchronous Java and XML (AJAX). AJAX fetches data from the Service Tier as XML (or anotherformat such as JSON), temporarily stores the data while it is being manipulated via

JavaScript, and then posts the modified data back to the Service Tier.Sophisticated Data Management also facilitates occasionally connected computing(OCC). When used within an OCC architecture, the Data Management componentstores all modified data entities until a connection between the Client Tier and ServiceTier is (re)established, at which point the changes are propagated to the Service Tier.

4.1.2.6 Security Container The Security Container provides client-side security services. The Security Containeris responsible for supplying user credentials to the Security Tier to facilitate userauthentication and authorization. Credentials may be supplied by the end user (e.g.user name and password) or they may be associated with the Client Tier itself (e.g.X.509 certificate).

The Security Container is also responsible for validating any credential provided bythe Security Tier. For example, the Security Container must check the certificationchain and the root certificate for an X.509 certificate provided by the Security Tier toestablish a secure HTTP session.

Additionally, the Security Container is responsible for protecting the Client Tier (andthe display device) from malicious attacks originating from the Service Tier. This isvitally important since the Client Tier may access multiple different Service Tiers, someof which might be malevolent. For example, a browser-based Client Tier connected tothe internet can access any HTTP server also connected to the internet.

4.1.2.7 Communication Services

The Communication Services provide the means to access Service Tier capabilities. TheCommunication Services handle message marshalling and demarshalling as well asconnection and reconnection as necessary to provide reliable communications with theService Tier. The Communication Services use standard communication protocols asdescribed below.


38/62

Logical View


4.1.3 Standard Communication Protocols The Standard Communication Protocols is not technically a layer in the architecture,rather it separates the Client Tier from the Service Tier. Architecturally it is veryimportant for two primary reasons: It illustrates that the Client Tier and the Service Tier are separated by a network.

The network may introduce many issues including unreliable transport, poorthroughput, high latency, and malevolent interlopers.

The Client Tier and the Service Tier may be completely different technologyplatforms owned by different authorities. Therefore, adhering to standards-basedcommunication protocols is essential to ensure interoperability.

Even in the case where the Client Tier and the Service Tier are owned by the sameauthority and reside on an internal network, the architectural significance ofseparating the Client Tier from the Service Tier should not be ignored since frequentlyfunctionality, which was originally designed to support only internal users, ends upwith an expanded role to support partners and even customers.

4.1.4 Service Tier The Service Tier hosts the capabilities that satisfy the requirements of the end user.The Client Tier exists solely to provide a user-friendly interface to the capabilitieshosted on the Service Tier. Since the Service Tier is accessed by multiple Client Tierapplications concurrently, it is vital that the Service Tier be reliable, meet or exceed theavailability and performance (both throughput and latency) requirements of theclients, and be scalable to meet any increase in the number of clients.

From the clients perspective, all functionality comes from the Service Tier. However,in reality, much of the functionality exposed by the Service Tier actually originates inother systems (the Resource Tier), and the Service Tier is only providing easy access tothe functionality.

There is a wide variety of capabilities that the Service Tier might provide, and a

multitude of ways the capabilities can be organized and quantified. This sectiondescribes the key capabilities at sufficient granularity to make the architecturerequirements clear without overwhelming the reader with a laundry list of possiblefeatures. The key capabilities are:

4.1.4.1 Service Invocation The Service Invocation capability provides easy access to the Service Tier capabilities.The Service Invocation capability is the counterpart to the Communication Services inthe Client Tier. The Service Invocation capability must handle the communicationwith multiple clients simultaneously and ensure that each client request is routed tothe appropriate Service Tier capability.

4.1.4.2 Personalization Personalization uses specific, implicit and explicit characteristics of the end user (e.g.interests, past behavior, context) to modify the interface to provide a better userexperience. Personalization is driven by three types of information: End user profile information such as organization, role, demographic, zip code,

etc. Past behavior of the end user such as previous purchases, articles accessed, etc. Current behaior such as responding to an image or clicking a link.


39/62

Logical View


Current context independent of the end user such as day of the week, time of day,current specials, open enrollment period, etc.

Personalization is generally based on a deterministic, rules-based process. The totalityof rules applied to determine the personalization may be arbitrarily complex.Personalization may also be based on collaborative filtering where the personalizationfor an end user is determined by the actions and interests of similar users.

4.1.4.3 Customization Customization is based on end user selections and explicit information provided bythe end user. For this architecture, localization is considered a type of customizationi.e. the end user selects the desired local and the interface changes to reflect the chosenlocal. Customization allows the end user to select particular display themes; move,remove, or add display elements; set default display settings; etc.

In addition to end user customization, customization may provide an easy mechanismto deliver a custom interface via administrative configuration. Private labelling is anexample of this type of customization. Private labelling takes a standard set offunctionality but provides a custom interface by changing the layout, color schemes,etc. to create a seemingly unique experience.

4.1.4.4 Collaboration Collaboration encompasses all of the current collaboration focused capabilitiesincluding email, calendar, contacts, forums, discussions, blogs, wikis, instantmessaging, announcements, etc. A unified, integrated collection of collaborationcapabilities simplifies and enhances the user experience. For example, what starts outas an email exchange might transition into a discussion to include more participantsand record the exchange for future reference. Collaboration capabilities should allowthe end users to work together effortlessly without having to jumping from interfaceto interface.

4.1.4.5 Search The Search capability provides the ability to search for specific content items across allcontent sources based on user defined search criteria such as content type, topic, keywords, date, etc. The Search capability needs to be integrated with the Secur