Your SlideShare is downloading. ×
SOA and Event Driven Architecture (SOA 2.0)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

SOA and Event Driven Architecture (SOA 2.0)

47,916

Published on

A historic view on software integration on how we've failed with our current approach to SOA (also know as SOA 1.0). …

A historic view on software integration on how we've failed with our current approach to SOA (also know as SOA 1.0).
We look at the problem, what to do about them using Events and the changes that we need to apply to our design philosophy and architecture to really obtain loose coupling, reuse (or replaceability) and a reactive system.

Published in: Technology, Business
2 Comments
64 Likes
Statistics
Notes
  • I've created a follow up slide set that attempts to both respond to what I believe are misinterpretations (perhaps due to lack of a sound track) and also sum of the different opinions on SOA that sparked from the online discussion that followed. I've added links to discussions, articles, videos and blog posts that I hope can be of benefit to all interested in SOA & EDA - http://www.slideshare.net/jeppec/soa-eda-follow-up
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Jeppe,

    here are my comments: http://www.slideshare.net/jdubray/soa-vs-eda

    In particular, you have no understanding whatsoever of what Orchestration or Mediation are and their role in a Service Oriented Architecture. The affectations contained in this presentation are not just plain wrong, they are disastrous.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
47,916
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
670
Comments
2
Likes
64
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Tilbudafd.design afd. bederomingrediens listenfor hveringrediensStof for at hørehvordanbehovet for ingredienskanopfyldes (2 rullerrynkebånd)Lager afd. hvornårkan vi levere Pris for henteprisenogsamt give kundeoplysninger (hvadsker der nårregnskaberlukket)?(næsteudvidelseer at de løberrundt med heleingrediens listen - aggregeret service) n+1 problem (pga. genbrugpålavesteniveau)Hvadsker der når design department ellerregnskabafd. erlukket?Design afd. - de kendermaterialer (opskriften) - Daniel (+ Schwan)Stofafd. -  kenderstofstørrelser (2 rulleraf 2m) - IngeborgLager afd. - har vi detpå lager  plus varebestilling -  EstherRegnskabafd. - kenderkunderogderes status + må de fåpåregningellerskal de selvafhente (plus kenderpriserogkunderabatter)      her er en person der kenderkunder + status       en person der kenderpriser - Mads + KrestenSalgafd.- Arnold + Gudrun
  • IntroducererkoordinatorHackel
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • The layersaretechnically de-coupled but not in terms of data or temporal.Eachlayer has a technical integration layerthatmakes it harder to understand the correlationsDebugging is made more difficultSingle point of failureLatency is high and scalability is low
  • Deterikkeantalletaf lag i en lasagne der bestemmerhvor god den er
  • Vigtige Pointer:LangtmindrekommunikationRobust overforsygdom/nedbrud. Vi kansælgeselvom vi ikkefår de senestepriserfraIngeborgellerhvis Design afd. Ersyg
  • The beginning of a Change of mind set
  • Human workflow – data double entry (entering data from a screen in Purchase to a screen in Inventory) due to lack of system integration
  • Before we had Human workflow – data double entry (entering data from a screen in Purchase to a screen in Inventory) due to lack of system integrationDatabase integration is fragile and changes to one applications database will often render all integrations with this database invalid, meaning that a lot of application integrations need to be changed.
  • Batch jobs, files, CORBA, COM/DCOM, RMI….To some EAI is the same a Service Oriented Architecture (SOA), but in reality it’s more or less just a more sophisticated variant of database integration. All integration happens in hindsight and you’re prone to many of the same problems as with database integration.
  • WebService focus was on technical integrations and not business integrations (i.e. automatic service “enablement” of CICS transactions) – methods needed to be called in the right order, transactional boundaries blurry, compensations needed to be handled, etc.To some WebServices, in the form of SOAP over HTTP, is the same a Service Oriented Architecture (SOA). WebServices (SOAP over HTTP) is just one way to integrate applications, but adding XML and SOAP to the equation doesn’t automatically turn integration into SOA.
  • In reality the ESB just hides all the old problematic point-to-point integrations. Introducing an ESB can make sense, but it will never make a poorly designed SOA solution better. If applied without changing your approach to SOA it will just be a very expensive cable cover
  • When the various logical models (subdomain models) need to grow to facilitate new features, each conflicting concern will impede the progress of each other.The bigger the change, e.g. adding a new logical model (such as forecasting), the worse the effect will become.
  • Combining subdomains into one big domain model increases complexity as everything tends to be connected to and depend on everything else
  • Scale up vertically
  • E.g. In an Inventory system a Product (often referred to as an Item) can have manydifferentnamesdepending on where in the lifecycletheyare:An Ordered Item not yetavailable for Sale is called a Back-Ordered ItemAn Item beingReceived is called a Goods ReceivedAn Item in stock is called a Stock ItemAn Item beingconsumed is called a Item Leaving InventoryAn Item beingspoiled or broken is called a Wasted Inventory Item
  • BPO
  • Note that we’re trying to describe the kind of problems you run into and the consequences it has for you
  • Do you want a Slow Module A to determine the performance of Module B/C?Do you want an error/downtime in Module A to affect the availability of Module B?
  • Locking and scaling: If it takes 200 ms to carry out an operation thatusesscaling, the system canmaximum handle 5 concurrentusersFragility: 2,3,4 .... PhaseCommit - 2PC theoryconcludes by saying "and thisdoes not work in reality" - in case of error (eg. Due to timeout while waiting for a resourcecommitphase) youalways end up with having to decidewhattwo do "Halt and manual recovery" or guesswhether it wasgood or bad!Therearebesides timeouts a big problem. At worst, timeouts last very long!
  • Autonomy and organizational unity around the subdomain. Independence on SLA
  • Don’t distribute unless absolutely necessary
  • Data – hard technical and functional couplingService – loose technical but hard functional couplingUI – loose technical and loose functional coupling
  • MimeType definition: http://en.wikipedia.org/wiki/MIME
  • Use Cases: There is a difference between the static and the dynamic part of a systemThe dynamic part contributes to provides an precisecontext
  • Commands and Events areimmutablewhere as Documents are mutable
  • When the Customer has decided what to buy and filled out the Order form the Sales Service will publish an Order Accepted Event to a Message Channel (typically a Topic).This allows interested parties to react to the event begin their part of the Sales fulfillment process
  • Transcript

    • 1. Jeppe Cramon – Partner in TigerTeam ApS AANUG Conference September 2013 SOA & EDA
    • 2. There are problems with SOA • Systems are more fragile • Development and Maintenance costs are higher • Your services are not being reused • You thought SOA would solve your integration problems, but they’ve gotten worse • No one wants to build or maintain services • System performance is worse
    • 3. If you have arrived at the realization that SOA is a pain and costs too much without enabling business agility or reducing your costs, you are not the only one. You will have to change your approach to achieve the benefits of SOA
    • 4. Let’s take a trip back in time
    • 5. And look at how we could do business
    • 6. Sales Department Old style SOA Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
    • 7. This is slow
    • 8. We are not selling enough!!
    • 9. Sales Department Old style SOA II Design Department Customer Department Finance Department Fabric Department Create Sales Order
    • 10. We need to speed things up! Hackel walks between desks? Way too slow.
    • 11. We need to speed things up! He needs to call So we make sure that he can Actually, call a lot!
    • 12. We need to speed things up! But Hackel still have to wait Even if we get creative
    • 13. We need to speed things up! Something needs to be done!!
    • 14. Speed up even more! Lets get an automatic switchboard!
    • 15. Speed up even more! New technology, same problem Even if we get creative again
    • 16. Or do things Async So Hackel can send request to Ingeborg and Kresten which can respond to Hackel when they’ve got an answer But even that doesn’t scale well, there’s still only one Ingeborg and Kresten
    • 17. Speed up even more! So Kresten and Ingeborg adds more staff
    • 18. Scalability is expensive Sales Department Design Department Customer Department Finance Department Fabric Department Coordinator Hackel
    • 19. Same problem different technology Data Storage Data Storage Data Storage Finance Service Data Service Design Service Hackel Coordinator Service Hackel Coordinator Service Sales Order Service Sales Order Service Customer Customer Fabric Service Customer Service Data Storage Client Process Service layer Activity Service layer Data Service layer
    • 20. Resemble much?
    • 21. Now back to the story… • Scaling up Sales requires scaling up other departments relatively much • People cost money and why have 9 Finance people for every 10 sales people just to answer questions about pricing • There’s got to be a better way to handle this • And there is 
    • 22. Sales Department Event Driven SOA and local caching Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
    • 23. Scalability is cheaper Sales Department Design Department Customer Department Finance Department Fabric Department
    • 24. This is just the beginning
    • 25. Have our mindset changed over the last 40 years?
    • 26. Paper work, file cabinets and manual workflows Inventory ShippingPurchase Manual workflow Manual workflow
    • 27. Next step was automating paper forms (aka. The birth of CRUD) Inventory ShippingPurchase Manual workflow Manual workflow
    • 28. Database integration Inventory ShippingPurchase Database Integration Database Integration
    • 29. Enterprise Application Integration (EAI) Inventory ShippingPurchase Application Integration Application Integration
    • 30. WebServices to the Rescue? SOA Web of Mess Inventory Purchase ShippingPortal
    • 31. ESB’s the the Rescue? SOA Web of Mess hidden by ESB Inventory Purchase ShippingPortal ESB
    • 32. ESB Reality SOA Web of Mess hidden by ESB Inventory Purchase ShippingPortal ESB
    • 33. I’ve got a cheaper solution
    • 34. To be clear – none of the examples represent in my opinion SOA The 4 tenets of SOA 1. Services are autonomous – Encapsulation & Cohesion at a bigger scale. – A service is autonomous if it doesn’t rely on other services to complete its job 2. Services have explicit boundaries – Services should not be too familiar with each other. There’s a clear boundary to where the responsibilities of each services starts and ends – Boundaries are made unclear when a service rely on other services to complete its job 3. Services share contract and schema, not class or type – Encapsulation improved. We need not worry about how things are implemented (languages or platform dependent information) 4. Service interaction is controlled by a policy – Controls under which rules/form of technical communication between services take place (e.g. using encryption incl. algorithm and keys)
    • 35. What we’ve seen is just old EAI wine on new SOA bottles
    • 36. WebServices and in general synchronous integration has nothing to do with real SOA Some call this pattern for SOA 1.0 to distinguish them selves from the old approach and the mess it causes
    • 37. Layered Architectures typically leaves all orchestration to a central manager (ESB) where business processes are coordinated through spaghetti code (BPEL)
    • 38. These BPEL processes typically break all Service encapsulation as they are data and feature envious This hurts our coupling an autonomy even further
    • 39. What we have with classic layered SOA is a HARD COUPLED architecture
    • 40. But what about reuse? • Layered SOA has typically been recommended because it increases reuse (at the expense of a hard coupled architecture) • The thesis is that the more we reuse, the faster we will be done • But the thesis rest on the false assumption that writing code is the most expensive part of a project – Not all code takes the same amount of time to write. Some code is very trivial while other code is very hard to write • The real money and time consumers on any project are: – Figuring out what the customer needs – The time it takes for the customer to figure what they really needed and the resulting rework – Meetings – Integration work, databases, webservices – Fix bugs – Debugging – Deployment – Test – Ship Faile d? Yes No The more dependencies we have, the worse and more expensive this becomes
    • 41. Service reuse multiplies our direct and especially indirect dependencies which creates high coupling My new Service that wants to reuse other services Service that is going to be reused Reusable Service Reusable Service Reusable Service Reusable Service Reusable Service DB service Another Service that is going to be reused
    • 42. Can’t we just avoid Services and make one big application?
    • 43. Retail Domain Invoicing Subdomain Product Catalog Subdomain Shipping Subdomain Sales (Order) Subdomain Inventory Subdomain Pricing
    • 44. One Domain Model to Rule them All? Combining subdomains into one big domain model increases complexity as everything tends to be connected to and depend on everything else
    • 45. One big model to capture it ALL? …. ….. ….. …. ….. ….. …. ….. ….. …. ….. …..
    • 46. Result: Our queries get messy
    • 47. ONE MODEL TO RULE THEM ALL ONE MODEL TO FIND THEM ONE MODEL TO BRING THEM ALL AND IN THE DARKNESS BIND THEM
    • 48. The database determines our scalability
    • 49. And databases often scale poorly To solve the performance problems for a few, you have to upgrade it all
    • 50. Do not design for locality and try to distribute Design for distribution, take advantage of locality
    • 51. Alternatively we can use Read replicas Master Slave SlaveSlaveSlave You’re now eventually consistent
    • 52. Or introduce caching… What’s your synchronization mechanism? ?
    • 53. Many perspectives on data Customer Retail System Pricing Inventory Sales Product Unit Price Promotional Price Promotion End Date Stock Keeping Unit (SKU) Quantity On Hand (QOH) Location Code Price Quantity Ordered Name The lifecycle for Data is VERY important! Forecasting?
    • 54. Smaller models & clear data ownership Sales Product ProductID Name Description Quantity Ordered … Sales Inventory Product ProductID SKU QOH Location Code … Inventory Pricing Product ProductID Unit Price Promotional Price … Pricing DDD: Bounded Context SOA: Service Retail System Shared Entity identity
    • 55. A Service is • A technical authority for a specific business capability – very similar to Bounded Contexts • The owner of all the data and business rules that support this business capability – like Bounded Contexts A Service is equivalent to a Bounded Context
    • 56. What a Service is NOT • A service with only functionality (and no data) is a FUNCTION – Like: check if order is valid • A service that only has data is a DATABASE – Like: CRUD of an entity This is typically seen in a lot of layered SOA usages where a function calls a function that calls a function that calls a database
    • 57. Autonomy becomes the next (and biggest) problem Can you rely on others?
    • 58. Data Layer Service Orchestration issue Data Access Layer Service Layer Interface/Display Layer System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema Local transaction spanning all modules Service
    • 59. Service autonomy Service B Service C Service A System X Service A System Y Service B Service C System X Slow/unreliable network Different SLA Slow system
    • 60. Orchestration using synchronous communication and local transactions System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema B:Service() call C:Service() call B:DAL() call A:Service() commit() Service
    • 61. Solution for when going distributed? Can’t we just distributed transactions? (XA / 2 phase commit)
    • 62. Distributed Transactions…. Oh my Sales system Sale Delivery system Deliveries Customer/CR M system Custome r SAP Bookkeeping Complete Purchase Transaction Coordinator Transactional Resource Prepare Phase Commit Phase 2 Phase Commit
    • 63. What’s wrong with distributed transactions? • Transactions lock resources while active • Services are autonomous – Can’t be expected to finish within a certain time interval • Locking keeps other transactions from completing their job • Locking doesn’t scale • X Phase Commit is fragile by design
    • 64. Orchestration using synchronous communication and without distributed transactions System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema ServiceB:Service() call C:Service() call B:DAL() call A:Service() if (A:Call-Failed?) call A:Service() if (A:Call-Failed?) Wait-A-While() call A:Service() if (A:Call-Failed-Due-To-IO?) Save-We-Need-Check-If-Call-A-Succeded-After-All AND We-Need-To-Retry call C:Service and call B:DAL AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (A:Call-Went-Well) commit()
    • 65. More of the same clearly can’t be The answer…
    • 66. The more autonomous services are, the more loosely coupled they are. Loose coupling is what drives business agility – which is why we wanted SOA in the first place
    • 67. Loose coupling Requires good encapsulation and high cohesion
    • 68. Return of the SILOS!!!!
    • 69. We need SMALL SILOS that SHARE very LITTLE with each other Sales Pricing InventoryShipping ✕ ✕ ✕
    • 70. A silo/bounded-context contains all parts related to it DB Schema Domain Services Application Services Domain Model Aggregates , Entities, Value Objects, Events Integration Endpoints (REST, SOAP, Pub/Sub) User Interface Silo
    • 71. A silos parts are not limited to deployment at a single location Subdomain User Interface Integration Endpoints (REST, SOAP, Pub/Sub) Domain Services Application Services Aggregates, Entities, Value Objects, Events DB Schema Units of individual deployment
    • 72. What should our silos share? Bounded Context
    • 73. Degrees of coupling UI UI Service ServiceData Data Events Events
    • 74. Composite UI’s Retail System Sales Pricing Inventory Web/Application tier Background server tier Storage tier Composite UI UI Layered ApplicationData Access Layer Readmodel Writemodel ✕ ✕
    • 75. Composite UI - example Context: Book ISBN-10 0-321-12521-5
    • 76. Composite UI - HTML #DIV – BookReviews #DIV – BookImage #DIV – BookTitleAndAuthor #DIV – BookPricing #DIV – BookAvailability #DIV - Header #DIV - Body
    • 77. Composite UI
    • 78. The Service owns it UI in all Contexts and for all Composite UI’s Not just for HTML clients
    • 79. Invoice Composite UI example InvoiceHeader Order:ShippingI nfo Invoice: NextInvoiceNumb er Invoice: Data and Due date Order: RelationInformation Order:Item- Qty Product:Ite m Product: Description Order: Item-Unit-Price Order: Item- Total- Price Order:Total Billing:Balance All Services participate at the UI level for each individual Item in the Order
    • 80. When won’t a Composite UI make sense? For certain types of UI’s that built outside of the organization, e.g. customer specific netbank apps and mobile banking application we need to provide a synchronous integration API that will allow them to integrate with the business domains without having to coordinate with the business domains UI team. The integration API could be built using both a REST* and/or a SOAP approach. * It’s not such a distant thought to see a Composite UI part as a REST resource with a rendering matching the requested MimeType encoding.
    • 81. That covers data presentation What about transactions?
    • 82. Next Step – Event Driven Architecture
    • 83. Why Events?
    • 84. Synchronous calls lowers our Fault tolerance • When servers crashes • When databases are down • When deadlocks occurs in the database – Do you retry? With synchronous RPC style Services interaction we loose business data. There’s no automatic retry and idempotence is often an after though.
    • 85. Cure: Messaging • Message based communication is asynchronous and thereby breaks temporal coupling • Messages can be exchanged between services over a message channel • The Message channel is responsible for delivering the message(s) to the relevant parties (consumers). If something goes wrong, the message will be put back on the Message channel (rollback) and will be resent later
    • 86. Let’s make the implicit explicit! Old wisdom seems to have been forgotten. Let’s introduce: Business Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: – CustomerBilled – ParcelShipped – CustomerCreated – ReviewCreated – CommentAdded – CommentDeleted
    • 87. Business Events as Messages A Business Event can be transferred over a message channel, such as a Queue or a Topic, in many different formats
    • 88. Business Event as XML Message <OrderWasAccepted> <CustomerId>50D1F244-ABBC-4EC7-BDCA-E4934C124A89</CustomerId> <OrderId>C199322A-01F1-4E56-918E-7A63529F8FA3</OrderId> <ShippingAddress> ... </ShippingAddress> <BillingAddress> ... </BillingAddress> <Items> <Item ProductId="4CD22C4B-600C-4477-B5BF-48ABDEE4DA61" Amount="100" AmountUnit="Pieces" UnitPrice="100,10" UnitCurrency="EUR"/> <Item ProductId="56E6BD19-660C-464A-9120-100DAF579855" Amount="10" AmountUnit="Litres" UnitPrice="56,95" UnitCurrency="CHF"/> </Items> </OrderWasAccepted>
    • 89. Business Event as JSON Message { EventType: "OrderWasAccepted", CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3", ShippingAddress: { ... } BillingAddress: { ... } Items: [ { ProductId: "4CD22C4B-600C-4477-B5BF-48ABDEE4DA61", Amount: "100", AmountUnit: "Pieces", UnitPrice: "100,10", UnitCurrency: "EUR" }, { ProductId: "56E6BD19-660C-464A-9120-100DAF579855", Amount: "10", AmountUnit: "Litres", UnitPrice: "56,95", UnitCurrency: "CHF" } ] }
    • 90. Business Events help us achieve autonomy, loose coupling and encapsulation • Encapsulation - because we don’t need to supply our services internal data (because no on else needs to know them) – internal data will only be accessible through the Services UI (which takes part in a Composite UI) • Events only need to explain WHAT happened and what it relates to and very few business data (which are typically only needed for replication scenarios)
    • 91. Business Events Messages and Business Processes By publishing Events messages from our Services we can communicate with each other and also drive Business Processes
    • 92. Using Business Events to drive Business Processes Sales Service Shipping Invoicing Sales Customers MessageChannel The sales fulfillment processing can now begin… Online Ordering System Web Shop (Composite UI) Invoicing Service Shipping Service Order Accepted Event
    • 93. Business Events example Sales Service Order Accepted Invoicing Service Retail System Order Accepted Customer Billed MessageChannel We use the Order Accepted event message published from the Sales Service to drive the Invoicing/Billing of the customer. The billing part of the process also use Business Events, in this case Customer Billed Event, to indicate that its part of the process is completed. Because we use asynchronous messaging we can still accept orders in the sales service even though the invoicing services is down. The Order Accepted event message will remain in the Message Channel until the Invoicing Service is ready to process it.
    • 94. Introducing Choreographed Processes Sales Service Order Accepted Invoicing Service Shipping Process Manager (Saga) Shipping Service Retail System Message Channel Order Accepted Order Accepted Customer Billed Customer Billed Order Ready for Shipment Order Ready for Shipment Works as a Finite State Machine (WorkFlow) handling the life cycle of Shipping and thereby forms a very central new Aggregate in the System
    • 95. Process Managers • Process Managers are essential to the coordination and monitoring of long running processes. • They work as a Finite State Machines (WorkFlow) which handling the life cycle of Process (e.g. Shipping an Order) and thereby forms a very central new Aggregate in the System • They can include manual steps/person intervention • Sometimes these Process Managers belong naturally within a specific Subdomain and other times they are truly and thing by themselves and often form new Subdomains that way Companies often derive their competitive advantages from their Processes. A Process Manager allows you coordinate Business Processes on the basis of Events
    • 96. Domain Events can also be used for data replication This is typically used for read-mostly master data that is needed in many business- domains. This way we avoid having to call a synchronous services to query the latest value(s)
    • 97. Event Based Replication Subdomain Z Repositor y Repositor y Z Data Subdomain Y Service Repository Message channel Event Receiver Y Event Receiver and Local Cache Builder Y Data Cache Y Events Y Events
    • 98. Questions? @jeppec on Twitterjeppe@tigerteam.dk @TigerTeamDK on Twitterhttp://tigerteam.dk

    ×