Application architectures
Diomidis Spinellis
Department of Management Science and Technology
Athens University of Economics and Business
Athens, Greece
dds@aueb.gr
Architectural Dimensions
- Design properties
- System structure
- Control model
- Element packaging
- Architectural reuse
Basic Design Principles
When designing a system's architecture we try to follow the
principles outlined below.
Abstraction
Abstraction is achieved in the following areas:
- procedural abstraction
- data abstraction
- control abstraction
Refinement
Stepwise refinement is a way to tame the details and
complexity of the final design.
Modularity
A modular design minimises the system's complexity and thereby
the development cost and the number of possible errors.
A good design method should provide:
- modular decomposability
- modular composability
- individual modular understandability
- modular continuity
(in changes: minimize the modules affected by any change)
- modular protection:
a problem in one part should not create problems in others
Cohesion
A design should bring closely together parts that exhibit a
high measure of cohesion.
We can distinguish the following ordered types of cohesion:
- coincidental cohesion
- logical cohesion
- temporal cohesion
- procedural cohesion
- communicational cohesion
- sequential cohesion
- functional cohesion
Coupling
On the other hand, a design should avoid coupling between
parts.
We can distinguish the following ordered types of coupling:
- data coupling
- stamp coupling (copy of a part)
- control coupling
- common coupling
- external coupling
- content coupling
A: System Structures
Important and noteworthy system structuring
models include the following:
- Centralized repository
- Data-flow
- Object-oriented
- Layered
- Hierarchical
Centralized Repository
- Central process acts as control hub
- Central data repository acts as information hub
- Termed client-server when based on standalone processes
- Integrability allows different clients and servers to interoperate
- Depending on persistency requirements:
- A blackboard can store temporary data acting as a communications hub
- A relational database can provide a persistent data store
- In a two-tier architecture the client accesses the database
- In a three-tier architecture a separate server offers task-oriented services
- A transaction monitor can be used to offer
- Resiliency
- Redundancy
- Load distribution
- Message sequencing
- Middleware allows different parts to communicate with each other
- CORBA (OMG)
- .NET (Microsoft)
- RMI (Java/Sun)
Examples
- Window manager
- File server
- Print server
- Collaboration
- WWW
- Modern ERP systems
- Instant messaging
- Revision control (CVS)
Data-Flow
- Also known as pipes-and-filters architecture
- Consists of a series of data transformations
- Examples:
- Unix text processing tools (wc, grep, sort, uniq, join)
- Netpbm graphics processing package
Create Manual Page Index
Object-Oriented
- Design is based on interacting objects
- Each object maintains its own state
- State is manipulated by methods
- Objects are typically grouped into classes
- Classes are often organised into generalisation relationships
A generalization relationship in the Tomcat servlet container
Layered
- Can organise multiple peer subsystems
- Each layer:
- Presents a standard interface to its upper layer
- Communicates using a different standard interface with its lower layer
- Essentially each layer implements a virtual machine
- Lower layers shall not use upper layers
- Examples:
- Network stacks
- Operating system structures
The Windows NT implementation layers
Hierarchies
Hierarchies
- provide structure
- facilitate navigation
- can be used orthogonally with other architectures
- examples
- directories
- DNS
- call graphs
- identifier namespaces
The NetBSD kernel source hierarchy
Control Models
- Call and return
- Structure prescribes control
- Flow of data
- Method invocation
- Event-Driven Systems
- System Manager
- State Transition
Event-Driven Systems
- Control decisions depend on external events
- Events can be broadcast to all listeners (e.g. power down)
- Events can be polled from a source (e.g. GetMessage)
- Handlers can be registered to respond
- Examples
- Hardware interrupts
- GUI systems
- Relational database triggers
- System and network management
System Manager
- Useful for orchestrating multiple (pseudo) concurrent processes
- One process acts as central manager
- Typical operations:
State Transition
- Changes in data (the state) direct the flow of control
- Often modelled as a state machine
- Set of states
- Initial state
- Final state
- Actions (processing and state transitions)
TCP state transition diagram
B: Element Packaging Approaches
Elements can be packaged using the following approaches:
- Module
- Namespace
- Object
- Generic implementation
- Abstract data type
- Library
- Component
- Process
- Data repository
Module
- Separately named and addressable component
- Provides services to other modules
- Typically interacts through procedure calls and data sharing
- Physical boundary is often a file
- Provides information hiding (only exposes what is needed)
Namespace
- Counters namespace pollution
- Unique prefix associated with a part of the implementation
- Supported by languages such as C++, C#, Java, Modula and Perl
Object
- Encapsulates data and code
- Fields contain data
- Methods contain code for acting on the data
- Every object has its own copy of the data
- Same objects are typically grouped into a class
- Classes can also contain data and code shared among all objects
- Classes can be organised in an inheritance hierarchy
- Each derived class inherits the fields and methods of its base class
- Polymorphism allows objects of any derived class to be used as objects of the base class
Generic Implementation
- Works with arbitrary data types
- Based on concepts a particular element must satisfy (e.g. comparable)
- Typically available as standardised library supporting e.g.
- Containers
- Iterators for traversing the containers
- Algorithms on containers
- Numeric algorithms
Abstract Data Type
- Encapsulates data
- Separates interface from implementation
- Implementation can change; interface remains
- Interface often specified in a formal manner
Examples
- Programming in the small:
- Programming in the large:
- Relational database accessible via stored procedures
- Data accessible via the web service model
Library
- Organized collection of modules
- Sharing a common purpose
- Typically distributed in binary form
- Uses:
- Facilitates code reuse
- Optimises the build process
- Load application features on demand (plugin)
Component
- Self contained unit of program composition
- Documented and well defined interfaces
- Deployed without access to the original developers
- Often distributed and used by third parties
- In common with objects
- Encapsulate state
- Provide access mechanisms through interfaces
- Support modular design
- In addition
- Can be implemented in different languages (although .NET allows this for objects as well)
- Robustly packaged in binary containers
- Can encapsulate multiple objects (e.g. DataGrid)
- Examples
Process
- Expensive startup and communication overhead
- Robust isolation (OS enforced)
- Faults (e.g. buffer overflow problems)
- Resources (e.g. open files)
- Privileges
- Simplifies build process and deployment
Data Repository
- Structure of the data reflects the structure of the system
- Examples
- Relational database
- Directory structure
- Windows registry
- XML data
C: Architectural Reuse
Reusing architectural designs is often more important than reusing code.
Some commonly-used approaches are:
- Frameworks
- Code wizards
- Design patterns
- Domain-specific and reference architectures
Framework
- Collection of classes serving a common goal
- Allow the expression of sophisticated architectures
- Designed to provide a reuse base for implementing complete systems
- Examples
- Adaptive Communication Environment
- Microsoft Foundation Classes
- Abstract Windowing Toolkit
Code Wizard
- Automatically generates (often cryptic) code
- User-guided
- Code is supposed to be subsequently modified
- Problematic if initially stated requirements change
Design Patterns
"Each pattern describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to that
problem, in such a way that you can use this solution a million times over,
without ever doing it the same way twice."
- Christopher Alexander
- Describe concepts, not code
- Finer-grained than frameworks
- Typical description
- a pattern name such as Singleton or Reactor used to identify the pattern,
- an illustration of its structure using a UML diagram,
- a classification of the pattern as e.g. creational, behavioural, or structural,
- an illustration of the design problem that provides the motivation to use the pattern,
- an outline of the situations where the pattern can be applied,
- an outline of the pattern's participants,
- a description of how the pattern supports its objectives, and
- examples and prescriptive guidelines towards the pattern's implementation.
Domain-Specific and Reference Architectures
- Some application classes are typically associated with a specific architecture
- Other architectures are abstract and refer to a given field
- Examples
- Compilers
- Operating systems
- OSI reference architecture
- Web services architecture
D: Web Services Architecture
Web Service
- Instance of Service Oriented Architecture
- Software system designed to support interoperable networked machine-to-machine interaction
- Interface described in a machine-processable format (WSDL)
- Interaction through SOAP messages
- Conveyed using HTTP with an XML serialization
Web Services Architecture
- Standard means of interoperating between different software applications
- Applications can run on a variety of platforms and/or frameworks
- Interoperability through the definition of compatible protocols
Roles of Humans and Machines
Web Service Technologies
WSA Models
- Message Oriented Model (e.g. message structure)
- Service Oriented Model (e.g. services and related actions)
- Resource Oriented Model (identification of resources)
- Policy Model (constraints like security and QoS)
- Management Model (relationship of deployed elements)
Message Oriented Model
Important Definitions
- Correlation is the association of a message with a context. Message correlation ensures that the agent requesting a service execution can match the reply with the request, especially when multiple replies may be possible.
- A message is the basic unit of data sent from one software agent to another in the context of Web services.
- A message envelope is that meta-data associated with a message that permits the message to be delivered, intact.
- A Message Exchanage Pattern (MEP) is a template, devoid of application semantics, that describes a generic pattern for the exchange of messages between agents.
Service Oriented Model
Important Definitions
-
An action, for the purposes of this architecture, is any action that may be performed by an agent as a result of receiving a message, or results in sending a message or other observable state change.
-
A choreography defines the sequence and conditions under which multiple cooperating independent Web services exchange information in order to achieve some useful function.
-
A service is a set of actions that form a coherent whole from the point of view of service providers and service requesters.
-
The semantics of a service is the contract between the service provider and the service requester that expresses the effect of invoking the service. A service semantics may be formally described in a machine readable form, identified but not formally defined or informally defined via an `out of band' agreement between the provider and the requester.
-
A service task is a unit of activity associated with a service. It is denoted by a pair: a goal and an action; the goal denotes the intended effect of the task and the action denotes the process by which the goal is achieved.
Resource Oriented Model
Important Definitions
-
Discovery is the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria.
A discovery service is a service that performs the above discovery; of particular interest are discovery services that permit the discovery of Web services.
Policy Model
Important Definitions
-
An audit guard is a mechanism deployed on behalf of an owner that monitors actions and agents to verify the satisfaction of obligations.
-
A permission guard is a mechanism deployed on behalf of an owner that enforces permission policies.
-
A policy is a constraint on the behaviour of agents.
-
A policy guard is a mechanism deployed on behalf of an owner that enforces a policy (or set of policies).
Management Model
Important Definitions
-
A deployed resource is a resource that exists in the physical world. There are many kinds of deployed elements, including agents, services and descriptions.
-
A management configuration is a collection of properties of a manageable elements which may be changed.
-
Events are changes in the state of a manageable element that are relevant to the element's manager.
Bibliography
- L. Barroca, J. Hall, and
P. Hall, editors.
Software Architectures: Advances and Applications.
Springer Verlag, 1999.
- Grady Booch, James
Rumbaugh, and Ivar Jacobson.
The
Unified Modeling Language User Guide.
Addison-Wesley, Reading, MA, 1999.
- David Booth, Hugo Haas,
Francis McCabe, Eric Newcomer, Michael Champion, Chris Ferris, and David
Orchard.
Web services architecture (http://www.w3.org/TR/ws-arch/).
Available online http://www.w3.org/TR/ws-arch/, Aug 2003.
W3C Working Draft.
- L. L.
Constantine and E. Yourdon.
Structured Design.
Prentice Hall, 1979.
- James O. Coplien and
Douglas C. Schmidt.
Pattern Languages of Program Design.
Addison-Wesley, Reading, MA, 1995.
- Alan M. Davis.
201
Principles of Software Development, pages 73–99.
McGraw-Hill, 1995.
- Peter
Duchessi and InduShobha Chengalur-Smith.
Client/server benefits, problems, best practices.
Communications of the ACM, 41(5):87–94, May 1998.
- M. Fayad, R. Johnson,
and D. C. Schmidt, editors.
Domain-Specific Application Frameworks: Applications and
Experiences.
John Wiley and Sons, New York, 1999.
- M. Fayad, R. Johnson,
and D. C. Schmidt, editors.
Domain-Specific Application Frameworks: Problems and Perspectives.
John Wiley and Sons, New York, 1999.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Software Design Descriptions, 1998.
IEEE Standard 1016-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Architectural Description of Software
Incentive Systems, 2000.
IEEE Standard 1471-2000.
- Brian W. Kernighan
and Rob Pike.
The
UNIX Programming Environment.
Prentice-Hall, Englewood Cliffs, NJ, 1984.
- Scott M. Lewandowski.
Frameworks for component-based client/server computing.
ACM Computing Surveys, 30(1):3–27, March 1998.
- David G.
Messerschmitt and Clemens Szyperski.
Software Ecosystem—Understanding An Indispensable Technology and
Industry.
MIT Press, Cambridge, 2003.
- Object
Management Group, Inc.
The common object request broker: Architecture and specification, July 1996.
Revision 2.0 (Updated).
- Roger S. Pressman.
Software Engineering: A Practitioner's Approach, pages 330–393.
McGraw-Hill, fifth edition, 2000.
European Adaptation. Adapted by Darrel Ince.
- Konstantinos Raptis,
Diomidis Spinellis, and Sokratis Katsikas.
Multi-technology distributed objects and their integration ( http://www.spinellis.gr/pubs/jrnl/2001-CSI-Components/html/imtd.html).
Computer Standards & Interfaces, 23:157–168, July 2001.
- J. H. Saltzer, D. P.
Reed, and D. D. Clark.
End-to-end arguments in system design.
ACM Transactions on Computer Systems, 2(4):277–288, November
1984.
- Mary Shaw and David
Garlan.
Formulations and Formalisms in Software Architecture.
Springer Verlag, 1995.
Lecture Notes in Computer Science 1000.
- J. Siegel.
A preview of CORBA 3.
Computer, 32(5):114–116, May 1999.
- Ian Sommerville.
Software Engineering, pages 215–259.
Addison-Wesley, sixth edition, 2001.
- Diomidis Spinellis.
The computer's new clothes ( http://www.spinellis.gr/pubs/jrnl/1998-IEEESoft-CliServ/html/CliServ.html).
IEEE Software, 15(6):14–17, November/December 1998.
- Diomidis Spinellis.
Code Reading: The Open
Source Perspective, chapter 9, pages 267–338.
Effective Software Development Series. Addison-Wesley, Boston, MA, 2003.
- Sun
Microsystems Inc.
Java remote
method invocation specification.
Available online http://java.sun.com/docs/guide/rmi/spec/rmiTOC.html/ (February
2002), December 1999.
Revision 1.7, Java 2 SDK, Standard Edition, v1.3.0.
- Clemens Szyperski.
Component Software: Behind Object-Oriented Programming.
Addison-Wesley, Reading, MA, second edition, 2002.
- Damien Watkins, Mark
Hammond, and Brad Abrams.
Programming in the .NET Environment.
Addison-Wesley, Reading, MA, 2002.