WEP: A Reference Model and the Portal of Web Engineering Resources Sotiris Christodoulou & Theodore...

WEP: A Reference Model and the Portal of Web Engineering Resources

Sotiris Christodoulou & Theodore Papatheodorou

High Performance Information Systems Laboratory

Computer Engineering & Informatics Department

University of Patras - Greece

10-Aug-2004 Web Engineering Workshop ACM HyperText 2004

Web Engineering

“The application of systematic, disciplined and quantifiable approaches to development, operation, and maintenance of Web-based Information Systems (WIS). It is both a pro-active approach and a growing collection of theoretical and empirical research in Web application development”.


WIS & WebApps

WIS is an information system, utilizing Web technologies to provide information (data) and functionality (services) to end-users through a hypermedia-based presentation / interaction user interface on web-enabled devices.

WebApps are the different functionality-oriented components of a WIS. Actually a WebApp is a small-scale WIS that provides very specific information or functionality.


Web Project

The planning, development, operation and maintenance of a WIS. It is a lifecycle process model to ensure successful WIS development and evolving through a number of phases and stages.

Each stage includes the activities that are carried out, the relationships between these activities, the skills needed (roles), the resources that are used, the results that are created, etc.

The activities are carried out by Teams of Developers who are based on selected Web Technologies, take advantage of selected Research Results and use a number of Tools.


Web Engineering Resources (WERs)

Web Engineering Resources

Research Results(Theoretical & Empirical)

Standards Bodies(IETF, W3C, etc.)

Researchers &Practitioners

S/W CompaniesOpenSource Orgs.

ResearchersIndividuals

Web Technologies

Tools

WebEngineers

WIS

INPUT

OUTPUT


The Problem

Few research results are transferred to real-life Projects

Emerging technologies are used hesitantly in the beginning and it takes a lot of time for them to be adopted by a large part of web engineering community

Web Engineers need time to test and understand all available tools


The Problem

Web Engineers have to continually be in a process of studying research results, understanding and experiencing (use and test) emerging tools and technologies

It is hard for most Web Engineers to follow in the strict schedule of a Web Project. Thus, WERs are not used appropriately or at all during current Projects.


The Problem

Web Engineers need help and guidance in accessing the knowledge and experience of web development.

Current solutions include: design patterns, good practices and tutorials on technologies / tools. What is missing? An overall view and structure of WERs

under several taxonomies.


Proposal

Web Engineering Resources Portal (shortly WEP). The main objective of WEP is to structure and present the WERs under a framework that provides a Reference Model and a resources Portal

Why Portal? It provides several and cross-referenced taxonomies of WERs

The aim of WEP is to constitute: for academics an important tool for the education of

Web Engineering, and for Web Engineers a reference model for the

deployment of WISs and a guide in the discovery and apprehension of WERs.


WEP - Web Engineering Reference Model & Resources Portal WEP Reference Model

WEP-Terms: WEP Basic Terminology and Definitions WEP-Arch:

Technical-oriented Classes of WebApps Logical Architecture of WebApps Physical Architecture of WebApps

WEP-Teams: Teams and skills needed in Web Project WEP-Process: Generic and adaptable lifecycle process

model through which WEP-Teams are using WERs to develop and maintain a WIS based on the WEP-Arch

WER-Portal Several WER Taxonomies through which Web Engineers

will be able to easily and meaningfully locate research results, technologies and tools and understand their role during WIS Development and WIS Operation / Maintenance


WEP-Terms A. General Terms

Data, Information, Software, Program, Application B. Web Primitive Elements

WWW, URI, Resource, Web Resource, Web Resource Manifestation, Web Link, Web Anchor:

C. Web Architecture Elements Web User, Web Publisher, Web Site Publisher, Message Web agent

Web Client Web Request User Session

Web Server Web Response Server Session Cookie

Web Proxy Web Gateway

D. Web Architecture Identification, Representation and Interaction


WEP-Terms E. Web Resource Structures

Web Page, Web Collection, SubSite, Web Site, SuperSite F. WebApp & WIS

WIS, WebAppsWWW

WIS

WebSite

WebApp

Web Page (as presented)

Links(URIs)

Web Resource (HTML / XHTML)

Anchors

Embedded WebResources

Web Resource


WEP-Terms G. Web Pages

WebPage Main Resource or (X)HTML Page WebPages Tag Sets

General Tags Structure Head

Structure & Presentation Tag Elements Core Text Extra Text Hypertext MediaObject ClientProgram

Interact Tag Elements & Events Attributes Form ClientScript Events

Embedded code of StyleLangs and ScriptLangs Stylelang ScriptLang


WEP-Terms G1. WebPages at WebServer side

Static WebPage Dynamic WebPage (SSS – Server Side Script)

SESLPage: Server-side Embedded Scripting Language CGIProgram JavaServlet

G2. WebPages at WebClient side WebPage() WebPage(F) WebPage(P)

H. Web Meta-architectures H1. Semantic Web H2. Web Services


WEP-Arch: WebApps’ Classes WebApps’ “Technical-oriented” Classes, according to the

skills, technologies and tools needed for designing, developing and maintaining them Web Hypermedia Application (WHA) Web Front-end Application (WFA) Web Interactive Application (WIA)

WIS = a large-scale Hypermedia Information Space that provides information and services. Information (multimedia content linked via hypertext

metaphor and navigational structures) is provided by WHA through a collection of Static and/or Dynamic WebPages

Services are provided within these WebPages as WFA, through WebForms, ClientScripts & result WebPages and as WIA, through ClientPrograms


WEP-Arch: WebApps’ Logical Architecture WebApps -> Logical Components,

i.e. WebApps parts that can be designed and implemented to some extend independent

Logical Layers: Content (data + metadata + navigation) Logic

Data access Logic Server-side Logic Rendering Logic Client-side Logic

Interface Layout Design Graphical Design WebForms Design GUI Design of

ClientPrograms

0%

20%

40%

60%

80%

100%

Hypermedia Front-End Interactive

Interface

Logic

Content


WEP-Arch: WebApps’ Physical Architecture Logical Components -> Physical Components:

components of the WebApp at run-time. Implementations of Logical Components (like

data sources, programs, stylesheets, etc.) and The run-time infrastructure of the WebApp

(Web Server and its modules, run-time environment of Logical Components, etc.)


WEP-Arch: Logical to Physical Mapping

Data

DataAccess

AppLogic

Rendering

WebServer

WebClient

Data

DataAccess

AppLogic

Communication

Interface

Content

Logic

GUI

Dis

trib

uti

on

Physical TiersLogical Layers Mapping

Local Distributed


WEP-Arch: Physical Components

Physical Components Map to Logical Components

Data SourcesSemi-StructData Content (data, links, metadata)

StructData Content (data, links, metadata)

MediaObjects Interface

MetaData Content (metadata)

WebForm Interface

StyleSheet Interface

ClientScript Logic

ClientProgram Logic, Interface

SSS: Server-Side Script (SESL,CGI,JavaServlet) Logic (rendering)

AccessProgram Logic (data access)

ServerProgram Logic (local / distributed)

WebServer Logic

WebClient Logic


WEP-Arch: Physical Composite ComponentsPhysical Composite Components Map to Logical Components

Static WebPage(): (X)HTML) + embedded StyleLang code + embedded ScriptLang code + link(s) to external StyleSheets + link(s) to external ClientScripts +link(s) to embedded MediaObjects

Content (data, links, metadata), Logic (light client-side)Interface

StaticWebPage(F): StaticWebPage() + WebForms (link to an SSS URI)

Content (data, links, metadata), Logic (form client-side), Interface

StaticWebPage(P): StaticWebPage() + ClientPrograms

Content (data, links, metadata), Logic (client-side), Interface

DynamicWebPage(): a StaticWebPage() produced by an SSS (Input: SSS URI)

Content (data, links, metadata), Logic (data access, client-side), Interface

DynamicWebPage(P): a StaticWebPage(P) produced by an SSS (Input: SSS URI)

Content (data, links, metadata), Logic (data access, client-side), Interface

DynamicWebPage(F): a StaticWebPage(F) produced by an SSS (Input: SSS URI)

Content (data, links, metadata), Logic (data access, form client-side), Interface

DynamicWebPage(FR): a StaticWebPage() or (F) produced by an SSS (Input: SSS URI + form data)

Content (data, links, metadata), Logic (data access, local/distr., client-side), Interface


WEP-Arch: Physical Components per WebApps’ Class

Physical Tiers Hypermedia Front-End Interactive

Data (CLI)

Dist r

DataSources, MediaObjects,StaticWebPages(), StyleSheets, ClientScripts

DataSources, MediaObjects,StaticWebPages(F), StyleSheets, ClientScripts

DataSources, MediaObjects,StaticWebPages(P), StyleSheets, ClientScripts, ClientPrograms

DataAccess (L) AccessPrograms AccessPrograms AccessPrograms

AppLogic (L) ServerPrograms

Rendering (CLI) DynamicWebPages() DynamicWebPages(F) or DynamicWebPages(FR)

DynamicWebPages(P)

GUI (CLI) WebPages() with: StyleSheets, ClientScripts

WebPages(F) or () with: StyleSheets, ClientScripts (form)

WebPages(P) with: StyleSheets, ClientScripts, ClientPrograms


WEP-Arch: Interoperation of Physical and Composite Components

Data

DataAccess

AppLogic

Rendering

WebServer

WebClient

Communication

GUI

WebRequests (+Cookie)At first sendWebResponseAt first send

Produce/manage Cookies

A StaticWebPage

User Prefs

Policy Profile(e.g. P3P)

(X)HTML URI SSS URI SSS URI + form data

A WebPage

DataSource

ServerProgramS

SS

AccessData

Call Program

Produce D. WebPage

ServerProgram(s)

DataSource

WebPage() WebPage(P) WebPage(F)

Information Presentation: WebPages, StyleSheets, MediaObjects (on screen, speakers, etc.):View (text, Docs, images), Watch (video, animation), Hear (audio)

Services’ Interaction (with mouse, keyboard, etc.): Fill Forms, ClientScripts, ClientPrograms

MediaObjectsStyleSheetsClientScripts

ClientPrograms

Programs andData Sources

may beDistributed

over Network

AccessProgram

AccessProgram

DataSource

AccessProgram


WEP-Teams: WIS Project Teams Basic Teams

Domain Team Web Team Content Team Logic Team Interface Team

Hybrid Teams Project Planning Team Project Management and Quality Assurance Team Analysis Team Test Team Evolution Team


WEP-Process: Lifecycle Process Model Based on WEP-Arch, WEP-Teams and WERs,

describe Who is doing What and How Generic Characteristics:

Data-centric & Service-centric General and adaptable Emphasis on component-based development, extensibility,

reusing, easy maintenance, interoperability Cornerstones:

WIS Structure design as a set of interconnected and interoperable WebApps, according to the WebApps’ classes: WHAs, WFAs and WIAs

Identification and design of WebApps’ Logical Components Design and Implementation of WebApps’ Physical

Components


WEP-Process Phases -> Stages -> Activities (Team Members, Workflow, WERs, Input

Artifacts & Output Artifacts) A. Project Planning Phase

WIS Goals, Current Situation, WIS process model, Management Model, Teams, Feasibility Analysis

B. Deployment Phase B1. Requirements Specification & Analysis

Use Case Model, Prototypes, WIS Structure, WIS Technical Specifications, Acceptance Criteria

B2. Logical Design Content Components, Logic Components, Interface Components

B3. Physical Design WIS Physical Architecture Diagram

B4. Implementation & Unit Testing WIS up and running

B5. System testing Testing Reports

C. Evolution Phase


WER-Portal

Taxonomies of Technologies Taxonomies of Research Results Taxonomies of Tools


XML Family TechnologiesClient-Scripts

DOM Level 2

DOM Level 1

Program(read/change data)

Program(read XML data)

XSLT(transform XML to XML)

XQuery

DOM Level 2(support: namespaces, CSS)

DOM Level 1(tree-based XML API)

SAX(event-based XML API)

XPATH 1.0XPATH

2.0

CSS2

CSS1XSL & XSL/FO

URI

XBase

XlinkXPointer

XPathMay use May use May use

Scripting

Style

AccessQuery

Manipulate

Linking

Data

SchemaXML Schema (Data Modeling)

XML Namespaces & URI (XML Schema Elements and Attributes Vocabulary)

XML Files (XML tagged data based on a specific XML Schema)


Semantic Web Architecture and core Technologies

RDF Model & Syntax(XML-Based language)

OWL(OWL Lite, OWL DL, OWL Full)

Model

More Vocabularies(Ontologies)

Vocabularies(Properties & Classes)

DublinCore, P3P,Annotea, NewsML,PRISM, XMLNews,RSS, MusicBrainz,CC/PP, etc.

WIS Resources

Resource Property ValueResource Property Value

RDF VDL or RDF Schema(XML-Based language)

XML Namespaces

URI

WIS ResourcesWIS Resources



Semantic Web

WWW

WebResources

Index

OntologiesIndex

IntelligentAgent

Agent

Semanticallysearch of Web

Resources

Advanced WebOntologies and

Resources SearchKnowledge

Management

Web Portals, Topic Maps,News Channel Syndication,

Calendaring, Scheduling, etc.

Harder

Easier

Search Engines(local or world-wide)

Full-text & field search(headings, title,

embedded metadata, etc.)


Web Services Architecture and

core Technologies

SOAP/XMLwrappers

URIXML/SOAP UDDIregistry

developmenttool

application(soap client)

Web Service

WSDLdefinition

Legacysystem

Static lookup

Descriptionof service’s

interface

Descriptionof service

XML overSOAP/ebXML/IMS

SOAP/XMLwrapper

XML/SOAPdynamiclookup

services”Yellow Pages”

-or-

App. components(e.g. EJB)


Taxonomies of Research Results

Research Areas Research Topics Web Specific Research DataBases & Information

Management Hypermedia engineering Software engineering Network engineering Human-computer

interaction

development methods & process modeling requirements analysis & modeling designing techniques & notations design patterns & good practices testing methodologies evaluation & metrics maintenance issues domain specific research (e-commerce,

education, business processes etc.) security and authentication social and legal aspects (like copyright,

privacy, accessibility, ethical issues) quality assurance & project management


Taxonomies of Tools

Logical Layers Tools Physical Layers Tools Full-scale Development & Run-time Platforms

J2EE-based Platforms .NET Platform Apache Platform


Conclusions

WERs are not used appropriately or at all during current WIS Projects. Web Engineering is a complex information space that needs to be engineered, in order to provide the WERs to developers in a structured and meaningful way

To address these needs we introduce the WEP, in order to structure and present the WERs in a unified framework that provides a Reference Model and a resources Portal

WEP will be presented in more detail as a book chapter of “Web Engineering: Principles and Techniques” that will be published by Idea Group in December 2004


Future Work

WEP must be enhanced by the contribution of other researchers in the field and work together to make it a stable “standard” for Web Engineering community

Implementation of WER-Portal (1st version expected by end of October)

Evaluate WER-Portal in real-life WIS Projects Maintain WER-Portal, in order to include

emerging technologies, research results and tools

WEP: A Reference Model and the Portal of Web Engineering Resources Sotiris Christodoulou & Theodore...

Documents

Transcript of WEP: A Reference Model and the Portal of Web Engineering Resources Sotiris Christodoulou & Theodore...