Sometimes I feel a bit like Bill Murray in Groundhog Day (except he gets paid better) since I started to propose, what I believe to be a better alternative, to pure Service Oriented Architecture as an approach to Enterprise Integration.
Let’s say the meeting starts at 10am and I arrive on time (because I am German and therefore I can ;-)) and then it goes like this:
Other: Hey Andy, I heard you are against SOA, what’s wrong with it?
Me: There’s nothing wrong with SOA there’s just a better alternative for Enterprise Integration.
Other: Better in what?
Me: Scalability for example, SOA doesn’t scale as well as it should if it’s the backbone of an Enterprise Integration strategy.
Other: What do you mean, we just need to add some more nodes to our ESB cluster, if load increases.
Me (Thinking: That’s exactly what I am talking about!): It doesn’t scale well, because it mainly relies on Request/Response which creates double the amount of network latency, it depends on the Service providing system to be up and running and it uses distributed transactions or compensation flows and hence requires undo-service implementations. And you can’t predict the amount of service calls.
Other: That’s why SOA recommends a strong Governance, so that we know who the consumers are.
Me: You are still not able to predict the exact number of calls at any given point in time, plus once your service endpoint is made public there is little enforcement for who calls it.
Other: But you can force authentication/authorisation on service calls.
Me: I don’t think authentication & authorisation should be part of a standard Integration scenario inside an Enterprise.
Others: Services don’t have to be Request/Response, a [one-way] queue can be a service endpoint too!
Me (Thinking: I wonder how a getCustomerData service call might get the customer data back then!?): How does a getCustomerData service return the customer data then?
Other: <Silence>. But it doesn’t need the service providing system to be up and running if you put the service request in a queue.
Me: But then you will have to correlate the asynchronous response to the request each time. The underlying issue with SOA is that it depends on other systems to do something, whereas the Event Driven approach doesn’t.
Other: We can just use an Orchestration Engine to support long running tasks.
Me (Thinking: Funny that those Orchestration Engines always show up in a integration discussion!?): Orchestration introduces state, and that’s no good in Enterprise Integration, because it doesn’t scale and failover easily and hence creates unnecessary overhead.
Other: You don’t want a BPEL Engine!? How do you orchestrate business processes then!?!!!
Me (Thinking: Oh no, not again!): Event Driven Architecture doesn’t need an Orchestration Engine. Whenever a business event happens, all systems that are interested in that event subscribe to it.
Other: But what about this process: <Other describes passionately a business process>…
Me (Walking to the whiteboard, throwing the first 2 markers in the bin because they don’t work): <Whiteboarding>…
Other: But what about that process: <Other or friend of other describes a more complex business process more passionately>…
Me: <Whiteboarding continues>…
Other: Ok, that was an easy example, but what about that one …
Me: <Whiteboarding continues>…
(The above “But what about/whiteboarding”-loop happens usually between 2 and 5 times) until “Other” or “Friends of Other” cannot come up with a more difficult process.
Other: I will have a think about it and come back to you with an example that cannot be solved without a BPEL Engine.
Me (Thinking: No, you won’t): Sure.
We are now already somewhere between 30 and 90 minutes into our meeting time, we have been kicked out of a meeting room at least once, because other people have booked the meeting room after us, but now…
…the meeting finally starts!
Have a great day!