Architectural Middleware

1. Architectural Middleware Eric M. Dashofy CSCI 578 at the University of Southern California March 24, 2011

2. Review: From Architecture to Design to Implementation

3. Mapping Architecture to Implementation • Limit/prevent architectural erosion • There is a community who advocates Model-Driven Architecture or Model-Driven Development • Ideal: fully generate implementationsfrom architectural models • This ideal is rarely feasible • Models are necessarily abstractionsof systems • We can take the modeledparts and map those,especially with domainknowledge

4. The Gap to Bridge • Architecture Concepts • Application: Components, connectors, interfaces (at component level), high-level behaviors • Style: Connection rules, communication rules, concurrency rules… • Programming language concepts • Functions, conditionals, variables, structures, assignments, classes and objects… • Operating system concepts • Threads, mutexes, sockets, files and filesystems, IPC mechanisms…

5. The Key Question How do we take architectural concepts and realize them using the elements that we have in the implementation world?

6. A Discussion About Mapping

7. A Discussion About Mapping

8. Middleware, Frameworks, and Mappings (oh my!) Application “Middleware” Programming Language & OS • Middleware has a lot of broad definitions • My definition: any software that sits in between your application and your Programming Language/OS to provide services not provided by PL/OS • Architectural frameworksare a special typeof middleware

9. So what’s the difference? • There’s no clear, bright line • Middleware is designed based on services • Architectural concerns are secondary • Frameworks are designed based on architectural styles and patterns • Services are secondary

10. Traditional Middleware • Traditional middleware may be based on services, but it induces an architectural style (Di Nitto and Rosenblum) • Consider CORBA • Services: Network transparency, language transparency, OS transparency • Induced properties: (primarily) synchronous request-response point-to-point communication, hiding of network properties, OO-style topologies

11. Middleware is Everywhere • Software reuse is alive and well, but perhaps thriving most at the middleware layer • Software systems today are increasingly built on growing stacks of underlying middleware – whether we call it • “Middleware” • “Frameworks” • “Component Libraries” • “Toolkits” • All of it has architectural implications • Who is really designing your software?

12. Let’s Discuss some Middleware • “Distributed Systems Middleware” • DCE, Courier, CORBA, (D)COM(+), RMI, Web Services • Message-Oriented Middleware • MQ Series, MSMQ, JMS implementations • “Enterprise Service Buses” • Web Application Middleware • Server-side: JSP, Spring, JSF, Rich Faces, Rails, Grails, Pylons, TurboGears • Client-Side: YUI, JQuery, JQuery UI, Dojo, Prototype

13. Architecture Frameworks • Start from an architectural style (or specific architecture) • Pipe-and-filter • Web Services • C2 • Prism • Myx • Develop middleware that supports (not necessarily enforces) the constraints of the style, tailored to support • Desirable NFPs • Additional desirable properties/services

14. A Tale of Four Frameworks Supporting the evolution of one system (ArchStudio) over four versions. Through a fundamental change in architectural style (C2Myx) Three research-based (Lightweight C2, Flexible C2, Myx) One off the shelf (OSGi)

15. Review: C2 Style

16. Framework #1: Lightweight C2 Framework 16 classes, 3000 lines of code Components & connectors extend abstract base classes Concurrency, queuing handled at individual comp/conn level Messages are request or notification objects Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

17. Lightweight C2 Framework • Advantages • Simple, small • Control concurrency (or not) at brick level • Disadvantages • Fixed top, bottom interfaces • Potential for deadlock • Single-inheritance limitation of Java

18. ArchStudio 2

19. Framework #2: Flexible C2 Framework 73 classes, 8500lines of code Uses interfacesrather than baseclasses Threading policyfor applicationis pluggable Message queuing policy isalso pluggable Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

20. Framework #2: Flexible C2 Framework Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

21. Flexible C2 Framework • Advantages • Ability to implement and change out message queuing, threading policies • …but it turned out not to matter • However, it did enable the “Steppable Engine” • Reduced dependency on base classes • Flexible interfaces permit non-C2-topologies • Synchronous call support • Fully serializable control interface • Disadvantages • Complexity • Performance • Certain threading policies (e.g., shepherd threads) difficult to implement

22. ArchStudio 3

23. The Myx Style • Combines useful qualities of C2, Weaves • (C2) All communication through interfaces • (C2) No assumption of shared state • (C2) Substrate Independence • Top, bottom interfaces, enforced layering • (C2) Asynchronous eventing • (Weaves) Synchronous invocations • (Weaves) Connectors create threading policy • Relatively hard to deadlock

24. Myx: Synchronous Patterns Direct Call With Proxy

25. Myx: Asynchronous Patterns Downward Event Upward Event

26. Myx: Nifty Patterns

27. Framework #3: Myx Framework 62 classes, 2600 lines of code Minimal required support for brick classes Pluggable brick loaders Framework does not getinvolved in anyinter-brickcommunication Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

28. Myx Framework • Advantages • Performance: all communication between bricks direct • Library of reusable connectors • Pluggable brick loaders permit operation in different contexts • This becomes important later • Can support non-Myx topologies • Fully serializable control interface • Flexible dynamism • Disadvantages • Complexity (sorta) • Monitorability

29. ArchStudio 4

30. Worlds are Mixing! OSGi and Myx • Myx was developed as a general-purpose architectural style • But was specifically built to support ArchStudio 4 • ArchStudio 4 was going to be built in Eclipse • Considered AS3+Myx but rejected • Eclipse has its own framework (OSGi), inducing a style

31. Simplified view of OSGi Bundle Bundle class class class class class class class class ExposedPkgs ExposedPkgs

32. Simplified view of OSGi Bundle Bundle class class class class class class class class ExposedPkgs ExposedPkgs

33. Simplified view of OSGi Bundle Bundle class class class class class class class class ExposedPkgs ExposedPkgs

34. Simplified view of OSGi Bundle Bundle class class class class class class class class ExposedPkgs ExposedPkgs

35. OSGi Why? • Provide a system with deployable and undeployable units • With well-known, manageable lifecycles • Permit lazy loading of bundles • Permit dynamism • In a limited way

36. Integration Attempt #1 (AS4) Bundle (all exposed)

37. Handling the Master of the Universe problem

38. Approach #1: Evaluation • (+) “Hatting” solution solves MOU problem • (-) But it’s a dirty dirty hack • (+) Requires no Eclipse-specific code in Myx framework • (+) Otherwise works OK with Eclipse and permits deploy/undeploy through the Eclipse Update system • (-) But the unit of deployment is the whole app!

39. Integration Attempt #2 (AS5) “Core” Bundle “Core” Bundle class class class class class class class class “Common” Bundle “Common” Bundle

40. Integration Attempt #2 (AS5) “Core” Bundle “Core” Bundle class class class class class class class class “Common” Bundle “Common” Bundle

41. Approach #2: Evaluation • (+) “Hatting” solution still solves MOU problem • (-) But it’s still a dirty dirty hack • (+) Eclipse-specific code in Myx framework can be written entirely as extensions in a separate bundle • (+) Deploy/undeploy at the level of an individual component/connector

42. Takeaways • Middleware is Everywhere and Everyware • May have more influence on your architecture than you do! • Beware middleware that gives you enticing services, but does not improve your cognitive control over your system • Frameworks are tricky to build • But well-built frameworks can substantially reduce the burden on app developers • Concurrency is an area where this can be especially true

43. Takeaways (cont.) • Efficient frameworks stay out of the way of inter-component communication • Component granularity matters for efficiency • The difficulty in elegantly merging an architecture framework with existing middleware is very high • This may be the biggest barrier to the adoption of strong architectural styles.

44. Backup charts

45. Implementing Lunar Lander in C2 Framework: LightweightC2 framework Each component has itsown thread of control Components receiverequests or notificationsand respond with newones Message routing followsC2 rules This is a real-time, clock-driven version of Lunar Lander Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

46. Implementing Lunar Lander in C2 (cont’d) First: Clock component Sends out a ‘tick’ notificationperiodically Does not respond to anymessages Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

47. Clock Component import c2.framework.*; public class Clock extends ComponentThread { public Clock() { super.create("clock", FIFOPort.class); } public void start() { super.start(); Thread clockThread = new Thread() { public void run() { // Repeat while the application runs while (true) { // Wait for five seconds try { Thread.sleep(5000); } catch (InterruptedExceptionie) {} //Send out a tick notification Notification n = new Notification("clockTick"); send(n); } } }; Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

48. Clock Component import c2.framework.*; public class Clock extends ComponentThread{ public Clock(){ super.create("clock", FIFOPort.class); } public void start(){ super.start(); Thread clockThread = new Thread(){ public void run(){ //Repeat while the application runs while(true){ //Wait for five seconds try{ Thread.sleep(5000); } catch(InterruptedException ie){} //Send out a tick notification Notification n = new Notification("clockTick"); send(n); } } }; clockThread.start(); } protected void handle (Notification n) { // This component does not handle notifications } protected void handle (Request r) { // This component does not handle requests } } Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

49. Implementing Lunar Lander in C2 • Second: GameStateComponent • Receives request to updateinternal state • Emits notifications of newgame state on requestor when state changes • Does NOT compute newstate • Just a data store Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

50. GameState Component import c2.framework.*; public class GameState extends ComponentThread{ public GameState() { super.create("gameState", FIFOPort.class); } // Internal game state and initial values int altitude = 1000; int fuel = 500; int velocity = 70; int time = 0; intburnRate = 0; booleanlandedSafely = false; Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.