Dynamic Software Architecture - PowerPoint PPT Presentation

Loading...

PPT – Dynamic Software Architecture PowerPoint presentation | free to download - id: 6e173b-YmJjN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Dynamic Software Architecture

Description:

Title: Software Architecture Author: csfaculty Last modified by: Ali Arsanjani Created Date: 3/17/2003 9:57:34 PM Document presentation format: On-screen Show – PowerPoint PPT presentation

Number of Views:85
Avg rating:3.0/5.0
Slides: 230
Provided by: csf72
Learn more at: http://softwarearch.pbworks.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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)
About PowerShow.com