Architectur 2 Architecture Styles

Catalin George RaicuZIT 9.5 Microsoft Competence CenterFrankfurt / February, 2009

Architecture StylesZIT 9.5 Microsoft Competence Center

C. G. Raicu, ZIT 9.5, February, 2009

2

Agenda

• Introduction to software architecture – review

• Architectural process

• Refined Experience

• Architectural Style

• Q & A


3

Introduction to software architecture – review(1)

• What is architecture?

- a set of principles and design decisions describing the structure and behavior of a software system

• Managing complexity through architecture

- Conceptual: decomposition, abstraction and simplification.

- Operational: communication enhancement, decreased number of task dependencies and increased manageability of dependencies.

• The technical dimension of architecture

- The application model

- The system design

- The test plan

- The deployment / provisioning concept

- The operational concept


4

Introduction to software architecture – review(2)

• From architecture to code:

- Conceptual System Design

- Detailed System Design

- Development (Coding)

- Unit & Integration Testing

- System Testing

- System Delivery

• Documenting the architecture: the “4+1” model

- the logical view,

- the process view,

- the physical view,

- the development view,

- the scenario (use case) view.

• Use case driven modeling and development

- WHAT system are we building, HOW is the system going to be structured, WHO will the system interact with


5

Agenda





• Q & A


6

Architectural ProcessWhere do Architectures Come From?

• All software architectures rely on two pillars:

- Creativity:

- Fun, BUT strained with risk

- May be unnecessary, BUT may render the best result

- Method

- Efficient in familiar terrain, BUT not always successful

- Predictable outcome (pros & cons), BUT quality of methods varies


7

Architectural Process Objectives

• Creativity

- Enhance your skill-set

- Provide new tools

• Method

- Focus on highly effective and proven techniques

• Develop judgment:

- when to develop novel solutions

- when to follow established method


8

Architectural ProcessDesign Stages

• Feasibility stage:

- identifying a set of feasible concepts for the design as a whole

• Preliminary design stage:

- selection and development of the best concept.

• Detailed design stage:

- development of engineering descriptions of the concept.

• Refinement stage:

- evaluating and altering the concept to suit the requirements of production, distribution, consumption and product retirement.


9

Architectural ProcessPotential Problems

• If the designer is unable to produce a set of feasible concepts, progress stops.

• As problems and products increase in size and complexity, the probability that any one individual can successfully perform the first steps decreases.

• The standard approach does not directly address the situation where system design is at stake, i.e. when relationship between a set of products is at issue.

• As complexity increases or the experience of the designer is not sufficient, alternative approaches to the design process must be adopted.


10

Architectural Process Alternative Design Strategies

• Standard

• Linear model (as above)

• Cyclic

• Process can revert to an earlier stage

• Parallel

• Independent alternatives are explored in parallel

• Adaptive (“lay tracks as you go”)

• The next design strategy of the design activity is decided at the end of a given stage

• Incremental

• Each stage of development is treated as a task of incrementally improving the existing design


11

Architectural Process Identifying a Viable Strategy

• Use fundamental design tools:

- Abstraction

- Modularity

• Use:

- Inspiration, where inspiration is needed

- Predictable techniques elsewhere.

• Applying own experience or experience of others.

But how?

But where iscreativity required?


12

Architectural ProcessThe Basic Tools of Software Engineering

• Abstraction, applicable in two different ways:

- Bottom-up: look at details, and abstract “up” to concepts

- Top-down: choose concepts, then add detailed substructure, and move “down”

• Modularity, applicable in six different ways:

- Splitting a design into two or more modules

- Substituting one design module for another

- Augmenting the system by adding a new module

- Excluding a module from the system

- Inverting a module to create new interfaces (design rules)

- Porting a module to another system

• The key design principles


13

Architectural ProcessA Few Definitions*

• Abstraction:

- “The act or process of separating in thought, of considering a thing independently of its associations; or a substance independently of its attributes; or an attribute or quality independently of the substance to which it belongs.”

• Reification:

- “The mental conversion of … [an] abstract concept into a thing.”

• Deduction:

- “The process of drawing a conclusion from a principle already known or assumed; spec. in Logic, inference by reasoning from generals to particulars; opposed to INDUCTION.”

• Induction:

- “The process of inferring a general law or principle from the observation of particular instances (opposed to DEDUCTION).”

source: Oxford English Dictionary


14

Architectural ProcessAbstraction and the Fundamental Machines

• What concepts should be chosen at the outset of a design task?

- One technique: Search for a “fundamental machine” that serves as an abstraction of a potential system that will perform the required task. For instance:

- Q: what kind of fundamental machine makes a software system embedded in a washing machine?

- A: at core, it is basically just a little finite state machine.

• Fundamental machines provide a plausible first conception of how an application might be built.

• Every application domain has its common fundamental machines.


15

Spreadsheets

DatabasesTransactions

Banking

Matrices

Mathematical functions

Scientific computing

HypertextComposite documents

Web pages

Finite state machinesProcess control

Structured documentsLayouts

Word processing

Pixel arrays

Transformation matricesWidgets

Graphics

Fundamental MachinesDomain

Architectural ProcessFundamental Machines


16

Architectural ProcessChoosing the Level and Terms of Discourse

• Any attempt to use abstraction as a tool must choose a level of discourse, and once that is chosen, must choose the terms of discourse.

- Variant 1: initial level of discourse is one of the application as a whole (step-wise refinement).

- Variant 2: work, initially, at a level lower than that of the whole application.

- Once several such sub-problems are solved they can be composed together to form an overall solution

- Variant 3: work, initially, at a level above that of the desired application.

- E.g. handling simple application input with a general parser.


17

Architectural ProcessThe Key Design Principles

• Separation of concerns: Break your application into distinct features that overlap in functionality as little as possible.

• Single Responsibility Principle : Each component or a module should be responsible for only a specific feature or functionality.

• Principle of least knowledge : A component or an object should not know about internal details of other components or objects (also known as the Law of Demeter).

• Don’t Repeat Yourself (DRY) : There should be only one component providing a specific functionality; the functionality should not be duplicated in any other component.

• Avoid doing a big design upfront : If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely (often abbreviated as BDUF).

• Prefer composition over inheritance : Wherever possible, use composition over inheritance when reusing functionality because inheritance increases the dependency between parent and child classes, thereby limiting the reuse of child classes.


18

Architectural ProcessThe Grand Tool: Refined Experience

• Experience must be reflected upon and refined.

• The lessons from prior work include not only the lessons of successes, but also the lessons arising from failure.

• Learn from success and failure of other engineers

- Literature

- Conferences

- Networking

• Experience can provide that initial feasible set of “alternative arrangements for the design as a whole”.


19

Agenda





• Q & A


20

Refined Experience Patterns, Styles, and DSSAs

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc..


21

Refined Experience Domain-Specific Software Architectures*

• A DSSA is an assemblage of software components

- specialized for a particular type of tasks (domain),

- generalized for effective use across that domain,

- composed in a standardized structure (topology) effective for building successful applications.

• Since DSSAs are specialized for a particular domain they are only of value if one exists for the domain wherein the engineer is tasked with building a new application.

• DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for developing a new architectural design.

Source: http://www.sei.cmu.edu/pub/documents/92.reports/pdf/sr09.92.pdf


22

Refined Experience Architectural Patterns

• An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.

• Architectural patterns are similar to DSSAs but applied “at a lower level” and within a much narrower scope.


23

Refined Experience State-Logic-Display: Three-Tiered Pattern

• Application Examples

- Business applications

- Multi-player games

- Web-based applications

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc.


24

Refined ExperienceModel-View-Controller (MVC)

• Objective: Separation between information, presentation and user interaction.

• When a model object value changes, a notification is sent to the view and to the controller.

- Thus, the view can update itself and the controller can modify the view if its logic so requires.

• When handling input from the user the windowing system sends the user event to the controller.

- If a change is required, the controller updates the model object.

Model(Encapsulation of information)

View(Encapsulation of display choices)

Controller(Encapsulation of

interaction semantics)

Graphicaldisplay

UI events


25

Refined Experience Architectural Styles

• An architectural style is a named collection of architectural design decisions …

• A primary way of characterizing lessons from experience in software system design

• Reflect less domain specificity than architectural patterns

• Useful in determining everything from subroutine structure to top-level application structure

• Many styles exist (and we will discuss them in detail ☺)


26

Agenda





• Q & A


27

Architectural StylesDefinitions of Architectural Style

• Definition, in two “flavors”:

- An architectural style is a named collection of recurring organizational patterns & idioms, meaning

- established, shared understanding of common design forms

- mark of mature engineering field. (Shaw & Garlan)

- An architectural style is an abstraction of recurring composition & interaction characteristics in a set of architectures (Medvidovic & Taylor)


28

Architectural Styles Basic Properties of Styles

• A vocabulary of design elements

- Component and connector types; data elements

- e.g., pipes, filters, objects, servers

• A set of configuration rules

- Topological constraints that determine allowed compositions of elements

- e.g., a component may be connected to at most two other components

• A semantic interpretation

- Compositions of design elements have well-defined meanings

• Possible analyses of systems built in a style


29

Architectural StylesBenefits of Using Styles

• Design reuse

- Well-understood solutions applied to new problems

• Code reuse

- Shared implementations of invariant aspects of a style

• Understandability of system organization

- A phrase such as “client-server” conveys a lot of information

• Interoperability

- Supported by style standardization

• Style-specific analyses

- Enabled by the constrained design space

• Visualizations

- Style-specific depictions matching engineers’ mental models


30

Architectural StylesStyle Analysis Dimensions

• What is the design vocabulary (component and connector types)?

• What are the allowable structural patterns?

• What is the underlying computational model?

• What are the essential invariants of the style?

• What are common examples of its use?

• What are the (dis)advantages of using the style?

• What are the style’s specializations?


31

Architectural StylesSome Common Styles

• Traditional, language-influenced styles

- Sequential processing

- Object-oriented

• Layered

- Virtual machines

- Client-server

• Data-flow styles

- Batch sequential

- Pipes and filters

• Shared memory

- Blackboard

- Rule based

• Interpreter

- Interpreter

- Mobile code

• Implicit invocation

- Event-based

- Publish-subscribe

• Peer-to-peer

• “Derived” styles

- REST

- CORBA

- COM/DCOM


32

Architectural Styles Sequential Processing Style

• Components are programs and libraries

- Main executable and associated dll’s

• Connectors are function invocations and corresponding parameters

• Style invariants

- There is always a main execution and control loop

• Advantages

- Simplicity

• Disadvantages

- Simplicity ☺


33

Architectural Styles Sequential Processing Style

Main Loop

Functionlibrary(dll)

Function library(dll)




call/return

call/returncall/return

call/return

call/returnExecutable


34

Architectural Styles Object-Oriented Style

• Components are objects

- Data and associated operations

• Connectors are messages and method invocations


- Objects are responsible for their internal representation integrity

- Internal representation is hidden from other objects

• Advantages

- “Infinite malleability” of object internals

- System decomposition into sets of interacting agents

• Disadvantages

- Objects must know identities of servers

- Side effects in object method invocations


35

Architectural Styles Object-Oriented Style

Domain object

Interaction & controlobject

Processing object

Procedurecall

Procedurecall “SET”“GET”

Procedurecall “PROCESS”


36

Architectural Styles Layered Style – 1

• Hierarchical system organization

- “Multi-level client-server”

- Each layer exposes an interface (API) to be used by above layers

• Each layer acts as a

- Server: service provider to layers “above”

- Client: service consumer of layer(s) “below”

• Connectors are protocols of layer interaction

• Virtual machine style results from fully opaque layers


37

Architectural Styles Layered Style – 2

• Advantages

- Increasing abstraction levels

- Evolvability

- Changes in a layer affect at most the adjacent two layers (reuse)

- Different implementations of layer are allowed as long as interface is preserved

- Standardized layer interfaces for libraries and frameworks

• Disadvantages

- Not universally applicable

- Performance

• Layers may have to be skipped

- Determining the correct abstraction level


38

Architectural Styles Layered Style

L3

L2.cL2.bL2.a

L1.zL1.yL1.x

breach

breach

bridging


39

Architectural Styles Virtual Machine Style

Layer 1

Layer 2

Layer 3

Application A

Application B Application C

Application D


40

Architectural Styles Client-Server Style

• Components are clients and servers

• Connectors are RPC-based network interaction protocols

• Style invariants:

- Servers do not know number or identities of clients

- Clients know server’s identity

• Advantages

- Explicit support for separation of concerns

• Disadvantages

- Lack of support for single responsibility


41

Architectural Styles Client-Server Style

SERVERBusiness Logic

StateProcess

CLIENT 1User interaction

Procedurecall

Procedurecall

Procedurecall




42

Architectural Styles Data-Flow Styles

Batch Sequential

- Separate programs are executed in order; data is passed as an aggregate from one program to the next.

- Connectors: file system tools, human operators (e.g. ConnectDirect, tapes)

- Data Elements: Explicit, aggregate elements passed from one component to the next upon completion of the producing program’s execution.

• Typical uses: Transaction processing in financial systems. “The Grandfather of all Styles”


43

Architectural Styles Pipes and Filters Style – 1

• Components are filters

- Transform input data streams into output data streams

- Possibly incremental production of output

• Connectors are pipes

- Conduits for data streams


- Filters are independent (no shared state)

- Filter has no knowledge of up- or down-stream filters

• Variations

- Pipelines — linear sequences of filters

- Bounded pipes — limited amount of data on a pipe

- Typed pipes — data strongly typed


44

Architectural Styles Pipes and Filters Style – 2

• Advantages

- System behavior is a succession / composition of component behaviors

- Filter addition, replacement, and reuse (possible to hook any two filters together)

- Certain analyses (throughput, latency, deadlock)

- Concurrent execution

• Disadvantages

- Batch organization of processing

- Interactive applications

- Lowest common denominator on data transmission


45

Architectural Styles Pipes and Filters Style

Filter Filter Filter

Filter

Pipe

Pipe

PipePipe

PipeDatastream

Datastream


46

Architectural Styles Blackboard Style

• Two kinds of components

- Central data structure (blackboard)

- Components operating on the blackboard (agents)

• Connectors can be anything from RPC based protocols to shared memory


- System control is entirely driven by the blackboard state

• Advantages

- Excellent separation of concerns and single responsibility

- Explicit process state

• Disadvantages

- Streamlining the processing

- Interactive applications


47

Architectural Styles Blackboard Style

Data structure(Blackboard)

Agent 2

Agent 3

Agent …

Agent 1

Agent n

Agent n-1


48

Architectural Styles Rule-Based Style

Inference engine parses user input and determines whether it is a fact/rule or a query. If it is a fact/rule, it adds this entry to the knowledge base. Otherwise, it queries the knowledge base for applicable rules and attempts to resolve the query.

• Components are user interface, inference engine, knowledge base

• Connectors are direct procedure calls and/or shared memory.

• Data Elements are facts and queries

• Behavior of the application can be very easily modified through addition or deletion of rules from the knowledge base.

• Caution: When a large number of rules are involved understanding the interactions between multiple rules affected by the same facts can become verydifficult.


49

Architectural Styles Rule-Based Style

User interactionfacts/rules || queries

Inference engine

Procedurecall

Procedurecall

Knowledge base(facts/rules)


50

Architectural Styles Interpreter Style

Interpreter parses and executes input commands, updating the state

• Components are command interpreter, program/interpreter state, user interface.

• Connectors typically direct procedure calls and shared state.

• Highly dynamic behavior possible, where the set of commands is dynamically modified. System architecture may remain constant while new capabilities are created based upon existing primitives.

• Superb for end-user programmability; supports dynamically changing set of capabilities

• Examples: VBScript, Jscript/ECMAScript


51

Architectural Styles Interpreter Style

Pseudo-codeState

Pseudo-code To Be

Interpreted

InterpretationEngine

Interpretation Engine

Control State

inputs

outputsSelected instructions

Selected data


52

Architectural Styles Mobile-Code Style

• Summary: a data element (some representation of a program) is dynamically transformed into a data processing component.

• Components: “Execution dock”, which handles receipt of code and state; code compiler/interpreter

• Connectors: Network protocols and elements for packaging code and data for transmission.

• Data Elements: Representations of code as data; program state; data

• Examples: SQL Ad-hoc querying, some Reflection scenarios


53

Architectural Styles Mobile-Code Style

SERVER

Executionenvironment



streamof code

streamof code

streamof code


54

Architectural Styles Implicit Invocation Style – 1

• Event announcement instead of method invocation

- “Listeners” register interest in and associate methods with events

- System invokes all registered methods implicitly

• Component interfaces are methods and events

• Two types of connectors

- Invocation is either explicit or implicit in response to events


- “Announcers” are unaware of their events’ effects

- No assumption about processing in response to events


55

Architectural Styles Implicit Invocation Style – 2

• Advantages

- Component reuse

- System evolution

- Both at system construction-time & run-time

• Disadvantages

- Counter-intuitive system structure

- Components relinquish computation control to the system

- No knowledge of what components will respond to event

- No knowledge of order of responses


56

Architectural Styles Publish-Subscribe

Subscribers register/deregister to receive specific messages or specific content. Publishers broadcast messages to subscribers either synchronously or asynchronously.

• Components: Publishers, subscribers, proxies for managing distribution

• Connectors: Typically a network protocol is required. Content-based subscription requires sophisticated connectors.

• Data Elements: Subscriptions, notifications, published information

• Topology: Subscribers connect to publishers either directly or may receive notifications via a network protocol from intermediaries

• Qualities yielded: Highly efficient one-way dissemination of information with very low-coupling of components


57

Architectural Styles Publish-Subscribe

SERVER(publisher)

Subscriber 1

Subscriber 2

Subscriber 3

Event

Stream

Stream

Stream


58

Architectural Styles Event-Based Style

• Independent components asynchronously emit and receive events communicated over event buses

• Components: Independent, concurrent event generators and/or consumers

• Connectors: Event buses (at least one)

• Data Elements: Events – data sent as a first-class citizen over the event bus

• Topology: Components communicate with the event buses, not directly to each other.

• Variants: Component communication with the event bus may either be push or pull based.

• Highly scalable, easy to evolve, effective for highly distributed applications.


59

Architectural Styles Event-Based Style

Business logic

Process

User interaction

State

Event bus

eventnotifications

eventnotifications

eventnotifications

eventnotifications


60

Architectural Styles Peer-to-Peer Style

• State and behavior are distributed among peers which can act as either clients or servers.

• Peers: independent components, having their own state and control thread.

• Connectors: Network protocols, often custom.

• Data Elements: Network messages

• Topology: Network (may have redundant connections between peers); can vary arbitrarily and dynamically

• Supports decentralized computing with flow of control and resources distributed among peers.

• Highly robust in the face of failure of any given node.

• Scalable in terms of access to resources and computing power.

- But extremely demanding in terms of protocol’s complexity!


61

Architectural Styles Peer-to-Peer Style

Applicationinstance

Applicationinstance

Applicationinstance

Applicationinstance

Stream

Applicationinstance

Stream

Stream

Stream

Stream

Stream


62

Architectural Styles Heterogeneous Styles

• More complex styles created through composition of simpler styles

• REST (REpresentational State Transfer)

- Focus on state transitions instead on method invocation

• Distributed objects

- CORBA, COM/DCOM

• …


63

Architectural Styles REST Style

A style where the application state and functionality are abstracted into uniquely addressable resources.

• Components: resources and clients

• Connectors: network protocol (client-server, stateless, cacheable, layered).

• Data Elements: state.

• Topology: practically every possible meshing topology imaginable.


64

Architectural Styles REST Style

User agent

Resource server 1

Resource server 2

Resource server n

…

Limited verbs & typesUnlimited nouns


65

Architectural Styles Distributed Objects: CORBA, COM/DCOM

• “Objects” (coarse- or fine-grained) run on various hosts, written in heterogeneous languages. Objects provide services through well-defined interfaces. Objects invoke methods across host, process, and language boundaries via remote procedure calls (RPCs).

• Components: Objects (software components exposing services through well-defined provided interfaces)

• Connector: (Remote) Method Invocation / (Remote) Procedure Call

• Data Elements: Arguments to methods, return values, and exceptions

• Topology: General graph of objects from callers to callees.

• Additional constraints imposed: Data passed in remote procedure calls must be serializable. Callers must deal with exceptions that can arise due to network or process faults.

• Location, platform, and language “transparency”. CAUTION – usually does not works as advertised! ☺


66

Architectural Styles Distributed Objects: CORBA, COM/DCOM

Componentconsumer

Component server 1

Component server 2

Component server n

…

Limited typesUnlimited verbs & nouns


67

Architectural StylesObservations

• Different styles result in

- Different architectures

- Architectures with greatly differing properties

• A style does not fully determine resulting architecture

- A single style can result in different architectures

- Considerable room for

- Individual judgment

- Variations among architects

• A style defines domain of discourse

- About problem (domain)

- About resulting system


68

Architectural Styles Style Summary (1/4)

Centrality presents a single-point-of-failure risk; Network bandwidth limited; Client machine capabilities rival or exceed the server’s.

Centralization of computation and data at a single location (the server) promotes manageability and scalability; end-user processing limited to data entry and presentation.

Clients request service from a serverClient-server

Many levels are required (causes inefficiency).Data structures must be accessed from multiple

layers.

Many applications can be based upon a single, common layer of services.

Interface service specification resilient when implementation of a layer must change.

Virtual machine, or a layer, offers services to layers above it

Virtual Machines

Layered

Application is distributed in a heterogeneous network.

Strong independence between components necessary.

High performance required.

Close mapping between external entities and internal objects is sensible.

Many complex and interrelated data structures.

Objects encapsulate state and accessing functions

Object-oriented

Complex data structures needed.Future modifications likely.

Application is small and simple.Main program controls program execution, calling multiple subroutines.

Main Program and Subroutines

Language-influenced styles

Avoid It WhenUse It WhenSummaryStyle Category & Name


69


Number of rules is large.Interaction between rules present.High-performance required.

Problem data and queries expressible as simple rules over which inference may be performed.

Use facts or rules entered into the knowledge base to resolve a query

Rule-based

Programs deal with independent parts of the common data.Interface to common data susceptible to change. When interactions between the independent programs require complex regulation.

All calculation centers on a common, changing data structure;Order of processing dynamically determined and data-driven.

Independent programs, access and communicate exclusively through a global repository known as blackboard

Blackboard

Shared memory

Interaction between components required. Exchange of complex data structures between components required.

[As with batch-sequential] Filters are useful in more than one application. Data structures easily serializable.

Separate programs, a.k.a. filters, executed, potentially concurrently. Pipes route data streams between filters

Pipes-and-filters

Interactivity or concurrency between components necessary or desirable. Random-access to data required.

Problem easily formulated as a set of sequential, severable steps.

Separate programs executed sequentially, with batched input

Batch sequential

Data-flow styles


70


Security of mobile code cannot be assured, or sandboxed.When tight control of versions of deployed software is required.

When it is more efficient to move processing to a data set than the data set to processing.When it is desirous to dynamically customize a local processing node through inclusion of external code

Code is mobile, that is, it is executed in a remote host

Mobile Code

High performance required.Highly dynamic behavior required. High degree of end-user customizability.

Interpreter parses and executes the input stream, updating the state maintained by the interpreter

Interpreter

Interpreter


71


When high overhead of supporting middleware is excessive. When network properties are unmaskable, in practical terms.

Objective is to preserve illusion of location-transparency

Objects instantiated on different hosts

Distributed Objects

When scenarios are local and rather specialized.

When extreme scalability in heterogeneous application environments is required.When frequent changes are part of the non-functional requirements.

Mesh of components abstracting state and functionality, uniquely addressable over a constrained set of well-defined operations.

REST

More complex styles

Trustworthiness of independent peers cannot be assured or managed.Resource discovery inefficient without designated nodes.

Peers are distributed in a network, can be heterogeneous, and mutually independent.Robust in face of independent failures.Highly scalable.

Peers hold state and behavior and can act as both clients and servers

Peer-to-peer

Guarantees on real-time processing of events is required.

Components are concurrent and independent.Components heterogeneous and network-distributed.

Independent components asynchronously emit and receive events communicated over event buses

Event-based

When middleware to support high-volume data is unavailable.

Components are very loosely coupled. Subscription data is small and efficiently transported.

Publishers broadcast messages to subscribers

Publish-subscribe

Implicit Invocation


72

Agenda





• Q & A


73

Resources

• http://portal.acm.org/dl.cfm

• http://msdn.microsoft.com/en-us/architecture/default.aspx

• http://www.sei.cmu.edu/architecture/

• http://ieeexplore.ieee.org/Xplore/guesthome.jsp

• http://www.wwisa.org/

• http://www.iasahome.org/web/home/home

Architectur 2 Architecture Styles

Documents