SEng 5861: Software Architecture

1. SEng 5861: Software Architecture Lecture 9 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

2. Topics for Today • Questions / Comments from Last Week • Team Technical Presentations • Concurrency Viewpoint • Integration and Communication patterns • Security Perspective • Attack Trees • Software Product Line Engineering SEng 5861 - Mike Whalen

3. Updates • Coming up to the end of term • Remaining Lectures: 11/18, 12/3, 12/10, 12/17 • 12/3 will be project presentations • 12/10 will be REST and final review • 12/17 will be final • Move REST reading to 12/10. • We’ll skip SOA readings. SEng 5861 - Mike Whalen

4. Team technical presentations SEng 5861 - Mike Whalen

5. Why? People skills are important You must earn and maintain the confidence of all of your stakeholders from senior management and users to developers, third parties, and operational staff • Often, your interactions with stakeholders are through presentations • Management: proposals, progress reports • Technical team meetings • You will be judged on the quality of the presentation • Knowing your audience is important • Being able to concisely summarize why they should care in a short presentation is critically important. SEng 5861 - Mike Whalen

6. Architecture Presentations • Two team presentations during the semester • One 10 minute project proposal • One 20 minute technical talk • Presentations should be formatted differently for different audiences • Every group member should be involved (speak) in at least one of the talks SEng 5861 - Mike Whalen

7. Technical Presentation • Audience: technical stakeholders • Depends on viewpoint chosen • Entire class will act as your stakeholders • Purpose: convey information • Provide technical overview of original model and your change to it • Persuade users that it is the right solution • Time: 20 minutes • Shoot for being able to deliver in ~15 minutes in case of questions SEng 5861 - Mike Whalen

8. Technical Presentation • Present one of the viewpoints in your architecture document + extension • Should be enough time to give flavor of architecture • Expect technical questions • E.g., questions related to comparison of alternatives SEng 5861 - Mike Whalen

9. Concurrency view SEng 5861 - Mike Whalen

10. Concurrency Management • Moore’s law is making computers with more cores rather than faster cores • Business systems are becoming more focused on real-time response • Control systems are inherently concurrent • Environment updates in parallel with controller • Availability requirements necessitate redundant systems • Hence, architects must describe and manage concurrency SEng 5861 - Mike Whalen

11. Concurrency Management • Task structure • InterprocessCommunication • State management • Synchronization and Integrity • Startup and Shutdown • Task Failure • Re-entrancy SEng 5861 - Mike Whalen

12. Concurrency Models: Process SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

13. How do we structure interprocess communication? • Many means of structuring process/process communication • Roll your own: • Shared memory • Pipes • UDP • TCP/IP • Mediated: • RPC • Message Queuing • We will examine some message queuing patterns from Enterprise Integration Patterns by Hohpe and Woolf. SEng 5861 - Mike Whalen

14. IPC: Not so Hard? String hostName = “finance.bank.com”; int port = 80; IPHostEntryhostInfo = Dns.GetHostByName(hostname); IPAddress address = hostInfo.AddressList[0]; IPEndPoint endpoint = new IPEndPoint(address, port); Socket socket = new Socket(address.AddressFamily,SocketType.Stream, ProtocolType.Tcp); Socket.Connect(endpoint); byte[] amount = BitConverter.GetBytes(1000); byte[] name = Encoding.ASCII.GetBytes(“Joe”); intbytesSent = socket.Send(amount); bytesSent += socket.Send(name); socket.Close(); SEng 5861 - Mike Whalen

15. Tightly-Coupled Interaction What if network is unavailable? What if we want to monitor traffic? What if we want to move service to a different machine? What if it is different endian? What if client/server have different word size? What if we want to send the information to more than one machine? What if client is unavailable? SEng 5861 - Mike Whalen

16. Loosely-Coupled Interaction SEng 5861 - Mike Whalen

17. Messaging • Variable timing:unlike RPCs, sender/receiver can work at their own pace. • Throttling: because receiver buffers requests, it can control the rate at which they are consumed so that it does not get overloaded • Reliable Communication: Messaging system uses store-and-forward communication to ensure delivery of all messages. • Disconnected Operation: Can run client applications disconnected with server and then synchronize when connection is available • Mediation: Messaging system acts as a GoF Mediator between all programs that send and receive messages. If an application becomes disconnected, it must only reconnect with the messaging system, not all other apps. • Thread management: threads do not block waiting for remote server. Transfer packets of data frequently, immediately, reliably, and asynchronously using customizable formats SEng 5861 - Mike Whalen

18. Messaging Challenges • Complex Programming Model: Messaging requires that developers work with an event-driven programming model; applications must have callbacks for events from remote applications • Sequence Issues: Message channels guarantee delivery, but not when message will be delivered. This can lead to messages being delivered out of sequence • Synchronous scenarios: Many times we want application to behave synchronously. • Performance: Messaging systems add overhead to communications for each message. Structuring messages correctly is important to performance. • Vendor Lock-in: Many messaging systems rely on proprietary protocols. Even specifications such as JMS do not control the physical implementation of the solution, so different messaging systems may not connect to one another, leading to yet another integration problem. SEng 5861 - Mike Whalen

19. Enterprise Integration Patterns GregorHolpe and Bobby Woolf SEng 5861 - Mike Whalen

20. Integration Patterns • Messaging architectures have several commonalities involving message manipulation and routing. These are good candidates for patterns. • Integration Patterns can be grouped into: • Managing Channels • Message Construction • Message Routing • Message Transformation • Managing Endpoints • Systems Management SEng 5861 - Mike Whalen

21. Channel Adapter • Goal: connect application not designed to support messaging to the messaging system. • Rationale: • When possible, leave legacy systems that are designed to communicate using different means {file, database, TCP, pipes} alone. • Build a small application that mediates communication between native communication format and messaging system. SEng 5861 - Mike Whalen

22. Messaging Gateway • Goal: Encapsulate access to the messaging system from the rest of the application. • Provides: domain-specific API to the application that hides communication layer. Allows swapping of integration technology: e.g., messaging, RPC or web services • Often these are used for request/reply message pairs. • This yields two “flavors” of Messaging gateways: • Synchronous (blocking) • Asynchronous (non-blocking) • Asynchronous gateways use callback interface to contact client. delegate void OnCreditReplyEvent(intCreditScore); void OnCreditResponse(intCreditScore); void RequestCreditScore(string SSN, OnCreditReplyEventOnCreditResponse) ; SEng 5861 - Mike Whalen

23. Messaging Gateway • [Show Sequence Diagrams Here] SEng 5861 - Mike Whalen

24. Point-to-Point Channel • Channel in which each message is received exactly once by a single process. • Channel can have multiple receiver processes that can process messages in parallel. • However, each message is only delivered to one of the receivers. SEng 5861 - Mike Whalen

25. Publish-Subscribe Channel • Goal: Sender broadcasts event to all interested receivers without knowledge of receivers. • Similar to Observer/Observable, but receiver can be decoupled from sender as well through use of named channels. • Can be security risk; unauthorized receivers can gain access to information. SEng 5861 - Mike Whalen

26. Message Translator • Goal: Allow systems that use different data formats to communicate using messaging • Often used in tandem with Canonical Data Model, which creates a “standard” data format for a buisness object. • Translator is usually separate process specifically to marshal/unmarshal data from the canonical data model. • Translations may be chained; often translations occur at different levels of abstraction. • Abstract: convert record field names • Low-level: convert data representations from big-endian to little-endian. SEng 5861 - Mike Whalen

27. Content Enricher • Goal: Allow communication between systems even if source message does not have all required data items for destination. • One example: addresses • One system may just use zip codes • Another may city and state along with zip code. • Another common example: adding unique identifier to message • This is just a special case of Message Translator SEng 5861 - Mike Whalen

28. Message Router • Perform conditional routing of a message, depending on: • The contents of the message (Content Router) • The state of the set of receivers (Dynamic Router) • For load balancing • For service discovery • A provided set of recipients (Recipient List) SEng 5861 - Mike Whalen

29. Example: Widgets and Gadgets ‘R Us • Take Orders via web, phone, or fax • Process Orders involving taking inventory, shipping goods, and invoicing the customer. • Check Status: customers can check the order status • Change Address: customers can use a Web front-end to change their billing and shipping address • New Catalog: The suppliers update their catalog periodically. WGRUS needs to update its pricing and availability based on the new catalogs • Announcements: Customers can subscribe to selective announcements from WGRUS • Testing and Monitoring: The operations staff needs to be able to monitor all individual components and the message flows between them SEng 5861 - Mike Whalen

30. WGRUS IT Infrastructure SEng 5861 - Mike Whalen

31. Scenario 1: Taking Orders Taking orders is currently a tedious manual process, which increases costs. The first step to streamlining order processing is to unify taking orders. A customer can place orders over one of three channels: web site, call center, or fax. Unfortunately, each system is based on a different technology and stores incoming orders in a different data format. The call center is a packaged application, while the Web site is a custom J2EE application. The inbound fax system requires manual data entry into a small Microsoft Access database. We want to treat all orders equally, regardless of their source. For example, a customer should be able to place an order via the call center and check the order status on the web site. ? SEng 5861 - Mike Whalen

32. Orders • Billing address • Shipping address • Shipping method • Order Items • Payment Method • Splitting Preference • Special Instructions SEng 5861 - Mike Whalen

33. Aggregator • Goal: Combine the results of individual but related messages so they can be processed as a whole. • Asynchronous nature of messaging systems makes aggregation difficult • How many messages are there? Need a means of identification of message groups. • How long should we wait? Guaranteed delivery does not imply timely delivery. • Often used in tandem with Splitter + Correlation Identifier to define the set of messages to aggregate. • To handle cases in which one part is significantly delayed, often used with Message Expiration pattern. SEng 5861 - Mike Whalen

34. Aggregator • Aggregator Strategies: • Wait for All • Timeout • First Best: grab the first correlated message and ignore the other messages • Timeout with override: can timeout if “good enough” message has arrived. • External event • Common aggregation algorithms: • Select the “best” answer • Concense data • Collect data for future evaluation SEng 5861 - Mike Whalen

35. Aggregator • Aggregator has spectrum with two ends: choosing one of a set of messages and assembling message from all messages. • Assembly-style exposes several policy issues. • With “wait for completion”, how long can you wait? • When/how do you notify operator of incomplete aggregation? • With timeout, what can you do with partial set of messages? • Send out partial message or drop? • Does this constitute failure? If so, who gets notified? SEng 5861 - Mike Whalen

36. Scenario 2: Processing Orders • To fulfill an order, we need to complete the following steps: • Verify the customer’s credit standing. If the customer has outstanding bills we want to reject the new order • Verify inventory. We can’t fulfill orders for items that aren’t in stock • If the customer is in good standing and we have inventory, we want to ship the goods and bill the customer. ? SEng 5861 - Mike Whalen

37. Scenario 3: Inventory As discussed in the requirements, WGRUS has two inventory systems: one for widgets and another for gadgets. As a result, we have to route the request for inventory to the correct system. • All incoming messages with an item number starting with ‘W’ are widget orders and those starting with ‘G’ are gadget orders. Item numbers starting with letters other than ‘W’ and ‘G’ are invalid. • Assume each order has only one Item number. • The widget and gadget systems pre-date the new messaging system and do not natively understand New Order messages. • We would like to shield the rest of the system from the peculiarities of the inventory system. ? SEng 5861 - Mike Whalen

38. Splitter • Goal: Process message containing multiple elements, each of which have to be processed in a different way. • And make efficient use of network resources • Often message elements have to be re-assembled later (Aggregator) • Some means of re-assembly is necessary. • Correlation identifier can be used to identify all messages derived from original message. • Sequence identifier can be used to define position of elements within re-assembled message. SEng 5861 - Mike Whalen

39. Inventory Revisited As we learned in the requirements, WGRUS has two inventory systems: one for widgets and another for gadgets. As a result, we have to route the request for inventory to the correct system. • Assume each order has several items • All items with an item number starting with ‘W’ are widget orders and those starting with ‘G’ are gadget orders. Item numbers starting with letters other than ‘W’ and ‘G’ are invalid. • The widget and gadget systems pre-date the new messaging system and do not natively understand New Order messages. • We would like to shield the rest of the system from the peculiarities of the inventory system. ? SEng 5861 - Mike Whalen

40. Wait a second… • How did we correlate order elements? • How did we determine all messages have been received? • What aggregation algorithm did we use to combine the individual messages into one result message? • NeedContent Enricherto add Unique Order ID to messages. • Need some other means for checking completeness (What?) SEng 5861 - Mike Whalen

41. Claim Check • Goal: reduce data volume of a message sent across the system without sacrificing information content. • Mechanism: store portion of information in database for later recovery. • Message must have unique key for later recovery of information. • Could be a business key already be in the message (say, Customer ID) • Could be a unique message key (if it exists) • Could be a unique id generated by the claim check. • Data Enricher looks up claim check in database and reconstructs “full” message. • Result: processing and communication of messages can be much faster, but messages are no longer self-contained. • Can also be used to hide information. SEng 5861 - Mike Whalen

42. Content Filter • Goal: Simplify dealing with a large message when you are interested only in a few data items • Dual of Content Enricher • May remove data elements • May distill message content into simpler form • May flatten hierarchically-structured messages. • Reduces processing and network burden for filtered message. SEng 5861 - Mike Whalen

43. Message Store • Goal: Report message information and status without disturbing the loosely coupled and transient nature of messaging system. • Mechanism: store message data persistently and in a central location. • Create duplicates of messages and send them to a special channel to be collected by the message store. • This may significantly increase network traffic. • Often this pattern is used in tandem with Message Filter. SEng 5861 - Mike Whalen

44. Inventory • If you haven’t created a unique OrderID for order processing, do so now. • If you haven’t accounted for total # of items (to re-aggregate orders), do so now. SEng 5861 - Mike Whalen

45. Checking Status Fulfilling an order can take time. For example, we may be out of a certain item and the inventory system may be holding the Inventory Check message until new items arrive. A long-running business process also means that both customers and managers are likely to want to know the status of a specific order. For example, if certain items are out of stock, the customer may decide to process just those items that are in stock. Or, if they have not received goods, it is useful to tell them that the goods are on their way (including the shipping company’s tracking number) or that there is an internal delay at the warehouse. • Add support for tracking and reporting of order status within the messaging system • Describe how network traffic could be minimized by offloading portions of message. SEng 5861 - Mike Whalen

46. Checking Status SEng 5861 - Mike Whalen

47. Wait a second (again)… • We probably want to know the status of messages after each step. • If we know the status of messages, we can use this information to route them appropriately. • We are describing a kind of sophisticated message switchboard that can track the status of messages in flight. SEng 5861 - Mike Whalen

48. Process Manager • Goal: Route a message through multiple processing steps where the required steps may not be known at design time and may not be sequential • Introduces a central point of control for message routing and tracking • Hub and spoke messaging process • Two main functions: • Storing data between messages • Tracking message progress and determining next step. • Can be arbitrarily complex; • Could have its own book of patterns(!) SEng 5861 - Mike Whalen

49. Concurrency Models: Thread SEng 5861 - Mike Whalen

50. Thread Communications Mechanisms • Inter-thread communication is very fast • Several orders of magnitude faster than inter-process communication. • Threads communicate (ultimately) through shared memory. • Memory must be protected if it is accessed by multiple threads • Low-level constructs: semaphores and monitors • Semaphores: explicit “token” that allows access to some shared data • Monitor: (similar to) a Java class in which all data is private and all methods are synchronized. • Possible to use messaging as sole means for ITC • Safe! • Not as high-performance as other approaches. SEng 5861 - Mike Whalen