In a Service Oriented Architecture, should a service make a request while it is servicing a request

Question

In a Service Oriented Architecture, is it a violation of its general philosophy to have a service that is responding to a request put another request on the service bus to fulfill said request? Or should the original request have the dependency provided so that the service can handle the request without putting another request on the service bus?

Answer 1

In a SOA application, instead of a monolith component solving some problem, you have multiple services - each dealing with its own business concern - that now must communicate and collaborate to solve the same problem together. That means they need to know about each other and what each one is doing. That's a dependency, plain and simple.

Services are self contained components that should handle their own data and perform a business behavior. Do one thing and do it well. But because they do one thing well, if you have a complex business process to implement, at some point a service must call another service and ask it to perform some function for it, the function that that service is responsible for. Take for example business entities like customer or product. These span across almost all services because they need to "use them". But normally, only one customer service exists that "manages customers". And this is isolated. And other services need to call it if they want to do something with customers. If they don't want to call it, but do their own thing, then each one needs to know more about managing customers. That usually implies having to duplicate or share data or behaviur or knowing more about implementation details about a certain business logic. This now means tight coupling, and is a problem in general, not just in SOA.

If your services are tightly coupled, know implementation details about each other, and share or duplicate data then you are moving away from SOA "general philosophy", as you call it, and you just end up with the monolith all over again disguised as a service architecture all over the network (a wolf in sheep clothing, if you like).

So, in SOA, services need to be as decoupled as possible. But then this introduces chatter between them. Service A can't do something on its own because that's not within its business boundaries, so now it has to talk with service B. You don't have a choice. You do however have a choice on how they talk to each other.

A synchronous request/response call, for example, is worse than an asynchronous message sent over a communication bus. The dependency is weaker with a bus but it still exists. Service orchestration is more tigthly coupled than service choreography but the dependency exists. Of course this introduces other issues, like figuring what who is involved in solving a complex problem when you lack an execution flow with some central component coordinating others, and instead have services responding to events... but that's life. It's all about trade offs.

It's just like in the case of a database and normalization. You go to higher forms of normalization to eliminate data redundancies, but then you have to do more joins to get the same records, so performance decreases. So you de-normalize the database a bit to get better performance in certain situations. It's a trade off. You have to get the balance just right so you don't suffer all the problems of both extremes (very normalized vs not normalized at all). The same with SOA. You can't avoid dependencies but at the same time you need to keep them low. You need to have communication but too much chatter is bad. But duplicating data and behavior to limit chatter might be even worse.

So you need to find the right balance. You might not get it right the first time, but at some point the idea is to have isolated components that talk to each other just enough to solve problems.

Answer 2

There are two scenarios:

1- original request conveys dependencies:

• The client should know about our software implementation
• Multiple requests are made via the internet rather than LAN. -- Network failure, slow connections, ...
• User should have access to the needed services which lead to security issues.

2- original service does not convey dependencies:

• The service interface is simpler.
• Encapsulation
• Secure