Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Architectural Styles Part II Software Architecture Lecture 6

Software Architecture: Foundations, Theory, and Practice Implicit Invocation Style Event announcement instead of method invocation u “Listeners” register interest in and associate methods with events u System invokes all registered methods implicitly Component interfaces are methods and events Two types of connectors u Invocation is either explicit or implicit in response to events Style invariants u “Announcers” are unaware of their events’ effects u No assumption about processing in response to events 2

Software Architecture: Foundations, Theory, and Practice Implicit Invocation (cont’d) Advantages u Component reuse u System evolution Both at system construction-time & run-time Disadvantages u Counter-intuitive system structure u Components relinquish computation control to the system u No knowledge of what components will respond to event u No knowledge of order of responses 3

Software Architecture: Foundations, Theory, and Practice Publish-Subscribe Subscribers register/deregister to receive specific messages or specific content. Publishers broadcast messages to subscribers either synchronously or asynchronously. 4

Software Architecture: Foundations, Theory, and Practice Publish-Subscribe (cont’d) 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 5

Software Architecture: Foundations, Theory, and Practice Pub-Sub LL 6 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice 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 entity 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. 7

Software Architecture: Foundations, Theory, and Practice Event-based LL 8 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice 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 9

Software Architecture: Foundations, Theory, and Practice Peer-to-Peer Style (cont’d) 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 caution on the protocol! 10

Software Architecture: Foundations, Theory, and Practice Peer-to-Peer LL 11 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Heterogeneous Styles More complex styles created through composition of simpler styles REST (from the first lecture) u Complex history presented later in course C2 u Implicit invocation + Layering + other constraints Distributed Architecture u OO + client-server network style u CORBA u SOA 12

Software Architecture: Foundations, Theory, and Practice C2 Style An indirect invocation style in which independent components communicate exclusively through message routing connectors. Strict rules on connections between components and connectors induce layering. 13

Software Architecture: Foundations, Theory, and Practice C2 Style (cont’d) Components: Independent, potentially concurrent message generators and/or consumers Connectors: Message routers that may filter, translate, and broadcast messages of two kinds: notifications and requests. Data Elements: Messages – data sent as first-class entities over the connectors. Notification messages announce changes of state. Request messages request performance of an action. Topology: Layers of components and connectors, with a defined “top” and “bottom”, wherein notifications flow downwards and requests upwards. 14

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

Software Architecture: Foundations, Theory, and Practice Distributed Architecture: CORBA “Objects” (coarse - or fine-grained) run on heterogeneous 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 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 16

Software Architecture: Foundations, Theory, and Practice CORBA Concept & Implementation 17 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

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

Software Architecture: Foundations, Theory, and Practice Service-Oriented Architecture A Service Oriented Architecture (SOA) starts with a businesses process. In this context, a service is a business functionality that is well-defined, self-contained, independent from other services, and published and available to be used via a standard programming interface. Software manages business processes through a SOA with well-defined and standard interfaces that can build, enhance, and expand their existing infrastructure more flexible. SOA services can be extensively reused within a given domain or product line, and even among legacy systems. Loose coupling of service–orientation provide great flexibility for enterprises to make use of all available service recourses regardless of platform and technology restrictions. The connections between services are conducted by common and universal message oriented protocols such as the SOAP Web service protocol, which can deliver requests and responses between services loosely. A connection can be established statically or dynamically. 19

Software Architecture: Foundations, Theory, and Practice SOA Model 20 DB CCI ERPCRM Service Registry 1 register Consumer/Client SOAP XML 3 invoke 2 Discover and/or Bind Policies

Software Architecture: Foundations, Theory, and Practice Features of SOA u Loosely-coupled connection: Loose-coupling is the key attribute of SOA. u Each service component is independent from other services due to the stateless service feature. u The implementation of a service will not affect the application of the service as long as the exposed interface is not changed. u It makes SOA software much easier to evolve and update. u Interoperability: Technically any client or any service can access other services regardless of their platform, technology, vendors, or language implementations. u Reusability: Any service can be reused by any other service,. Because clients of a service only need to know its public interfaces, service composition and integration become much easier. u SOA based business application development comes much more efficient in term of time and cost. u Scalability: Loosely coupled services make themselves easy to scale. u The coarse-grained, document-oriented, and asynchronous service features enhance the scalability attribute. 21 SOA (cont’d)

Software Architecture: Foundations, Theory, and Practice Observations Different styles result in u Different architectures u Architectures with greatly differing properties A style does not fully determine resulting architecture u A single style can result in different architectures u Considerable room for Individual judgment Variations among architects A style defines domain of discourse u About problem (domain) u About resulting system 22

Software Architecture: Foundations, Theory, and Practice Style Summary (1/4) 23

Software Architecture: Foundations, Theory, and Practice Style Summary, continued (2/4) 24

Software Architecture: Foundations, Theory, and Practice Style Summary, continued (3/4) 25

Software Architecture: Foundations, Theory, and Practice Style Summary, continued (4/4) 26

Software Architecture: Foundations, Theory, and Practice Design Recovery What happens if a system is already implemented but has no recorded architecture? The task of design recovery is u examining the existing code base u determining what the system’s components, connectors, and overall topology are. A common approach to architectural recovery is clustering of the implementation-level entities into architectural elements. u Syntactic clustering u Semantic clustering 27

Software Architecture: Foundations, Theory, and Practice Syntactic Clustering Focuses exclusively on the static relationships among code-level entities Can be performed without executing the system Embodies inter-component (a.k.a. coupling) and intra- component (a.k.a. cohesion) connectivity May ignore or misinterpret many subtle relationships, because dynamic information is missing 28

Software Architecture: Foundations, Theory, and Practice Semantic Clustering Includes all aspects of a system’s domain knowledge and information about the behavioral similarity of its entities. Requires interpreting the system entities’ meaning, and possibly executing the system on a representative set of inputs. Difficult to automate May also be difficult to avail oneself of it 29