soa vs eda
Post on 15-Jan-2015
Embed Size (px)
DESCRIPTIONThis is a response to Jeppe Cramon's presentation on "SOA and EDA" also available on Slideshare.
- 1. SOA This is in response to Jeppe Cramons presentation on 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 theyve gotten worse No one wants to build or maintain services System performance is worse Source: Jeppe Cramon 3. All these symptoms can be experienced if you do not understand what you are doing Systems are more fragile This is because there are more moving parts and services are shared assets and when changes are needed it impacts/breaks more components Development and Maintenance costs are higher To Quote Peter H. : the second you introduce distributed, you need to leverage infrastructure that addresses network latency, fault tolerance, message serialization, unreliable networks, asynchronicity, versioning, varying loads within the application tiers etc  Takes top level talent at the moment, not something all enterprises have access to. 4. All these symptoms can be experienced if you do not understand what you are doing Your services are not being reused In SOA reuse happens the other way around, when a new consumer wants to reuse a service, there is a very low probability that the service will be reused as is. It generally requires some small changes, when you change the service, what happens is that it is the old consumer which reuses the new version of the services, unless you adopt a compatible versioning strategy where new versions of services are compatible with older consumers. 5. All these symptoms can be experienced if you do not understand what you are doing You thought SOA would solve your integration problems, but theyve gotten worse Well, following what you say, would certainly create a massive mess with events flying every where and everyone write code to correlate their content world class encapsulation, cohesion and lose coupling No one wants to build or maintain services Thats why you need a dedicated service team It also fit well the architectural paradigm of intent / consistency with SoR exposing Integration Points System performance is worse Not quite sure about that. I did some measurements on Synapse for instance and the added latency is less than 50 ms (measured around 10 ms, but just to be safe, I say 50) 6. 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 If only no one would listen to hipsters, pundits and other self proclaimed experts 7. Have our mindset changed over the last 40 years? Clearly yours has not 8. 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 doesnt rely on other services to complete its job 2. Services have explicit boundaries Services should not be too familiar with each other. Theres 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) Services ensure consistency Service Interfaces are Intentional Ok Whatever 9. 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 Because real SOA is a protocol? 10. Layered Architectures typically leaves all orchestration to a central manager (ESB) where business processes are coordinated through spaghetti code (BPEL) I am actually the (pre) author of that figure coming from BPMN. There is no ESB and no BPEL in it, this is actually a collaboration diagram, which I can be credited for pushing into BPMN BPEL is actually the only technology available today to achieve consistency at a reasonable cost. You simply have no freaking clue as to what you are talking about 11. These BPEL processes typically break all Service encapsulation as they are data and feature envious This hurts our coupling an autonomy even further BPEL is actually the only technology available today to achieve consistency at a reasonable cost. You simply have no freaking clue as to what you are talking about These past two slides is the reason why I am so mad at Jeppe. It shows that no only he has no understanding whatsoever as to what he is talking about, and he has no restraint in what he is claiming 12. What we have with classic layered SOA is a HARD COUPLED architecture You have no understanding as to what coupling means 13. 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 Reusa ble Servic e Reusa ble Servic e Reusa ble Servic e Reusa ble Servic e Reusa ble Servic e DB servi ce Another Service that is going to be reused Could please create the same picture with code duplication? Specially the stateful code that is needed for achieving consistency 14. 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 When you have 500 apps, can you please show me where the bounded contexts are? There is the theory and the practice. Each app is a bounded context? 15. 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 Yes, we all know that autonomy and lose coupling are synonymous to consistency The CAR theorem postulates that you cant have Consistency, Agility and a high degree of Relationality at the same time. You have to pick two. 16. Loose coupling Requires good encapsulation and high cohesion We of course all know that encapsulation and high cohesion drive consistency 17. Business Events help us achieve autonomy, loose coupling and encapsulation Encapsulation - because we dont 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) And so, how do you do exception handling and roll back with business events? You emit more message events? Shit happens you know. Where is the context? 18. Business Events Messages and Business Processes By publishing Events messages from our Services we can communicate with each other and also drive Business Processes Events drive business processes? You must be a candidate for the Turing Award. 19. 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. The problem with SOA discussions is that when you take simplistic examples everything works. You need to scale these examples, real world stuff, not just PowerPoint Architectures Please provide end-to-end sequence diagrams including the implementation of the services, which you will discover is best implemented by an orchestration that waits on the proper events 20. 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) The response to any business event must be coordinated, Pub/Sub does not work in the business world 21. Understanding SOA is actually pretty simple Services provides a normalized interface to the systems of record They ensure consistency of both the Queries and Command Services serve data from the Systems of Truth They make sure all SoRs are properly updated (or rolled-back) Services call Integration Points on the SoR (not services) Service interfaces are intentional, they express the intent of the consumer, how this intent is realized is under the control of the service Technically there are two software paradigms that are essential to SOA Mediation (e.g. Apache Synapse) Orchestration (e.g. Apache ODE) None of which are part of Jeppes presentation, Yes, events are also part of the picture but only to reflect changes in the SoR when these changes are not intentional The response to events is coordinated by an orchestration