ASGARD: Architecture of
Skoll Got A ReDesign
Presented by Jack Kustanowitz
University of Maryland
April 28, 2005
6/27/2016
University of Maryland
1
Norse Code
Asgard- The home of the
Æsir, one of the nine worlds of
Norse mythology. Asgard was
the topmost level of the nine
worlds. The Æsir gods and
goddesses had their mansions
and palaces here. Asgard was
connected to Midgard by the
rainbow bridge, Bifrost.
Asgard is surrounded by a
strong wall built by a giant.
(See Asgard's Wall and the
Giant Builder for the story.)
6/27/2016
University of Maryland
2
Overview








About Skoll
Disclaimer: Development Phases
Software Architecture Research
Distributed Architectures
Current Skoll Architecture/Operation
Areas of Concern
Recommendations
Future Work
6/27/2016
University of Maryland
3
About Skoll
 System for DCQA (Distributed, Continuous
Quality Assurance)
 Distributed system, with standard
components (database, client, server, RPC,
data synchronization, data visualization,
etc.)
 Implemented with ACE+TAO as a proof-ofconcept
 Several studies proved its utility
 Growth -> Refactoring & Rearchitecting
6/27/2016
University of Maryland
4
Disclaimer: Development Phases
 Risk-driven approach of
spiral development*
 Refactoring, small
releases from Extreme
Programming

“System put into
production in a few
months, before solving
the whole problem”
 Recommendations listed
here are in light of
successes of first few
iterations

Authors deserve lots of
credit for getting things
where they are today
*From B. Boehm, A Spiral Model of Software Development and Enhancement
6/27/2016
University of Maryland
5
Why Talk About Software
Architecture1,2
 Lets developers make statements about the system:
the creation of vocabularies & notations
 Allows better code reuse
 Potentially creates space for formal analysis
 Creates demand for tools that support rapid, reliable
development
 Provides techniques and guidelines for refactoring &
improving existing code
 Provides basis for project management & assessment
 Address “architectural erosion” and “architectural
drift”, increasing brittleness of system
1D.Garlan
2D.
6/27/2016
& M. Shaw, An Introduction to Software Architecture
Perry & A. Wolf. Foundations for the Study of Software Architecture
University of Maryland
6
Architectural Transformations
 Transformations for Explanatory Purposes
 Temporary, for analysis
 Transformations for Change
 Permanent – these are the ones we’re interested in
here
 Notion of “transform”: Same fundamental “thing”, but
mapped onto a different scheme
 3-levels (highest, middle, lower)
 Many of these help only if there is a formal model, so
less interesting in our case
From V. Ambriola & A. Kmiecik, Architectural Transformations
6/27/2016
University of Maryland
7
Architectural Assessment
 Two case studies, with Symbian OS and mobile
network resources (Nokia)
 Scenario-based evaluation
 Important to put architecture over personal issues,
ownership of code
 Need management sponsorship & follow-up
 Side benefits
 Easier communication
 Better documentation
 Easier to schedule new work
 Quicker to find architectural flaws in future
development
From A. Maccari, Experiences in assessing product family
software architecture for evolution
6/27/2016
University of Maryland
8
Maturation of Software Architecture
Research
 Feasibility
 Going from specification to implementation
 Characterization
 Creating terms that explain the domain
 Method/Means
 Describing ways to develop/evolve systems
 Generalization
 Abstraction of principles to general guidelines, such
as patterns
 Selection
 Providing criteria for deciding between alternatives
From M. Shaw, The Coming-of-Age of Software Architecture
Research
6/27/2016
University of Maryland
9
Architectures: P2P or Grid?
 P2P (typical)
 Grid (typical)
 Diverse platforms
 Geographically spread
out
 High probability of
node failure
 Join/Leave protocols
important
 Decentralized (selforganizing)
6/27/2016
 Similar/identical
platforms
 Frequently in a
cluster
 Tight administrative
control
 Fixed number of
nodes
 Centralized command
with distributed
functionality
University of Maryland
10
Architectures: 3-Tier
 Motivation
 Developers tired of writing authentication,
security, etc. into every web application
 Innovation: Creation and separation of
middle-tier Application Server
 Connection pooling
 User management
 Security
 Allows database isolation
 Communication using open-source, well
established, platform independent protocols
6/27/2016
University of Maryland
11
Architectures: Web Services






Interface-based communication
Stateless protocol
Both sides platform independent
Frequently: XML over HTTP
Often used for standardized RPC
Industry support
 Many developers know how to use it
 Variety of high-quality tools
 Fast improvements in Open Source community
6/27/2016
University of Maryland
12
Skoll Architecture: Sample
Interaction
1.
2.
3.
4.
5.
6.
Client registers with server, providing client-specific
information (once)
Client contacts server over custom port and requests
a workflow
Server sends perl script with workflow to client
Client runs script, parses freetext, and generates
XML report
Client sends logs and generated report to server
using CGI
Server records results and updates “scoreboard”
Summary: Standard client-server model, effective to
prove concept but with limitations
6/27/2016
University of Maryland
13
Areas of Concern








ACE+TAO dependencies & assumptions
Perl
Stateful client-server interaction
Workflow definition language
Result reporting and interpretation
Static client
Installation
Security
General: Tight coupling between client & server with minimal
planning for project growth
6/27/2016
University of Maryland
14
Recommendations
 Database isolation (3-tier model)
 Architectural support for starter kit
 Web services platform for client-server
interaction
 XML for task definition (replace Perl)
 Light, versioned, updateable client
 Stateless interactions
 Raw result reporting (structured when
possible)
 Authentication protocol
6/27/2016
University of Maryland
15
Priorities
1. Close security holes (hide access to
database)
2. Revamp client-server communication
protocol (toward XML job description
and reporting)
3. Hide all internals and publish
interface
4. Create starter kit
5. Everything else
6/27/2016
University of Maryland
16
Future Work
 Re-evaluate architecture after
implementation of Skoll on ~5 nonACE+TAO projects
 Compare new architecture to old, for
specific scenarios
 Does the existence of a DCQA
program have implications for the
architecture of the system being
tested?
6/27/2016
University of Maryland
17