soa vs eda 2 (discussions with jeppe)

Download SOA vs EDA 2 (discussions with Jeppe)

Post on 22-Apr-2015




0 download

Embed Size (px)




  • 1. SOA vs EDA 2
  • 2. Let me also correct something Obviously you have done a lot of research and you have a lot of practical experience, So I apologize, your presentation on SOA vs ESA did not reflect that, and I tend to get very upset at that style of communication, which brings absolutely nothing to the discussion and in general has a negative impact on our industry creating a large amount of FUD
  • 3. Protocol vs Semantics Jeppe, I truly believe that you are mixing two levels: Protocol Semantics of the interaction When you say Systems are more fragile. [] Suddenly the stability of the service I call is dependent upon the stability of the combined list of services What is the alternative? Aggregating the 3 services into a single back-end? Use reliable protocols? Dependencies and unreliable systems is a given, there is no way around it The semantics of an interaction are very well defined (e.g. the ebXML BP specification I was one of the editors of that spec): Notification Business Transaction Request/Confirm Request/Response Query/Response Information distribution Data Exchange These semantics cannot be dependent on the protocol which maybe reliable or not depending on what/how you want to achieve, you can choose a protocol more or less aligned with the semantics of the interactions, but you cannot pick interactions as you please
  • 4. Protocol vs Semantics (contd) That is, we want to eliminate temporal coupling between services by limiting ourselves to asynchronous communication between services. Really, you can eliminate temporal coupling because you decide so? How can someone writes this kind principle? When you go rent a car, there is no temporal coupling? You can wait until a car becomes available, right?
  • 5. Service Coupling loose coupling is what gives us business agility, which is the key business driver for SOA Again the CAR theorem states that you cant have Consistency, Agility and a high degree of Relationality at the same time, you can only have two, that has nothing to do with temporal coupling, or even a protocol Service interaction semantics sit above the protocol Note: I am the author of the CAR theorem, thats why Google didnt return anything
  • 6. Service Coupling Clemens explained that Autonomous Services is what allows the Azure teams to scale development or operations But when do you have a choice? When there is no consistency and no relationality? Yes, there are some services like that, typically the Azure Service Bus / AWS services are autonomous, I agree, but thats not true in the enterprise Is a service defined by the protocol you use, or by a higher definition? SOA is not plumbing, there are a lot of interesting things to do with the plumbing but we should call it plumbing not SOA
  • 7. Service Coupling NetFlix has MANY autonomous services/bounded contexts which seems to work for them. The same seems to be the case for Azure (and as far I can tell also for Amazon) I am not sure it is helpful to take examples that are non relational That being said, even Netflix had to fight the chattymess of their APIs SOA was designed for the enterprise not for the Cloud, we might call them Services I can find hundreds of examples of truly autonomous services, it does not help me designing the one that cant be made autonomous
  • 8. The Key to SOA (I could not say it more clearly) is to make the Systems of Record autonomous from one another That is what is very desirable, but this cannot happen by itself, it is the services above the integration points that make it happen So, if you call an integration point a service you might come to the conclusion that services are indeed autonomous, but integration points are not services by a very large margin
  • 9. ESB It takes too long to get anything across the ESB service team, lets just bypass them for now, build what we need and deal with it later The truth is that you can expose an integration points in minutes (e.g. Apache Synapse) Once you do that you create a stable interface that prevents changes in the SoR to propagate to that interface An ESB is the only way (I know of) to decouple SoR from consumers, if you dont do that youll keep pushing changes to the SoR to all consumers (or break them) This is simply not true
  • 10. ESB (contd) but most companies seem to end up in a broker/hub-spoke ESB model There are ESBs and ESBs. For me an ESB is Apache Synapse, and I use Synapse to manage the interface to a service not its implementation You cannot be successful at SOA if you do not decouple the service interface from its implementation (see Reuse section) An ESB greatly simplify security, monitoring, scalability
  • 11. ESB (contd) A bunch of webservices that communicate with other services using Request/Response over HTTP (i.e. RPC) and an ESB put in the middle as a broker. This is not the view, the ESB is a mediation layer essential to manage (and decouple) the service interface from its implementation You cannot handle changes in the SoRs without mediation, I dont know any other way There is Compatible interfaces, but it seems too complex for people to deal with it In any case, you would still need to deal with horizontal aspects of a service (security, monitoring)
  • 12. ESB A centralized ESBs is one of the problem I see many organizations battle with. In theory it should work (with clustering and all), but Ive so many times heard the ESB is slow again, none of our services work, who forgot to increase the DB quota for the ESB log tables, etc. Again, Jeppe, you assume that because someone does this, everyone does it or should do it We cant make this kind of reasoning Many ESBs are fully decentralized (thanks to SCA for which I was also an early author of the spec) But the Hipsters didnt like SCA either We have to stop this wolf pack mentality that drives our industry in the worst possible direction Nowadays, ESBs like Apache Synapse make it easy to deploy mediation capability wherever you need it An ESB is only centralized because you say so
  • 13. About a bunch of Services that is the key to a successful SOA, you can never aim at building the right service, your SOA must start as just a bunch of services It is through reuse (as I define it later) that services evolve towards becoming enterprise services It is under the pressure of the changes requested by new consumers that eventually the service becomes an enterprise service It is not via governance, years of analysis, it is slowly but surely, one version after another
  • 14. Reuse Some dont see reuse as the end goal. Udi Dahan made a comment sometime ago stating For me, Ive given up on the whole reuse thing. I think its a crock. Has been since OO Once again, if you dont understand that in SOA reuse happens the other way around, you can never reuse anything In SOA new consumers rarely can consume a service as-is, they need changes to be made to the SoR and hence to the interface would need to change. The most sensible way to deal with this situation Keep the existing interface stable Change the service implementation Expose a new service interface When you do that, it is old consumers who reuse the new version of the service, not the other way around
  • 15. The fallacy of Reuse Udi Reuse may make sense in the most tightly coupled pieces of code you have, but not very much anywhere else. Yep, and lets try to not reuse customer change of Address service Guys come on Intentional interfaces are reusable Interfaces which aim at driving a consistent outcome are reusable Yes, not all interfaces are reusable