software architecture session11

The World Wide Web

A Case Study in Interoperability

1

Introduction The most dramatic example of the workings of

the Architecture Business Cycle can be found in the way in which the goals, business model, and architecture of the World Wide Web have changed since its introduction in 1990.

No one—not the customers, the users, or the architect (Tim Berners-Lee)—could have foreseen the explosive growth and evolution of the Web.

04/13/23 2

History of WWW The original proposal for the Web came from Tim Berners-

Lee, a researcher with the Conseil Européen pour la Recherche Nucléaire (CERN), who observed that the several thousand researchers at CERN formed an evolving human "web."

People came and went, developed new research associations, lost old ones, shared papers, chatted in the hallways, and so on, and Berners-Lee wanted to support this informal web with a similar web of electronic information.

In 1989, he created and circulated throughout CERN a document entitled Information Management: A Proposal.

By October of 1990 a reformulated version of the project proposal was approved by management, the name World Wide Web was chosen, and development began.

04/13/23 3

Relationship to the Architecture Business Cycle

04/13/23 4

Requirements and Qualities The World Wide Web, as conceived and initially

implemented at CERN, had several desirable qualities portable, interoperatable with other types of computers running the same software, scalable and extensible.

The business goals of promoting interaction and allowing heterogeneous computing led to the above mentioned quality goals.

libWWW embodies strict separation of concerns and therefore works on virtually any hardware and readily accepts new protocols, new data formats, and new applications. Because it has no centralized control, the Web appears to be able to grow without bounds.

04/13/23 5

The Original Requirements Remote access across networks

Any information had to be accessible from any machine on a CERN network.

Heterogeneity The system could not be limited to run on any

specific hardware or software platform. Noncentralization

The operation of linking to a document, in particular, had to be decentralized.

Access to existing data Existing databases had to be accessible.

04/13/23 6

The Original Requirements Ability for users to add data.

Users should be able to "publish" their own data on the Web, using the same interface used to read others' data.

Private links. Links and nodes had to be capable of being

privately annotated. Bells and whistles.

The only form of data display originally planned was display on a 24 x 80 character ASCII terminal. Graphics were considered optional.

04/13/23 7

The Original Requirements Data analysis.

Users should be able to search across the various databases and look for anomalies, regularities, irregularities, and so on.

Live links. Given that information changes all the time,

there should be some way of updating a user's view of it. This could be by simply retrieving the information every time the link is accessed or (in a more sophisticated fashion) by notifying a user of a link whenever the information has changed.

04/13/23 8

Other Criteria and Features Controlling topology Defining navigational techniques and

user interface requirements, including keeping a visual history

Having different types of links to express differing relationships among nodes

04/13/23 9

Architectural Solution of WWW

04/13/23 10

Meeting The Original Requirements: libWWW

04/13/23 11

Lessons from libWWW Formalized application programming

interfaces (APIs) are required. These are the interfaces that present the

functionality of libWWW to the programs built on top of it.

Functionality and the APIs that present it must be layered. Different applications will need access to

different levels of service abstraction, which are most naturally provided by layers.

04/13/23 12

Lessons from libWWW The library must support a dynamic,

open-ended set of features. All of these features must be replaceable,

and it must be possible to make replacements at runtime.

Processes built on the software must be thread safe.

Web-based applications must support the ability to perform several functions simultaneously

04/13/23 13

An Early Client-Server Architecture Using libWWW

04/13/23 14

Common Gateway Interface CGI scripts, allow dynamic, request-specific

information to be returned. CGI has historically been used to augment

server functionality: for input of information, for searches, for clickable images.

The most common use of CGI, however, is to create virtual documents—documents that are dynamically synthesized in response to a user request.

04/13/23 15

CGI CGI solved many problems inherent in the

original design of libWWW— Principally because it provided much needed server

extensibility to handle arbitrary resources, allowed users to put data in limited ways

It also had several substantial shortcomings. The security issue was one; another was portability.

CGI scripts written in VisualBasic, AppleScript, and C Shell work on Windows, Macintosh, and UNIX, respectively. These scripts cannot be (easily) moved from one platform to another.

04/13/23 16

Achieving Initial Quality Goals

04/13/23 17

The Evolution of Web-Based E-Commerce Architectures

The incredible success of the Web has resulted in unprecedented interest from business and hence unprecedented pressure on the architecture, via the ABC.

Business requirements have begun to dominate Web architecture.

Business-to-business and business-to-consumer Web sites have fueled most of the innovation in Web-based software.

04/13/23 18

Requirements of e-commerce High performance

A popular Web site will typically have tens of millions of "hits" per day, and users expect low latency from it.

High availability E-commerce sites are expected to be available "24/7.”

Scalability As Web sites grow in popularity, their processing capacity must be able to

similarly grow, to both expand the amount of data they can manage and maintain acceptable levels of customer service.

Security Users must be assured that any sensitive information they send across the

Web is secure from snooping. Operators of Web sites must be assured that their system is secure from attack

Modifiability E-commerce Web sites change frequently, in many cases daily, and so their

content must be very simple to change

04/13/23 19

A typical e-commerce system

04/13/23 20

Achieving Quality Goals

04/13/23 21

The Architecture Business Cycle Today

04/13/23 22

Summary The Web has been so successful because of

the manner in which the desired qualities were realized in its architectural structures, and in how these structures have been reinvented in the face of dramatic new requirements.

The success of the Web has meant that the ABC has been traversed multiple times in just a few years, with each traversal creating new business opportunities, new requirements, and new technical challenges.

04/13/23 23

J2EE/EJB

A Case Study of an Industry-Standard Computing

Infrastructure

04/13/23 24

Introduction J2EE provides a standard description of how

distributed object-oriented programs written in Java should be designed and developed and how the various Java components can communicate and interact.

EJB describes a server-side component-based programming model.

Taken as a whole, J2EE also describes various enterprise-wide services, including naming, transactions, component life cycle, and persistence, and how these services should be uniformly provided and accessed.

04/13/23 25

The ABC of J2EE/EJB

04/13/23 26

Requirements and Qualities The Web And J2ee

04/13/23 27

Sun's Quality Attribute Requirements for J2EE

04/13/23 28

Architectural Solution The major features of the J2EE

platform are :- A multi-tiered distributed application

model A server-side component model Built-in transaction control

04/13/23 29

J2EE multi-tier architecture

04/13/23 30

J2EE Technology Components and Services

04/13/23 31

How EJB Supports Sun's J2EE Quality Attribute Requirements

04/13/23 32

How EJB Supports Sun's J2EE Quality Attribute Requirements

04/13/23 33

EJB Programming

04/13/23 34

Summary The creation of the J2EE multi-tier architecture

was motivated by the business needs of Sun Microsystems.

These business needs were influenced by the lessons of the CORBA model and by the competitive pressures of other proprietary distributed programming models, such as COM+ from Microsoft.

J2EE features a server-side component framework for building enterprise-strength server-side Java applications, namely, Enterprise JavaBeans.

04/13/23 35

The Luther Architecture:

A Case Study in Mobile Applications Using J2EE

04/13/23 36

Introduction The Luther architecture was designed to

provide a general framework within which Inmedius could provide customized solutions for the maintenance problems of its customers.

It is based on the Java 2 Enterprise Edition (J2EE) architecture, so becomes an application of the general J2EE/EJB framework to an environment where the end user is connected over a wireless network and has a device with limited input/output capabilities, limited computational capabilities, or both.

04/13/23 37

Relationship to the Architecture Business Cycle

04/13/23 38

Requirements Wireless access User interface Device type Existing procedures, business

processes, and systems Building applications Distributed computing

04/13/23 39

Architectural Solution It is commercially available from a variety of

vendors. HTTP becomes the basis of communication

because it is layered on top of the TCP/IP protocol, which in turn is supported by a variety of commercial wireless standards

It separates the user interface and allows the user experience paradigm to be implemented. This paradigm proposes that the computer and its application be another, noninvasive, tool for the field service worker.

04/13/23 40

Architectural Solution It supports the separation and

abstraction of data sources. The user experiences require the filtering, fusion, synthesis, and display of data that comes from multiple, disparate data sources

04/13/23 41

Architectural Solution

04/13/23 42

Ramification of using J2EE Decisions Made by Design versus Those

Dictated by J2EE When designing a system using the J2EE runtime

environment, some decisions are left up to the designer and others are constrained by the J2EE rules and structure.

For example, J2EE mandates where servlets, JSPs, and EJBs reside within a container—servlets and JSPs in the Web tier and EJBs in the EJB tier.

04/13/23 43

Ramification of using J2EE Issues Introduced by the Multiple Tiers in the

J2EE One issue is performance. A major contributor to

poor performance is the number of calls made from one J2EE entity (e.g., servlet, EJB) to another within a given transaction.

Technically, each EJB method call is an RMI call, which can be very expensive. The implementation of coarse-grained EJBs and the elimination of inter-entity EJB relationships are two ways to address this issue and thereby ensure good component performance.

04/13/23 44

How Luther Achieved Its Quality Goals

04/13/23 45

Summary Inmedius develops solutions for field service

workers. Luther is a solution that Inmedius constructed

to support the rapid building of customer support systems. It is based on J2EE.

A great deal of attention has been given to developing re-usable components and frameworks that simplify the addition of various portions, and its user interface is designed to enable customer- as well as browser-based solutions.

04/13/23 46

PATTERN-ORIENTED SOFTWARE ARCHITECTURE

VOLUME 2

Chapter 2: Architectural Patterns

04/13/23 47

Introduction Architectural patterns represent the

highest-level patterns in our pattern system.

They help you to specify the fundamental structure of an application. Every development activity that follows is governed by this structure

04/13/23 48

Architectural Patterns Patterns that help to support similar

properties can be grouped into categories

From Mud to Structure : this category help you to avoid a 'sea' of components or objects. This category includes the Layers pattern, the Pipes and Filters pattern.

Distributed Systems : This category includes one pattern. Broker and refers to two patterns in other categories, Microkernel and Pipes and Filters . The Broker pattern provides a complete infrastructure for distributed applications.

04/13/23 49

Architectural Patterns Interactive Systems : This category comprises two

patterns, the Model-View-Controller pattern, well-known from Smalltalk and the Presentation-Abstraction-Control pattern. Both patterns support the structuring of software systems that feature human-computer interaction.

Adaptable Systems : The Reflection pattern and the Microkernel pattern strongly support extension of applications andtheir adaptation to evolving technology and changing functional requirements.

04/13/23 50

Example Pattern: Pipes and Filters

04/13/23 51

Example Pattern: Pipes and Filters [2] E.g Unix Shell programs, Compilers Characteristic: Filters are

independent No data sharing Do not know upstream / downstream

filters Correctness does not depend on

order of incremental processing

04/13/23 52

Example Pattern: Pipes and Filters [3] Advantages

Often reduces to batch processing system

Difficult to support interactive applications

04/13/23 53

Example Pattern: MVC SmallTalk’s user interface

framework Model - refers to data model View – refers to external views or

presentation of data. Controller – refers to module relating

reactions of view or presentation to changes in data.

04/13/23 54

Example Pattern: MVC [2] Need to separate presentational aspects with

the data, i.e. separate views and data. Classes defining application data and

presentation can be reused. Change in one view automatically reflected in

other views. Also, change in the application data is reflected in all views.

Defines one-to-many dependency amongst objects so that when one object changes its state, all its dependents are notified.

04/13/23 55

Layered Systems Characteristics

Hierarchical organization Each layer provides services to layer(s)

above Each layer acts a client to layer(s) below A layer may be partially opaque

Key Design Issues Inter-layer interaction Constrained interaction

04/13/23 56

Layered Systems – Basic Model

04/13/23 57

Core

Useful systems

Basic utility

User

ISO-OSI Model

Physical Layer

Data Link Layer

Network Layer

Transport Layer

Session Layer

Presentation Layer

Application Layer

Constrained Interaction

Strenths & Weaknesses ?

Layered Systems – Example

Layered Systems – Example

04/13/23 59

Flexible Interaction

Internet Model

Physical Layer

Data Link Layer

IP Layer

TCP/UDP Layer

Application Layer

Robot Control

Sensor Interpretation

Sensor Integration

Real-World Modeling

Navigation

Control

Global Planning

Mobile RoboticSystem

Constrained Interaction

Layered Systems – Example

Layered Systems- Benefits Design based on increased levels of

abstraction Easy Problem partitioning for designers

Support for Enhancements Easy addition/change of module

Re-use Standardized layer interfaces to which

implementers can build

04/13/23 61

04/13/23 62

Layered Systems- Issues Not all problems/domains amenable for

layering Difficult to find the right abstractions

Legacy interfaces/protocols Performance

Tighter coupling needed in practice Standardized layer interfaces to which

implementors can build

04/13/23 63

Layered Systems - Comparison Vs. Data Abstraction

Hiding is common factor Layering allows multiple levels of abstraction

Vs. Pipes & Filters Restricted Communication is common factor Instead of simple read/write complex interactions

allowed 2 ways transmissions permissible Closer interaction possible But makes it difficult to define system independent

modules (filters?) – Reduced Reuse

04/13/23 64

Other Examples Identify the layers in the following

contexts ? File Systems DBMS Java

04/13/23 65

Repository Style Two basic (types of) components

A central data store for current state Independent components operating on the

store Choice of control (selection of processes)

Input Transactions are the determinants - Databases

Current state of the store is the determinant – Blackboards

Repository Style for Database

04/13/23 66

Database

Report

T1T2 T3

T - Transaction

04/13/23 67

Blackboard Architecture Components

Knowledge Sources Control mechanism Blackboard

Data, partial solutions (hypotheses)

Problem Solving Incremental or Opportunisitic

Architecture for Compilers

04/13/23 68

Lex – Lexical AnalyzerSyn – Syntax AnalyzerSem – Semantic AnalyzerOpt – (Code) OptimizerCode – Code Generator

Traditional / Simplistic View : Batch Seq. or Pipe/Filter

Blackboard Architecture for Compilers

04/13/23 69

Blackboard View for Compilers

04/13/23 70

A better perspective!

04/13/23 71

Repositories - Other Situations Software Development

Environments Data Dictionaries Code Repositories

Blackboard AI – Signal Processing (Speech /

Pattern Recognition)

Broker Architecture Context: Distributed Systems

particularly Client Server systems Components:

Clients, Servers, Proxies, Brokers, Bridges

04/13/23 72

Broker Architecture

04/13/23 73

Client Proxy

Client

Server Proxy

Server

Broker

Call

Message

Call

Message

Use API

Register

(Distributed) Broker Architecture

04/13/23 74

Client Proxy

Client

Server Proxy

Server

Broker

Call

Message

Call

Message

Use API

Register

Broker

Use API

Bridge Bridge

Forward

Broker Architecture

04/13/23 75

Benefits Location Transparency Changeability / Extensibility of components Portability (of client and server) Portability (of brokers) & Interoperability

(among brokers) Reusability

Disadvantages Overheads – Performance Loss Lower fault tolerance Developmental issues (Testing / Debugging)

Broker Architecture

04/13/23 76

Examples OLE, COM, DCOM (platform depend.) CORBA (language/platform neutral) RMI / Jini (language depend.)

Broker Architecture – Design Patterns

04/13/23 77

Proxy (object structural) Provide surrogate / placeholder for

another object to control access to it. Bridge (object structural)

Decouple an abstraction from its implementation (so that they can vary independently)

Microkernel

04/13/23 78

Internal Server

External Server

Microkernel

External Server

Adapters

Clients

Microkernels

04/13/23 79

Typical scenarios: Platforms (OS, S/W Development, User

Interface Toolkits) (Customizable) Servers

Examples Windows NT (OS/2, POSIX, Win32 externals) Java Swing ?? IIS (Adapters – ISAPI, MAPI, TAPI filters)

Microkernels

04/13/23 80

Benefits Portability Flexibility and extensibility Separation of policy and mechanism Scalability/Reliability/Transparency in

distributed microkernels Disadvantages

Performance Complexity (Design and Implementation)

Thank You

81