Advanced Web Systems

1- Web Architectures
A. Venturini

Contact Details

Adriano Venturini

adriano.venturini@unibz.it

Availability :

by prior arrangement via e-mail

During the lecture time span, Piazza

Domenicani, office 2.10

Course web site

http://unibz.ectrldev.com/advanced-websystems-course

Course Structure

Lectures: 24 hours

Labs: 12 hours

Timetable:

Lectures: Friday, 14.00 16.00. (E411)

Labs: Friday 16.00-17.00. (E411)

Assessment:

final exam, written, 50% of the grade

project (1 or 2 students per project) 50%.

Motivatiton

Internet and World Wide Web is built on

interconnected systems which cooperates to
provide services to people

Web based systems can be very complex:

Exposes services to thousands of concurrent

users

Integrate with existing systems

Integrate with remote systems on the web

This should be addressed using the right

architectures, technologies and tools

Well defined interfaces

Proven existing technologies

Goals of the course

Analysis both methodological and practical of

the advanced approaches for web systems:

Web architectures

Frameworks for developing web systems

Portal Server technologies

Persistence technologies

Web 2.0 (ajax technologies)

You will learn

Learn how web portals are built and structured

Study the basic design patterns adopted by the

such sistems

Learn to design and structure complex web

solutions

In depth view of basic technologies adopted

today

Build web applications exploiting the concepts

described during the lectures (labs)

Course Format

12 Lectures on various topics in Advanced Web Systems

12 Labs where you will

Run yourself the examples shown during the lecture

Solve some new exercises

Build your own example applications

Work on your final exam project

Books

Ashish Sarin, Portlet in actions, Manning Publications

Co., 2011.

Craig Walls with Ryan Breidenbach, Spring in Action,

Third edition, Manning Publications

http://www.manning.com/walls3/WebXtras.pdf

Syllabus

Web Architectures

Portal Server Architectures

JSR 168 and 286 Portlet Technologies

Various design patterns like:

Model View Controller Pattern

Factory pattern

Singleton pattern

Object Relational Mapping

Web 2.0. Ajax technologies.

Remoting Web Services

Challenges

Internet technologies are evolving very fast

To build a Web-based application you should

have a very wide knowledge of many software
and communication technologies

There are dozens of competing approaches for

building web applications

We cannot cover all the possible technologies

We will follow some of the most adopted

approaches on real web portals

What we shall not cover

Adobe Dreamweaver

PHP

Ruby on Rails

ASP.NET

C#

JavaServer Faces

Web services

Project

The project is conducted individually (or 2 persons)

The objective is to develop a dynamic, database

supported, portal based web application:

The student must choose the functions they likes the best

All the techniques illustrated in the lectures must be

properly applied (not a simple, static HTML-based web site)

The project result is a running system and a written

report (design document).

In case of 2 persons:

Both should know all developed system

Structure of the Project

The application must run on the application

server that we shall indicate in the labs

The report must describe

The functions of the web application and their

motivation

The architecture of the application (modules and

their roles)

Main classes and main methods

Major technical problems found during the work

The project will be evaluated according to:

complexity of the implemented functions, user
interface usability and completeness, organization of
the code.

What is needed for passing the exam

Read and understand the slides presented during the

lecture

Read the book chapters or articles that will be

suggested for each lecture

If something is not clear during a lecture you must

take a note and rise a question (especially in the
labs)

Develop and test your application (for example run

it on both Firefox and IE)

Upload the project and send me the report in time.

Exam

The final grade is obtained evaluating the project result and

the knowledge acquired about the lectures topics in an
written exam

Written exam: questions on the topics illustrated

The project results will be presented in a seminar during the

last lecture (5 mins per presentation)

The final written report and project must be sent to me on

time at the communicated deadline (typically 1 week before
the written exam)

You will have two grades: P (project), max 15 points, and

W (written exam), max 15 points

The final grade is F = P + W

Both P and W must be greater or equal to 9.

lecture topics
1.

Software and Portal Architectures

2.

Portal server and Portlets

3.

Portlets and JSP

4.

Light Weight Containers

5.

Web Layer, basic patterns

6.

Web Layer, part 2

7.

Data Layer, Object Relational Mapping Tool

8.

Aspects and Annotation

9.

Transactions

10.

Ajax and Dynamic Web Remoting

11.

Ajax framework

12.

Summary and exam procedure

Contents

Software Architectures

Multiple views for describing a system

Overview of portal concept

Functionalities

Overall architecture

Software Architecture

Software architecture deals with the design and

implementation of the high-level structure of the
software.

To describe a software architecture, are used a

model composed of multiple views or
perspectives.

In a Software Architecture Document, typically

each view is one or more chapters

The project report should be structured like a

software architecture document

4+1 View Model

Ref: Architectural BlueprintsThe 4+1 View Model of Software

Architecture, Philippe Kruchten, IEEE Software, 12

Logical View

The logical view is the object model of the design

supports the functional requirementswhat the

system should provide in terms of services to its
users.

The system is decomposed into a set of key

abstractions, taken (mostly) from the problem
domain, in the form of objects or object classes.
They exploit the principles of abstraction,
encapsulation, and inheritance.

Class diagrams and sequence diagrams

Process View

Describe the processes and how they

communicate

Deal with parallelism, multithread and

concurrency issues

The process architecture takes into account some

non-functional requirements, such as
performance and availability.

It addresses issues of concurrency and

distribution, of systems integrity, of faulttolerance

Development View

The development architecture focuses on the actual

software module organization on the software development
environment.

The software is packaged in small chunksprogram

libraries, or subsystems that can be developed by one or
a small number of developers.

The subsystems are organized in a hierarchy of layers, each

layer providing a narrow and well-defined interface to the
layers above it.

The development architecture of the system is represented

by module and subsystem diagrams, showing the export
and import relationships.

the rules that govern the development architecture:

partitioning, grouping, visibility.

Development View (2)

The development architecture takes into account

internal requirements related to the ease of
development, software management, reuse or
commonality, and to the constraints imposed by
the toolset, or the programming language.

The development view serves as the basis for

requirement allocation, for allocation of work to
teams (or even for team organization), for cost
evaluation and planning, for monitoring the
progress of the project, for reasoning about
software reuse, portability and security.

Phisical View

The physical architecture takes into account availability,

reliability (fault-tolerance), performance (throughput), and
scalability.

The software executes on a network of computers, or

processing nodes.

The various elements identified networks, processes,

tasks, and objectsneed to be mapped onto the various
nodes.

We expect that several different physical configurations will

be used: some for development and testing, others for the
deployment of the system for various sites or for different
customers.

The mapping of the software to the nodes therefore needs

to be highly flexible and have a minimal impact on the
source code itself.

Scenarios

The elements in the four views are shown to work together

seamlessly by the use of a small set of important scenarios
(instances of more general use cases)

The scenarios are in some sense an abstraction of the most

important requirements. Their design is expressed using
object scenario diagrams and object interaction diagrams.

A driver to discover the architectural elements during the

architecture design

as a validation and illustration role after this architecture

design is complete, both on paper and as the starting point
for the tests of an architectural prototype.

Tailoring the model

Not all software architecture need the full 4+1

views.

Views that are useless can be omitted from the

architecture description

such as the physical or the process view, if

there is only one processor, and the process
view if there is only process or program.

The scenarios are useful in all circumstances.

Typically is added the infrastructural vew, which

descibes the main existing technologies adopted
within the project

Interface view

Description of the APIs among components

Closely related to the logical view is the interface

view. Interfaces are one of the riskiest parts of
any software system, so its very useful to show
what the internal external interfaces are and how
they work

Can be part of the development view

Data View

A specific data view is worth including in your

architecture diagram if your system is datacentric;

managing a large quantity of data or dealing with

complex data flows.

This section can include information such as

sizing and capacity planning through to archives
and backups

Possible index of a software architecture document

Introduction

Logical view:

logical components

main domain objects (entities managed by the system)

Technology (existing software components to be

extended/adopted)

Development view

Software components, APIs

Data view: data model

Process view: basic process managed by the system

Phisical view: hardware (server, clients)

Logical view: context

ENVIRONMENT

Database

Recommender System

Dialog
Manager

Application
Services

Product
Catalogues

State Manager
User

Case Base Log Data

Navigation
Manager

Decision
Manager

Log
Manager

Session
Manager

Policy
Manager

Learning
Manager

RECOMMENDATION AGENT

Logical view, domain model

Infrastructural view

Development
view

RECOMMENDATION AGENT
ectrl.recommendationagent.logmanager

ectrl.recommendationagent.decisionmanager

<<interface>>
Logger

<<interface>>
AgentEnvFlow

LoggerImpl

DBAccessImpl
DBImport
AgentEnvFlowImpl

VerificationService

LogModel

<<interface>>
DBAccess

ectrl.recommendationagent.learningmanager
ectrl.recommendationagent.policymanager

<<interface>>
InteractionManager

LoggedDataProvider

PolicyModelImpl

InteractionManagerImpl

<<interface>>
PolicyModel

RLAlgorithm

InternalAppStateManager

PolicyStats
ActionLearner

SystemActionManager RewardManager

Phisical View (UML)

What is a Portal Server?

A framework for integrating information, applications
and processes across organizational boundaries
Web
Mobile
Third party web sites

Extranet

Intranet

Portal

CMS
CRM
ERP

External sites

Multiple services

Multiple Services (2)

Personalization Features

Mobile Services

Sheffield, 25 1 /2/2013 Kick off Meeting

Localized Search

Sheffield, 25 1 /2/2013 Kick off Meeting

Accommodations..

Sheffield, 25 1 /2/2013 Kick off Meeting

Widget Technology
Simple HTML snipplet to
be put on partners
websites.
Highly customizable
Low integration and
maintenace costs
Easy to be integrated on
any website

Sheffield, 25 1 /2/2013 Kick off Meeting

Portal servers

IBM Websphere
Portal

BEA WebLogic
Portal

eXo platform

Sun Portal Server

uPortal

Oracle Portal

Liferay

JBoss Portal

Apache JetSpeed 2

Apache Pluto

Typical Portal Features

Robust application integration

Personalization

Development tools

Redundancy, failover, & load balancing

Mobile/wireless support

Single Sign-On

Security

Service aggregation

Content management

Content classification (metadata)

Content search & indexing

Feature - Application Integration

A portal allows to integrate web-based

applications

single sign-on

inclusion of external web resources

support for web services

Different application but seamless integrated

Common

layout !

Common

menu, header, footer

Communication among applications

Application can communicate:

Exchange messages or events

Invoke functionalities of other applications

Initial portal specification: JSR 168

Does not adress this feature

Partially covered by JSR 286

Feature - Personalization

Easy create of new pages or portal sections

display different views of organizational data

based upon user groups.

Individual users can further customize their

view to only display the content they use most
often.

Feature - Development Tools

A portal product provide robust, standardsbased development tools that allow to:

integrate applications

extend

portal functionality

Feature - Mobile & Wireless Support

Cross-platform functionality that allow users of

different operating systems and web browsers
to access the portal.

Support for mobile phones and wireless PDAs.

Feature - Single Sign-On

A portal should integrate with or provide a

single sign-on system. In other words, a
portal should pull user information from a
directory server such as LDAP, NDS, or Active
Directory.

Feature - Security

Robust authentication and authorization

systems.

Any integration with a single sign-on system

should be secure and prevent the unencrypted
transmission of user credentials across
application domains.

Single Sign On: user logs once (in the portal)

and can automatically access all the services
which he is allowed

Content Management

A portal provides content authoring systems

that allow non-technical staff to create
content.

Control access to content to allow only

authorized users access to document
repositories.

In principle, Content Management Systems is a

service (external application) which could be
integrated within the portal

Categorization of Content

A portal allows you to organize content and

applications in different ways in order to meet
the needs of various groups within your
organization.

Metadata used to classify contents

Content Search & Indexing

A portal should provide or integrate with

document index and search systems so that
users can quickly navigate to the information
they need.

Feature - Enterprise IT Functionality

A portal should provide standard enterprise

software functionality:

Redundancy

Failover

Load balancing (scalability)

backup

Questions