1. Enterprise Integration Patterns CS3300 Fall 2015

2. Problem ● Modern systems in large enterprises are distributed across many platforms and comprised of many systems. ● How do we get them to operate together?

3. Categories ● Information Portal : You have to access more than one system to answer a particular status. The portal allows access to a single interface, that hides all the other systems. ● Data Replication : Sometimes the same data is stored across multiple systems (sales, accounting, billing). If the data changes, it needs to change everywhere. ● Shared Business Function : Same functionality is needed by multiple systems.

4. Categories ● Service Oriented Architecture: Universal services available to consumers ● Distributed Business Processes: A single transaction may span several systems. ● Business to Business Integration: Providing access outside the company (ie. Shipping company allowing customers to interact with their system for obtaining delivery dates)

5. Goal ● Loose Coupling – reduce the amount of assumptions one system has to make about another.

6. Simple Patterns (for communication) ● File Transfer : Have applications produce and consume files to read and write information ● Shared Database: Have applications store data in a common database ● Remote Method Invocation: Use an rpc mechanism (RMI, CORBA, COM, SOAP) ● Messaging : Asynchronous communication with custom formats

7. Messaging Components ● Channels : virtual pipe connecting the sender and receiver ● Messages : atomic packet of data transmitted on a channel ● Pipes and Filters : chaining processing of messages using channels ● Routing : controlling the flow of messages that have to go through many channels ● Transformations : Converting information between systems ● Endpoints : a bridge between the message system and the application

8. A Practical Implementation JMS 8

9. JNDI - Java Naming and Directory Interface 9 Mapping human-readable names to machine names Like DNS for web sites Binding links names to objects (a filename to the physical file) Context is a set of bindings. ( a file directory for example) Name Service manages these contexts.

10. Different Architectures 10

11. JMS Programming Model 11

12. CQRS-ES ● Command Query and Response Segregation ● Event Sourcing

13. Traditional System Design

14. CQRS

15. Why CQRS? ● May perform 1000s of reads for each write, thus each part can be optimized separately for transaction throughput. Each part can be scaled independently ● Commands are complex, Reads are simple. Each part can be optimized and maintained separately ● Can use two versions of the database, fully normalized for writes, consolidated for reads ● However it is not an architectural style, but a lower level concept

16. Concepts ● Bounded Context : An autonomous business component with clear boundaries – a self- contained business model ● Orders and Registrations ● Conference Management ● Payments ● Submissions and Schedule Management ● Context Map : Showing the relationships between the bounded contexts

17. More Concepts ● Command – request for the system to perform and action MakeSeatReservation ● Commands are transported on a command bus to command handlers ● Commands originate in either the UI or the Process Manager ● Event – Something that has happened in the system, often in response to a command OrderConfirmed ● Multiple subscribers may handle an event

18. More components ● ProcessManager – controls domain model ● Subscribes to events and creates commands ● No business logic, just logic to figure out what command to send

22. Event Sourcing ● Events: ● Happened in the past ● Are immutable ● May cancel or negate a previous event ● Are one way messages ● Usually have parameters for additional information ● Should describe a business intent

23. Event Sourcing ● ES then is a way of persisting your application's state by storing the history that determines the current state of the application.

24. Traditional ORM

25. Event Sourcing

26. Data Transfer Objects ● These solutions frequently use DTO. ● An object is created, forwarded to the UI. The UI makes changes and the object is returned to the model for processing ● In CQRS, a DTO is sent to the UI, but the UI issues a command