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-web-

systems-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 Blueprints—The “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 requirements—what 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 system’s integrity, of fault-

tolerance

Development View

The development architecture focuses on the actual

software module organization on the software development

environment.

The software is packaged in small chunks—program

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 objects—need 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 it’s 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 data-

centric;

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 Recommender System

Dialog

Manager

Application

Services

State Manager

RECOMMENDATION AGENT

Decision

Manager

Policy

Manager

Learning

Manager

Log

Manager

Product

Catalogues

Log DataCase Base

Database

Navigation

Manager

Session

Manager

User

Logical view, domain model

Infrastructural view

Development view

RECOMMENDATION AGENT

ectrl.recommendationagent.decisionmanagerectrl.recommendationagent.logmanager

ectrl.recommendationagent.learningmanager

ectrl.recommendationagent.policymanager

AgentEnvFlowImpl

AgentEnvFlow

<<interface>>

VerificationService

PolicyModel

<<interface>>

PolicyModelImpl

ActionLearner

InteractionManager

<<interface>>

InternalAppStateManager

SystemActionManager RewardManager

RLAlgorithm

LoggedDataProvider

PolicyStats

DBImport

Logger

<<interface>> LoggerImpl

LogModel

DBAccess

<<interface>>

DBAccessImpl

InteractionManagerImpl

Phisical View (UML)

What is a Portal Server?

A framework for integrating information, applications and processes across organizational boundaries

Portal

CRM

ERP

CMS

External sites

Web Mobile Third party web sites

Intranet Extranet

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

Sheffield, 25 – 1 /2/2013 Kick off Meeting

• Simple HTML snipplet to be put on partners’ websites.

• Highly customizable

• Low integration and maintenace costs

• Easy to be integrated on any website

Portal servers

Liferay

JBoss Portal

Apache JetSpeed 2

Apache Pluto

eXo platform

uPortal

IBM Websphere

Portal

BEA WebLogic

Portal

Sun Portal Server

Oracle Portal

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, standards-

based 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