Dynamic Software Architecture

1
Dynamic Software Architecture

• Dr. Ali Arsanjani
• aarsanjani_at_mum.edu
• www.arsanjani.com/arch

2
Maharishi International University
1971-1995 MAHARISHI UNIVERSITY OF
MANAGEMENT Engaging the Managing Intelligence of
Nature Advanced Software Development
II Dynamics of Software Architecture CS526 Dr.
Ali Arsanjani 2004 Maharishi's Year of Raja
Raam
The software architecture of a program or
computing system is the structure or structures
of the system, which comprise software components
and connectors, the externally visible
properties of those components and connectors
and the relationships among them. 1
3
Software Architecture

• Components
• Connectors
• Relationships
• Constraints
• Containers
• Composition
• Configurations

4
http//groups.google.com/group/softarch2008
5
All files available through PDF on
website http//www.arsanjani.com/arch/arch.htm
6
Software Architecture
Why deploy this logical component on this
physical node?
Why? This component what are its boundaries and
why
Composition? (logical grouping)
Node
Node
Component
Component
Composition
Why? Why is this connection there? What are the
properties of this connector?
Component
Component
Node
Node
How do I deploy my components to meet NFRs?
(physical grouping)
Component
Component
Connectors
Component
Why?
Composition
Architectural Decisions
Component
Component
Component
Physical Connectors
Node
Hardware Node
7
Wholeness

• Looking at the entire set of applications that
  supports a business
• Looking at each layer, tier, component on that
  tier
• Looking at how components are deployed on nodes

8
IBM defines the following six architecture
disciplines

• Enterprise architecture. An enterprise architect
  focuses on mapping IT capabilities to business
  needs. The architect is responsible for an
  enterprise's full range of software-intensive
  systems, including the relationship between
  multiple applications, data shared between
  applications, integration of the applications,
  and the infrastructure to run applications.
• Application architecture. An application
  architect focuses on the design of applications
  to automate business processes and provide
  functionality that helps users perform business
  tasks. The architect's responsibilities include
  designing the application to meet user functional
  and quality of service requirements including
  performance, availability, scalability, security,
  and integrity. Responsibilities also include
  evaluating and selecting the software and
  hardware necessary to run the application, as
  well as the tools and methodologies to develop
  the application.
• Information architecture. An information
  architect focuses on the data used by multiple
  applications, including the structure, integrity,
  security, and accessibility of that data. The
  architect's responsibilities include designing,
  building, testing, installing, operating, and
  maintaining the systems for managing that data.
  Design of these systems must account for data
  requirements such as source, location, integrity,
  availability, performance, and age.

9

• Infrastructure architecture. An infrastructure
  architect focuses on the design of hardware and
  server software including server computers,
  storage, workstations, middleware,
  non-application software, networks, and the
  physical facilities that support the applications
  and business processes required by the
  enterprise. The architect's responsibilities
  include evaluation and selection of these
  components modeling, simulating, and testing to
  validate the designs and selected products and
  performance, availability and scalability of the
  resulting infrastructure.
• Integration architecture. An integration
  architect focuses on the design of solutions that
  enable existing applications, packaged software
  offerings, networks, and systems to work together
  within an enterprise or among enterprises. These
  solutions may use different technologies,
  vendors, platforms, and styles of computing.
• Operations architecture. An operations architect
  focuses on the design of solutions to manage the
  infrastructure and applications used by the
  enterprise. The architect's responsibilities
  include defining plans, strategies, and
  architectures for the installation, operation,
  migration, and management of complex information
  systems.

10
Enterprise Architecture

• Exploring IT architecture disciplines, Part
  1 Build an enterprise architecture
• http//www.ibm.com/developerworks/architecture/lib
  rary/ar-eaoverview/?S_TACT105AGX78S_CMPHP
• EA
• http//en.wikipedia.org/wiki/Enterprise_architectu
  re

11
You can deploy components on one node or several
nodes as determined by non-functional requirements
WS
AS
WS
DB
AS
AS
AS
DB
12
Architecture

• Functional and Non Functional Rqs
• Non-functional fulfillment may require --
  redundancy
• Redundancy
• In order to fulfill non-functional reqs
• Availability
• Performance
• security

13
1
3
WS
AS
WS
DB
Get Loan loan is up 99.997
Process loan is up 94
AS
AS
DB
14
Spectrum of Trade-offs made by an Architect based
on business priorities
Business priorities drive architectural decisions
6 months
12 months
current
Ideally here
??
1
3
15
Architectural Styles?

• An Architectural Style is a pattern of
  architecture
• Participants in the pattern are components and
  connectors
• Constraints, compositions, containers are other
  attributes of a style

16
Document Architectural Decisions as Patterns

• Pattern / Arch Dec Format
• Name ( Pattern or a Arch decision name)
• Context (Background)
• Problem
• Forces (Tradeoffs)
• Solution (to balance the forces in the problem
  space)
• Consequences

17
Block Diagram Section
AJAX
Web-client
RIA-client
Protocols
http/s
RIA-client
Apache HTTP Server
Web Server
Web Server
Tomcat
??
Application Server
DB
Servlet/JSP Container
18
Compositions, Configurations
deployment
Application Server
.ear, .war,.cnf,.xml
.ear
19
Garlan and Shaw
20
Arsanjani

• Add containers and composition to the notion of
  software architecture
• Dynamic containers and dynamic composition will
  enable dynamic architecture

21
Assignments

• Readings are indicated at arsanjani.com/arch/readi
  ng.htm

22
Readings

• 2
• 1 (4 Arch styles)
• EA (briefly) definition

23
Groups
Members Tasks
1 Sudeep, Tikaprem,Ardhi,Nir,Muskan
2 Thao,Khoa,Sabin, Amir,Jayaram
3 Mohan, Maxim,
4 Jonas, Yosef,Samuel, Hiwot, Alexander
5 Ebe, Viburanga,Pubudu,
6 Yonas K, Alemayehu, Isayas, Anteneh
24
Where is my Money.com

• Secure internet access to My Purchases and
  transactions
• Where is my money going?
• Personal account management system
• Open Account/Close Account
• Enter Customer Info
• Transactions
• (Debits) Purchases date , amount, item
  description
• Credits you got paid, add
• Reports
• One report Display All Transactions

25
Financial Tracking Application Functional
Requirements

• Use-case List
• Open Account, Close Account
• Enter Transactions
• Get Balance, Debit, Credit
• Define Category (nested to three levels)
• Assign Transaction to Category
• Generate Report
• Display All Transactions

26
Document Architectural Decisions

• Components
• Interactions (Connectors)
• Constraints
• Containers
• Compositions

27
Architectural Decisions can be expressed as
patterns

• Pattern
• Context- background
• Problem
• Forces tradeoffs, conflicting constraints
• Solution-resolves the forces or the conflicting
  constraints
• Consequences

28
Action Items ()

• Read and learn the Arch Style
• Discuss a design of the 2 styles you have chosen
• Class Diagram
• Architectural Decisions
• Run a use-case through each design
• Simplest first, then create a release plan
• Demo, Presentation, report

29
(No Transcript)
30
¾ of the Universe consists of dark energy ¼ of
matter/energy

• So what?
• ¾ of the time spent on software development is
  spent on maintenance, but creating it is an
  implicit cost, not tracked with regard to why we
  build software the way we do
• ¼ is spent on creating and is an explicit cost

31
¾ of a software architecture is not seen
/observable by the users
observed
Not observed
View
Front Controller
Back Controller
Model
32
Software Architecture

• Wholeness of the system
• functional and
• Use-cases
• non-functional requirements
• Application Architecture
• Components
• Interactions, connectors
• Diagram
• Block Diagram (hi-level)
• Class Diagrams, Interaction Diagrams (Sequence,
  State, Activity)
• Design or architectural decisions
• ABC2
• Patterns you will be using

33
Solution Architecture (Design)

• Parts of the system
• How parts fulfill functional and non-functional
  requirements
• Solution Architecture
• Components
• Interactions, connectors
• Diagram will contain details on technology
  bindings or mappings
• Block Diagram (contain technology detail)
• Protocols, HTTP or HTTPS
• Class Diagrams, Interaction Diagrams (Sequence,
  State, Activity) implemented by an ejb,
• Design or architectural decisions
• ABC2
• Patterns you will be using

34
Diagram
View
Controller
Model
35
(No Transcript)
36
OO systems have to be organized by applying
composition constraints
mediator
Composition implementation is an arch decisions
Regular OO
Apply Composition Constraints
Facade
subsystems
Enterprise Component
37
OO containers are application servers

• EJBs
• Servlets
• In a small implementation you do not need an
  application server in that case the container is
  the JVM

38
Explicit Invocation of Components through
Interfaces
39
Event-based or Implicit Invocation
Observer
User
Event Mgr

Receive requests (bal, deb, cre, xfer) Decides
whether this is a known request Handles
exceptions Generates an Event
Subjects
Register Interest in an event Decide whether they
should respond to an event
40
Event-based or Implicit Invocation

• Components
• Event
• Observer
• Register
• Listen
• Handle
• Subject
• Generate
• Patterns
• Mediator, Observer, Factory
• Issues
• Complex event processing
• What do I do when 500 events are generated
  minute?
• Ensure that business significant events are
  surfaced

Event Handler
Register me, EventType
Event Rules
Event Manager
Event
Publish Event
Event Rules
Event Generator
Initiate Event
41
Event-Driven or Event-based

• Container
• Product e.g., MQ Series
• Q-manager
• Environment (programming)
• Com.util.???Event

42
Repository/Blackboard

• Components
• KS, Rep
• Connectors
• KS interacts with Rep via
• Direct data access
• Procedure call
• Constraint
• Control Structure
• Which KS should be invoked when it changes
  state?
• Patterns
• Mediator
• Observer, invocation (table lookup)
• ltevent-based style control interaction between
  KS and Repgt

ltltEvent-basedgtgt
Rep
control
rule
??
control
rule
sensor
43
Interpreter Architectural Style
Input
Output
Scanner
Memory
Interpreter
token
Parser
Code Generator Action handler
State machine
Condition
Rules (grammar)
Action
44
Interpreter
Handler
User
debit
debitAcct
Interpreter
Grammar
45
Variation of Interpreter
Debit(account,amount)
Interpreter
debit 10 from account 123
46
Example
Debit(account,amount)
Interpreter
debit
how much? 10
what acct? 123
insufficient funds!!!
47
HandleSales
SellToCustomer
successful
HandleException
failure

• SellToCustomer
• successful, HandleSales
• failure, HandleException
• HandleSales bringUpSalesApplication
• HandleException displayMsg(product out of
  stock)

48
GOOD Architecture
?
49
Assignment Google Search on SA

• Do an image search on google for software
  architecture
• What do you find?
• What do you see is missing?

50
Pattern (Format)

• Context
• Problem
• Forces
• Solution
• Static UML
• Dynamic seq
• Implementation Considerations (constraints, arch
  decisions)
• Consequences

51
Physical Architecture

• A network diagram with
• Types of Nodes showing important characteristics
  of
• Hardware
• RAM, disk, special processors, cards
• Software
• Packages
• Platforms
• OS, DB, App Servers, etc.

52
Physical
A
B
From Step into the J2EE architecture and process
By Jian Zhong
Intel Core Duo , 4 Gig , 1 tera Windows XP,
Apache Web Server v.
A
53
Sample Physical Arch 1
54
Levels of architecture within a company
Broad spectrum of options for e.g., J2EE, .NET,
Packaged (SAP) Focused on Enterprise level
considerations Every project that does not comply
must Apply for an exception Standards for
companywide projects Governance (compliance with
stds)
Enterprise/logical
Architectural Decisions
Application /Solution/logical
Technical /Physical
55
Containers

• A runtime entity that allows the execution of
  components for your arch style
• Physical and Logical aspects to a container
• Logical
• Mediator or Broker
• Web Server, Servlet Container, EJB Container, Web
  Services Container, CLR, JVM
• Physical
• Database
• Listens on ports
• Rules ? Pass execution to a handler component
• Specific , well define extension to the container
• Types of common handler components are
• ASP Pages
• ASP.NET
• Servlets
• JSPs
• EJB
• MDB
• Web Service

Custom Handler
Default
Listens Apply Policy Routes Transformation
Port
56
Containers
Custom Handler A
Custom Handler B
Custom Handler C
Monitor
Threshold (how many)
policies
Dispatcher/Router Load Balancer
Port
Load (how many resources required)
Listens Apply Policy Routes Transformation
Default
57
Non-functional Requirements Resolution

• Vertical and Horizontal scaling
• Caching
• Load Testing try to break the application
  (non-func) to know the limitations (boundaries)
  of the architecture
• Traffic, load, etc., thresholds,
• Anticipated thresholds
• Number and types of requests in various times of
  day
• Optimization
• Monitor
• Statistics (obtain)

58
Web 1.0 vs Web 2.0 REST

• 1. Representational State Transfer is intended to
  evoke an image of how a well-designed Web
  application behaves a network of web pages (a
  virtual state-machine), where the user progresses
  through an application by selecting links (state
  transitions), resulting in the next page
  (representing the next state of the application)
  being transferred to the user and rendered for
  their use.  Dr. Roy Fielding, Architectural
  Styles and the Design of Network-based Software
  Architectures
• 2. simple interface that transmits
  domain-specific data over HTTP without an
  additional messaging layer such as SOAP or
  session tracking via HTTP cookies.

59
Web 1.0 vs Web 2.0 AJAX

• Thin client
• Rich Client see Google maps!
• Fat Client
• A layer that mediates between the traditional
  client in the consumer layer and the backend
  server, enabling faster refresh and more
  interactive experience

60
Dynamically Re-configurable Architectures

• Change the application running on the
  architecture at runtime or close to runtime
• Change of configuration allows different behavior
  
• Interpreter
• GOOD (Grammar-oriented Object Design)
• I takes a business grammar for a domain (DSL) and
  runs it and that is your application
• SOA provides loose-coupling that enables dynamic
  reconfiguration in the back end
• Dynamically change content
• AJAX, REST, Wikis (some extent), static columns
  -gt blogs
• Dynamically change behavior
• Composition ? Mashup (a composition at the
  consumer layer)
• Developer Works (pattern language for
  service-oriented architecture and integration,
  part 1, 2)
• SOA Orchestration, choreography
• BPEL XML Schema standard for defining loosely
  coupled workflow
• Context-aware Architecture

61
Context-aware Architectural Style
Agreements/Contracts/SLA
RuleSets
Policies (may be DSL)
Account
Policies
ltltdecisiongtgt Gold, secure, Cust,6moCD,
calcInterest
Context
Context
ltltexec enginegtgt Event Condition Action/exception
Agreements/Contracts
Account Type Cust Type (gold, normal) Security
Token Agreements/Contracts Transactional
Context-aware Component Offers context-aware
services
DSL domain-specific language
62
Three tiered architecture
Implicit invocation Pub/sub asynchronous
Pipes and filters Layered Implicit Invocation
Persistence Or Backend Layer Or Tier
Pres
Busines Logic (App layer) Tier
synchronous
Listener
Listener
synchronous
View
Model
Controller
63
Domain Model to Arch Style Mapping
2(2xy)
Externalize Variations if something is changing,
separate it out
4x2y
Mapping the Domain Model To an Architectural
Style (or composite style)
Refine and Refactor
VOAD
KS
ltltarchitectural Stylegtgt
Software Architect
Patterns Architectural style Principles of SA
Software engineering skills Domain knowledge
(domain modeling)
64
Where are the Rules?
Rule?
Rule?
Rule?
65
GOOD

• VOD Process

66
Grammar-oriented Architecture Dynamically
re-configurable Architectural Style

• Components
• Large grained Enterprise Components with business
  supporting services
• Connectors
• Implicit invocation
• Constraints
• Externalized manners

67
VOD
encapsulate
separate
identify
AccountRule
Pass context, (Bal, duration)
Account
Account
Minimum Balance Rule
Bal, etc.
Minimum Balance Rule
Minimum Balance Rule
explicit context
If ((bal lt 0 ) (duration gt 30)))
printWarningStatement()
getBlance(), etc
Implicit context
getBlance(), etc
getBlance(), etc
If the rule method tends to change a lot,
then Externalize it.
68
Order
Shopping cart
Account
Customer
Product
sclineitem
Product LineItem
69
Methods and Behavior

• Method
• Performs an action
• Behavior
• Check state
• Apply rules
• Then either handle exceptions
• Or perform the action

70
Manners in Systems

• System consist of many components
• Connectors between components
• Usually these connectors are implicitly
  implemented (hardcoded)

71
GOOD
Java
P
Business Logic
M
Grammar
Manners
Framework Context-awareness
Controller
View
Model
72
Manners in their entirety
Framework Context-awareness
Customer Status Rules
Policies
4
event
1
5
Loan Rules
method
Exception
Perform Action
3
State
Events Context-state Rules Policies (meta-data)
Context
2
73
GOOD
Change the behavior of the system By changing its
configuration, changing its play Manners. You
do this through a business grammar
74
GOOD
Java
P
Business Logic
M
Grammar
GOOD Engine
Controller
View
Model
75
GOOD
Controller
Grammar
P
M
GOOD Engine
Generate/call
Business Logic
Java
C
View
Model
Web Services
etc
76
GOOD
Could be generated using grammar
P View
Model
match
Scanner
Parser
Action Table
3
2
4
5
1
Business Logic
Java Method Call
6
lttext filegt Grammar File
Exceptions
77
GOOD
Grammar

• Banking Open Account, Process Transactions,
  Close Account
• Open Account openAccount
• Process Transactions Process Txn, Process
  Transactions epsilon
• Process Txn Debit Credit CalcInterest
  Transfer getBalance
• Debit debitAccount(accountNum, amount)
• Transfer Debit, CheckandCredit
• CheckandCredit
• overdrawn, msg(overdrawn)
• notOverdrawn, creditAccount(AccountNum, amount)

78
Guidance for incremental development
Implementation via a thin-slice end-to-end
modelTake a use-case that exercises your system
end to end (e.g., 80)

• Generate Code from UML
• Fill in the skeleton generated
• So it compiles
• 4 person team
• GUI, divide controllers and models, one person
  for the db and dbfacade
• Then combine
• Use a test class to run a simple use-case
• Use the transfer use-case or debit use-case
• If no account then create else Open account
• Transfer
• Debit
• Check
• Credit
• notify

79
Completion Compile

• What percentage have each group completed?
• Percentage complete?
• Learn to provid e
• Focus on one use-case at a time Debit

80
Estimation for Development

• Breakdown
• Arch Style Domain Model ? Class Spec
• GUI 1.5
• Functionality (Business Logic) (Subsystems)
• Number of classes (obtain metrics from groups).
  E.g.
• G1 40, G2 10, G3 30, G4 15, G5 15, G6
  25,
• G1 3, G2 1 , G3 1 hr, G4 2.5, G5 1 hr,
  G6 1 hr.
• G1 120, G2 10, G3 30, G4 40, G5 15, G6
  25hrs.
• Between 10 120 hrs.
• 2 6 hrs . 7 day s x 6 42 hrs.
• Integration time is typically 50 of total.
• Model / DB (Subsystems) .5 4 hrs.
• Communication of expectation

81
Map Application Architecture to a Solution
Architecture

• Conceptual, application level architectural style
• Assigning technology and protocols to each
  element in the style
• Components, connectors, constraints
• Assign Products to fulfill those technologies

82
Domain Model to Arch Style Mapping
2(2xy)
Externalize Variations if something is changing,
separate it out
Functional reqs
4x2y
Mapping the Domain Model To an Architectural
Style (or composite style)
Refine and Refactor
VOAD
KS
ltltarchitectural Style application/ conceptualgtgt
Software Architect
Non-functional/operational reqs
ltltsolution architecturegtgt
83
Three tiered architecture
Pipes and filters Layered Implicit Invocation
Database Server
synchronous
HTML
Web Server J2EE App Server
synchronous
HTTP
JDBC
Listener
Listener
asynchronous
Statement Printing Process
JMS
3rd Party
API
https
Integration pts Verify cc
View
Model
Controller
84
Servlet arch
HTML
Webserver
App
Java implements HttpServlet(1,2)
/servlet/debit
success
debit
85
Operational Aspect Three tiered architecture
Pipes and filters Layered Implicit Invocation
Database Server
synchronous
HTML
Web Server J2EE App Server
synchronous
HTTP or JSP
JDBC
Listener
EJB
Listener
asynchronous
Legacy Systems
Statement Printing Process
JMS
JSP
Message Format?
View
Model
Controller
86
Operational Aspects
From Step into the J2EE architecture and process
By Jian Zhong
87
Product Assignment and Assessment
Presentation HTML browser
Application Linux, Apache Web server
Linux, IBM Websphere App Server
Servlets and java Server Pages or EJB?
Database Oracle 9i, JDBC
Listeners EJB
Statementing Component Reuse existing Statementer

88
After mapping to technology, drill down into each
tier or architectural component

• Application
• HTMLJSP
• Servlets
• EJBs
• They entail a selection of supporting tools and
  products
• Eclipse? ROSE? ERWIN?.

89
Chhandas Value Decisions

• An Architects role is primarily creation of
  application architecture
• Architectural Styles
• Write an architectural description
• Components, connectors, constraints are defined
  in design decision documents
• Patterns
• Mapping to a solution architecture (technologies
  and tools)
• More design decisions
• Asynchronous vs synchronous
• Technology Mappings

90
Model-View-Controller and RDC
V, Interface, JSP, GUI,
C Devata, Server, Servelts, Business
Logic Rules, Manager (WF)
M DB, Domain Model (business Logic), Chhandas, Me
ssage /protocol formats
C Devata, Server, Servelts, Business
Logic Rules, Manager (WF)
samhitta
91
Functional Aspect How are you going to build the
internals of components?
?
?
?
92
Assign the logical to the physical in a
deployment diagram
Functional Requirements
Operational Requirements but Driven by
technology
Deployment Diagram
41 View
93
The assignment of logical component to a physical
node is driven by non-functional requirements

• This is represented as a deployment diagram

94
(No Transcript)
95
Common application architecture decisions you
must make through application architecture
development include

• Functionality partition between tiers
• Model domain objects
• What legacy system to save
• What software components to buy
• What components to build
• How to integrate third-party components

From Step into the J2EE architecture and process
By Jian Zhong
96

• The order domain objects in Figure 3 demonstrate
  how you can model domain objects.
• With current Java technology, you could
  distribute domain objects among Web containers
• as developer-managed persistent objects,
• EJBs in the application server, or
• as RDBMS-hosted Java stored procedures.

97
Architectural deliverables architecture
specification and process requires at least the
following

• A system architecture document to describe your
  existing hardware, software, network topology,
  and other components
• An application architecture document to describe
  the application's major structure, including a
  logical view of all architecturally significant
  components, use case components, and legacy
  components
• A new components design guideline to describe all
  design guidelines and architectural decisions,
  explain all those decisions, and describe
  possible consequences if an alternative option is
  used. These guidelines should capture all
  important base determinants that the new
  component design must respect to maintain the
  system's architectural integrity
• A working architectural prototype to evaluate new
  technologies gain experience developing and
  deploying J2EE applications build architectural
  frameworks address risks by measuring
  performance, scalability, and ease as well as
  prove to project stakeholders that your approach
  works

98
Arsanjani Arch Document for SOA
99

• Architectural Mismatch
• Article
• Summary

100
SOA Reference Architecture
101
SOA Layers

• Scope ltwhat area of the enterprise is this
  architecture for?gt
• Operational systems layer
• Packaged applications
• Custom applications
• Architectural decisions
• Enterprise components layer
• Functional areas supported by this enterprise
  components
• ltWhat business domains, goals and processes are
  supported by this enterprise componentsgt
• Decisions regarding governance
• ltCriteria by which something is elected as an
  enterprise components within this client
  organizationgt
• Architectural decisions
• Services layer
• Categorized portfolio of services
• Architectural decisions

102
SOA Layers

• Business process and composition layer
• Business processes to be represented as
  choreographies
• Architectural decisions
• ltWhich processes need to be soft-wired into
  choreographies and which will be built into
  applications?gt
• Access or presentation layer
• ltDocument implications of Web services and SOA on
  this layer if any. For example, use of portlets
  that invoke Web services at the user interface
  level and the implications on the functioning of
  that layergt
• Integration layer
• ltInclude considerations of an ESBgt
• ltHow are we going to ensure the service-level
  agreements (SLAs) and quality of service (QoS)
  required by clients of the services provided?gt
• Security issues and decisions
• Performance issues and decisions
• Technology and standards limitations and
  decisions
• Monitoring and management of services
• Description and decisions

103
Web Services are an instantiation of SOA
Describes Publishes
UDDI Registry ------ Yellow Pages
WSDL
WSDL
Description
Service desc
Service desc
Find (locate) Reads the service description
104
Web services implement a service-oriented
architecture
Role of Service Broker
105
Non-functional Requirements
106
Non-functional Requirements are added to your
project

• Add classes to your project that will implement
  one single non-functional requirements
• E.g., security
• Authentication
• List of uid and passwds (encrypted)
• Authorization
• List of uid and valid use-cases
• Remember this has to be added in an extensible
  way that conforms to your general architectural
  style

107
Security

• Add authorization, authentication to your program
• Download a product and configure it for security
• E.g., Orion app server for HTTPS
• Read page of doc on how to enable HTTPS
• Or
• How to enable security on an application server
• E.g., orion has three ways of handling security
  implement them.

108
Elements of Security
Author Authen
HTTPS Data Security
Client
Firewall
Web server
Firewall
App server
Access Control List
Usernames, roles
roles, authoriy(what they can do)
109
Scalability, Availability, Reliability ?
Failover, redundancy, or load-balancing
JVM
app server2
JVM
Web server2
JVM
Load balancer
WorkLoad Mgt
JVM
Web server 1
app server2
JVM
JVM
client
110
Load balancing

• 2 options

111

• Finish your notes
• Decide and communicate on a non-functional
  requirement
• Implement non-func reqs in your program
• Implement non-func reqs in a product
• Send Prof A, a description of your non-func
  requirement design Remember to complete your
  functional arch desc
• (make sure you have all design decisions,
  diagrams etc.) by Friday pm (5 pm)
• Project code
• Complete coding of first iteration by sat mar 22
  pm (8pm)
• Functional, running version
• J2EE thurs, Enterprise Component fri, web
  services arch (weekend)

112
Enterprise Component

• Focus on the diagrams
• Block diagram
• Uml class diagrams

113
The Enterprise Component Pattern Can Be Used to
Structure Each Service Component
DE T A I L
See Arsanjani, A., Enterprise Component A
Compound Pattern for Building Technology-Neutral
Components, proceedings of OOPSLA 2000 Workshop
on Business Components, Minneapolis, MN, 2000.
114
a Web service instance can serve multiple roles
simultaneously. In the peer to peer scenario,
each peer Web service instance serves in both the
Service Requester and Service Provider roles
SourceWeb Services Architecture W3C Working
Draft 14 November 2002 This version
http//www.w3.org/TR/2002/WD-ws-arch-20021114/
115
Intermediary
116
Oneway
117
The service description layer is actually a stack
of description documents defined using XML
Schema.It is through the service description
that the service provider communicates all the
specifications for invoking the Web service to
the service requestor. The service description is
a key contributor to making the Web services
architecture loosely coupled and to reducing the
amount of required shared understanding, custom
programming and integration between the service
provider and the service requestor.
118
Structure of a Service
119
Conceptual Architecture
120
The Web services architecture consists ofA
single specification of the way in which
artifacts of the system are identified the
Uniform Resource Identifier (URI) 1 (see
section 4.1 Identifiers.).A non-exclusive set of
data formats designed for interchange between
agents in the system (see section 4.2
Formats.).A small and non-exclusive set of
protocols for interchanging information between
agents (see section 4.3 Protocols.).A small and
non-exclusive set of ... (see section 5
Processing Model).Issue (procmod)Is Process
Model a foundational architectural
aspect?ResolutionNone recorded.
121
Non-functional requirements part of project

• Non-functional reqs, what they are
• List of and describe
• Arch with regard to non-func reqs
• gain experience of Implementing and /or
  configuring a product for a non-func requirement
• Pick non-func requirement
• Think about how to design and implement it
• Have frequent emails with your Prof to detail
  your design and implementation

122
Architects learning process

• In order for an architect to be able to fulfill
  non-functional requirements, you typically need
  to search, assess and configure a product
• Search by type
• Assess based on your constraints
• Configure the product

123
Security

• Authentication
• Login screen
• Db or file with uid, passwd encrypted!
• Authorization
• When you invoke some service (debit, transfer,
  etc.) check whether the user is authorized
• List of userids, and authroizations
• HashTable HashMap
• Handle it exceptions gracefully
• Provide feedback to user (give message)

124
Security

• Enable HTTPS on an application server

125
Load balancing and Failover are closely connected
126
Clustering or Load Balancing

• Configure an application server or web server to
  support load balancing

Receives routed requests from balancer
A
Web server
Balancer Sprayer
Edge server
user
Web server
B
No of users gt 100 then go to B
127
Clustering or Load Balancing

• Policies of load balancing
• Round robin
• ltOther algorithmsgt
• Rule based
• Give priority to certain transaction types
• Redirect them to a new server so they do not have
  to wait until the previous server s processing
  is complete

128
Load Balancing
Implement a couple load balancing policies
UI
UI
Policy
Controller
Acct Mgt Component
Acct Mgt Component
Database Layer
129
Failover
Implement a couple load balancing policies
Web server, Application server (EJBs, workload
mgt)
Firewall redundancy
UI
UI
Monitor
Policy
Controller
Policy
Monitor
Controller
Acct Mgt Component
Acct Mgt Component
Database Layer
130
Virtual Hosting

• How do I add virtual hosts to my orion server?
• Please refer to this article for detailed
  information.

131
Implement three forms of security

• User tries to access a page (directory) and you
  challenge them with login
• There are three forms of this on orion

132
Extensibility

• Justify how you can make an architecture
  extensible and implement this in your program
• Why is it extensible?
• Add a use-case to it
• New diagram with the new elements on it

133
Performance

• Monitoring
• Load testing
• Do it yourself or download a tool
• Profiler
• JProfile
• Publish Metrics
• One per service

134
Performance

• How do we ensure a system has acceptable
  performance?
• Monitor
• Speed
• Define what speeds are acceptable
• Create a test
• Create 2 Accounts
• Credit account A by 100,000
• Transfer 50,000 to account B
• When I have 500 transactions by performance is 12
  sec for the whole 500
• I need to have the system perfroming at 5 sec for
  500 txns
• In the real project you would use profiling tools
  to see where your program is slowest

135
Performance

• How do we ensure a system has acceptable
  performance?
• Monitor
• Speed
• Publish metrics
• 500 debits takes 5 sec
• 500 transfers takes 6 secs
• Credit
• getbalance

136
Arch Document

• Non-functional Requirements
• Background
• Research on the web on your topic
• Use at least three sources (references)
• Reference whatever you copy
• Describe your choice of non-functional
  requirements
• Components Connectors Constraints
• Design decisions on how you implement your
  non-functional requirements (Table)
• Product Configuration
• Identify a product and non-func aspect you wish
  to configure
• Describe how you will configure the product (user
  manual etc.)
• Research on the web about that product, what are
  its competitors

137
Non functional Requirements

• Security
• Author, authen,
• HTTPS
• 3 forms of secure access
• Load balancing/ Clustering
• Failover
• Performance
• Extensibility

• Configuration
• Orion security
• 3 forms of security
• Virtual Hosting on Orion

138
Grading

• Final
• Class Notes
• Everything I say in class
• Powerpoints
• Readings
• Official list
• Articles I have told you where I will emphasize
  and that is the bullets points and pictures!
• Concepts and applications
• Concepts in arch and styles etc.

139
Grading

• Paper (On yahoo groups)
• Arch desc ? Word
• Func 60
• Non-func 30
• Product 10
• Describe each section with at least one sentence
• Powerpoint
• MDL
• Source zipped and documented
• Package Edu.mum.dsa.ltstudent first namegt.gui
• Package Edu.mum.dsa.ltstudent first namegt.app

140
What is Software Arch? Roadmap
141
Arch Styles

• Shaw Patterns
• J2EE
• (component-based arch style)
• Web services
• AJAX, Web 2.0
• REST
• GOOA
• Grid Arch (OGSA)
• Self-evolving
• Dynamic Arch in general

142
Components and Assembly

• EC
• Arch Mismatch
• Identifying And specifying components

143
Dynamic Software Architecture
144
Dynamic Software Architecture Types of
Architecture Dynamism

• Run Time Structural Changes
• Create/Destroy Type Instance Component,
  Connector
• Attach/Detach Port to Role
• Run Time Control Changes
• Create/Destroy Process/Thread
• Suspend/Resume Process/Thread
• Run Time Behavior (i.e. Events)
• Design Time Structural Changes
• Define Type Component, Connector
• Design Time Control Changes

145
Self-evolving Architectures
146
Previously on DSA
147
Groups

• Group 1
• MVC Implicit Invocation
• Group 2
• Repository
• Group 3
• Grammar-oriented Object Design
• Group 4
• Pipes and Filters
• Group 5
• Object-oriented

• Group 6
• MVC (3-tier) Interpreter

148
The Meta-Model for SOA Solution Architectures

• We see a set of recurring things we need to
  capture for architecture.

149
Introduction to Architectural Styles
150
(No Transcript)
151
(No Transcript)
152
(No Transcript)
153
(No Transcript)
154
(No Transcript)
155
(No Transcript)
156
(No Transcript)
157
(No Transcript)
158
(No Transcript)
159
(No Transcript)
160
(No Transcript)
161
(No Transcript)
162
(No Transcript)
163
(No Transcript)
164
(No Transcript)
165
(No Transcript)
166
(No Transcript)
167
(No Transcript)
168
(No Transcript)
169
(No Transcript)
170
(No Transcript)
171
(No Transcript)
172
(No Transcript)
173
(No Transcript)
174
(No Transcript)
175
(No Transcript)
176
(No Transcript)
177
(No Transcript)
178
(No Transcript)
179
(No Transcript)
180
(No Transcript)
181
(No Transcript)
182
(No Transcript)
183
(No Transcript)
184
(No Transcript)
185
(No Transcript)
186
(No Transcript)
187
(No Transcript)
188
(No Transcript)
189
(No Transcript)
190
(No Transcript)
191
(No Transcript)
192
(No Transcript)
193
(No Transcript)
194
(No Transcript)
195
(No Transcript)
196
Reading David ParnasOn the criteria to be used
in decomposing a system into modules
197
(No Transcript)
198
(No Transcript)
199
(No Transcript)
200
(No Transcript)
201
(No Transcript)
202
(No Transcript)
203
(No Transcript)
204
(No Transcript)
205
(No Transcript)
206
(No Transcript)
207
(No Transcript)
208
(No Transcript)
209
(No Transcript)
210
(No Transcript)
211
(No Transcript)
212
SOA Solution Stack Meta Model
213
SOA Solution Stack Meta Model - Details

• KPIs
• It is a set of key performance indictor
  constraints that involve in ABBs and put concerns
  on making architectural decisions
• NFRs
• It is a set of non-functional requirement
  constraints that involve in ABBs and put concerns
  on making architectural decisions.
• Enabling Technology
• It is a technical realization of ABBs in a
  specific layer by selecting which technology or
  product.
• Exposed Business Services
• Exposed business services (a.k.a. externalized
  business solution elements) refer to entities
  that expose business processes or composite
  business applications as business services that
  can be reused as service assets.
• External Service Connectors
• External service connectors refer to adaptors
  (e.g., transformers) for exploiting external
  services for business connections and business
  integrations.
• Data Models
• It models data contents associated with ABBs
  including data exchange between layers and
  external services.
• Functional Requirements
• It models the functional requirements that one
  layer or ABB must fulfill.

• Layers
• It is an abstraction of the nine layers of S3,
  which contains a set of components such as ABBs,
  architectural decisions, interactions among ABBs
  and interactions among layers.
• Options
• options focus on solution-level patterns or
  principles that an SOA solution architect should
  consider and make decisions upfront.
• Architectural Decisions
• It is one type of options specific for
  architectural designs of an SOA solution.
• Normative Guidance
• It is one type of options specific for
  scenario-specific normative guidance.
• Method Activities
• It is a collection of steps that involve ABBs to
  form a process to populate components in a layer.
• ABBs
• A set of Architectural Building Blocks (ABBs)
  reside in a layer that contains attributes,
  dependencies and constraints as well as
  relationships with other ABBs in the same layer
  or different layers.
• Interaction Patterns
• It is an abstraction of the various relationships
  among ABBs (patterns and diagrams) within and
  across layers.

214
Detail Solution SOA Solution Stack Layer Consists
of Steps that Should be Applied to Populate Each
Layer
215
Example from Layer 6 Integration Layer ABBs
Relationships
Certain relationships exist between the
identified ABBs There is a one-to-one
relationship between integration controller ABB
with all other ABBs data aggregator ABB, message
transformer (including data transformer ABB and
protocol transformer ABB), logger ABB, access
control ABB, auditor ABB, exception handler ABB,
event manager ABB, state manager ABB, and
configuration rule ABB.
216
(No Transcript)
217
(No Transcript)
218
(No Transcript)
219
(No Transcript)
220
(No Transcript)
221
(No Transcript)
222
(No Transcript)
223
(No Transcript)
224
(No Transcript)
225
(No Transcript)
226
(No Transcript)
227
(No Transcript)
228
(No Transcript)
229
(No Transcript)