Application architectures

Architectural Dimensions

• Design properties
• System structure
• Control model
• Element packaging
• Architectural reuse

Basic Design Principles

Abstraction

• procedural abstraction
• data abstraction
• control abstraction

Refinement

Modularity

• 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

1. coincidental cohesion
2. logical cohesion
3. temporal cohesion
4. procedural cohesion
5. communicational cohesion
6. sequential cohesion
7. functional cohesion

Coupling

1. data coupling
2. stamp coupling (copy of a part)
3. control coupling
4. common coupling
5. external coupling
6. content coupling

A: System Structures

• 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

• 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:
  • Start
  • Stop
  • Schedule

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

• 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:
  • Stack
  • Map
  • Queue
• 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
• ActiveX
• JavaBeans

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

• 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."

• 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.dmst.aueb.gr/dds/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.dmst.aueb.gr/dds/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.

• Contents

 Last change: Tuesday, January 17, 2006 4:57 pm
 Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License. Portions of the above text appear in Web Services Architecture (working draft). Copyright © 2003 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231