Software Architecture

Transcription

1 Software Architecture Lecture 6 Event Systems Rob Pettit George Mason University SWE 443 Software Architecture Event Systems 1

2 previously data flow and call-return styles data flow batch sequential dataflow network (pipe & filter) acyclic, fan-out, pipeline, Unix closed loop control call-and-return main program/subroutines information hiding objects stateless client-server SOA interacting processes communicating processes event systems implicit invocation publish-subscribe data-oriented repository transactional databases stateful client-server blackboard modern compiler data-sharing compound documents hypertext Fortran COMMON LW processes hierarchical tiers interpreter N-tiered client-server SWE 443 Software Architecture Event Systems 2

3 This lecture event-based styles data flow batch sequential dataflow network (pipe & filter) acyclic, fan-out, pipeline, Unix closed loop control call-and-return main program/subroutines information hiding objects stateless client-server SOA interacting processes communicating processes event systems implicit invocation publish-subscribe data-oriented repository transactional databases stateful client-server blackboard modern compiler data-sharing compound documents hypertext Fortran COMMON LW processes hierarchical tiers interpreter N-tiered client-server SWE 443 Software Architecture Event Systems 3

4 Outline interacting processes style family tree: communicating peers publish-subscribe implicit invocation event systems quality attributes SWE 443 Software Architecture Event Systems 4

5 communication is loosely coupled in the interacting processes style components independent tasks (processes or threads) may be distributed connectors Connectors are the bindings between events announcements and handling routines communication is loosely coupled and often asynchronous system components may or may not have knowledge of other components functionality of one component does not depend upon others overall system functionality depends upon all components functioning and communicating properly SWE 443 Software Architecture Event Systems 5

6 interacting processes family tree communicating peers event systems aka implicit events publish aka broadcast publish-subscribe implicit invocation SWE 443 Software Architecture Event Systems 6

7 communicating peers know recipient s identity event to Z component X component C event to Y component Z event to C component Y event to B component B component A event to C identity of event recipients is known by event senders order of execution can be prescribed/predicted components execute independently (in contrast to call-return) communicating finite state machines are good example of this style SWE 443 Software Architecture Event Systems 7

8 event systems publish aka broadcast Don't care component X event i Don't care component C Don't care component Y component Z component A Don't care I CARE! component B Ethernet protocol in local area networks uses similar idea: event packet is tagged with recipient s address SWE 443 Software Architecture Event Systems 8

9 publish-subscribe & often implicit invocation rely on event infrastructure component X component Y component Z reg i evt: i evt: i reg j evt: i evt: i reg i evt: i event bus i: X, Z j: Y identity of event recipients is unknown to senders Publishers of events do not know which components (subscribers) will be affected by those events order of event delivery is bus-dependent different event buses make different guaranties or no guaranties about ordering SWE 443 Software Architecture Event Systems 9

10 publish-subscribe common example interacting tools in a shared environment (e.g. IDE) editor announces it has finished editing a module compiler registers for such announcements and automatically re-compiles module editor shows syntax errors reported by compiler debugger announces it has reached a breakpoint editor registers for such announcements and automatically scrolls to relevant source line SWE 443 Software Architecture Event Systems 10

11 implicit invocation recipients register callback call Y.m1() when i component A component X component Y component B call Y.m2() when j directly with event issuer e.g. supported by Java Observable/Observer classes facilitated by broker e.g. database triggers SWE 443 Software Architecture Event Systems 11

12 in summary communicating peers asynchronous messages aka explicit events explicit wrt identifying the recipient event systems aka implicit events events delivered to all interested components in some order publish aka broadcast publish-subscribe interested components subscribe to events interested components receive asynchronous message implicit invocation interested components register a callback method upon the event, the method is invoked (call-return) SWE 443 Software Architecture Event Systems 12

13 outline interacting processes style event systems quality attributes SWE 443 Software Architecture Event Systems 13

14 events are widely supported Ada: defines interrupts and interrupt handlers C++: defines events, event sources and event receivers Visual Basic: widgets send various events depending upon user interaction, timers, and so forth; code attached to event is executed when event occurs Java Observer & Observable classes database triggers: conditions associated to data trigger callbacks to registered methods middleware support for events: CORBA, etc. SWE 443 Software Architecture Event Systems 14

15 outline interacting processes style event systems quality attributes SWE 443 Software Architecture Event Systems 15

16 event systems X Y Z event bus promote scalability easy to add new components however, may increase overhead and hurt performance performance may be a challenge hard to coordinate the order of processing predicting and optimizing performance can be a challenge SWE 443 Software Architecture Event Systems 16

17 event systems X Y Z event bus promote reuse decoupling: events offer an interface with little assumptions announcers don t need to know the identity of responders easy to reuse/register a component that communicates this way promote conceptual integrity components work more independently interaction policy can be cleanly separated from internals however, due to non-determinism it may be hard to model and reason about run-time behavior SWE 443 Software Architecture Event Systems 17

18 event systems X Y Z event bus promote maintainability changes to one component have little or no effect on others however, changes to when a component announces/register may impact system behavior testing may be a challenge hard to trace origin/path of events may require special tools and/or system structures to do so hard to replicate ordering of actions during testing & after deployment SWE 443 Software Architecture Event Systems 18

19 in summary, many event systems rely on event infrastructure component X component Y component Z event bus identity of event recipients is unknown to senders order of event delivery is unknown different event buses make different guaranties or no guaranties about ordering SWE 443 Software Architecture Event Systems 19

20 in summary, event systems easy to modify, hard to test X Y Z event bus QAs promoted due to decoupling and encapsulation reuse modifiability scalability QAs inhibited performance: hard to guarantee response time testability: hard to test and reason about correctness availability: possible to miss events (no registrations) SWE 443 Software Architecture Event Systems 20