Your SlideShare is downloading. ×
0
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
SOA vs EDA
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 vs EDA

2,620

Published on

This is a response to Jeppe Cramon's presentation on "SOA and EDA" also available on Slideshare.

This is a response to Jeppe Cramon's presentation on "SOA and EDA" also available on Slideshare.

Published in: Technology
8 Comments
8 Likes
Statistics
Notes
  • but of course, when someone talks about "spaghetti", he or she is exhibiting technical mastery, while I am just serving boloney. Some days you wonder how humanty ever got away from the dark ages.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Jean, enthusiasm is all you got and all you put on the table! Obviously you have minimum understanding of what you are so mad about. Technical authoring is not what you are doing here!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Jeppe, thank you for continuing the discussion, this is at level that I really enjoy. Here is my answer: http://www.slideshare.net/jdubray/soa-vs-eda-2-discussions-with-jeppe
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 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
  • David,

    feel free to join the discussion on building a realistic example that shows what's different between SOA and EDA and what is the role of 'Business Event' in a SOA (which is a perfectly valid concept of course).

    Here is the link: https://docs.google.com/document/d/1Vt96dy3HUzSPD42k6lJFGNNequPIQPuRkFNU99CmBlg/edit
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,620
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
45
Comments
8
Likes
8
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

Transcript

  • 1. SOA This is in response to Jeppe Cramon’s 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 they’ve 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 they’ve 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”  That’s 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 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) 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 can’t 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 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) 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 Jeppe’s 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

×