Contact Details
Adriano Venturini
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
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
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
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