Date post: | 19-Jun-2015 |
Category: |
Software |
Upload: | swapnil-kulkarni |
View: | 338 times |
Download: | 0 times |
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