Encapsulating a central soap service in a microservice?

Question

I am currently developing an application (rest-backend and SPA) that requires information from people (personal data, department, superior... ). Our company has a central directory for this purpose. This provides the data via soap.

Unfortunately, I cannot say "give me the manager of x", for example, but have to call up various endpoints and evaluate them to draw conclusions. I currently have this logic built directly into the backend.

I would prefer to outsource this to a microservice including logic in order to separate the functionalities.

In future, the backend would then only ask the microservice for the superior via rest & the microservice would then ask the central service via soap.

Would this be a bad approach ("hell of microservices") or a good approach? What would the pattern be called?

Answer 1

So, it depends on the state of that SOAP service. Is it considered an immutable fact of life? Is there no more development on this service, but you also cannot find an alternative nor a different way to access that information? This is not ideal, but sometimes that's just the kind of lemon that life gives you.

If so, then your idea is one of several valid approaches (discussed further below). If not, then it would be much more effective to actually get that SOAP service to adapt to your needs. This latter avenue is not something I can answer, you'll have to take that up with the owners of that SOAP service.

So, for the remainder of this answer we've established that the SOAP service is what it is, and cannot be changed. The remaining question is how you deal with interacting with that service.
It will always contain some "funky logic" that is clunky and inefficient because (as you said) the consumer of this SOAP service has to call up various endpoints and evaluate them to draw conclusions.

You've correctly identified that you can build a little black box that does this funky logic for you, and which (seemingly neatly) just outputs a manager, which is what you want. But, I'm not convinced that this has to be a microservice.

Suppose this SOAP service did have an endpoint that spat out the manager. What would the benefit of having an additional microservice layer be? Nothing. It would be a dumb passthrough, which suggests that the microservice does nothing but act as a wrapper around the SOAP service. The knock-on effect here is that if tomorrow the SOAP service ceases to exist (or adds a better endpoint that returns the manager), what will you do?

• Will you still route things through your microservice? That's a pointless passthrough.
• Will you re-route your service to no longer use the microservice and now talk to the better endpoint? Then the microservice wasn't really expressing a meaningful responsibility, and needing to re-route it is extra development work.

It seems that in either case, the microservice is not the right call. What I would do here is develop the exact same logic that you would put into that microservice, but instead just turn it into an infrastructure (DAL) component in your actual service.

It saves you the overhead cost that microservices bring with them (provisioning cost, extra IO call, deployment complexity, ...), while still providing the same kind of encapsulation that you would've gotten from your microservice anyway. Win-win.

Answer 2

It points to a flaw in the overall design somewhere.

You expect your application to do some assembly of downstream data into view models, but if the assembly is from a single provider, and your model is reusable enough that you want to put it in its own API layer, it begs the question of why you don't add it to the downstream API instead.

Either:

1. Your model is flawed and there is a good reason the downstream API doesn't present the information that way
2. Your model is good and the downstream API is flawed
3. Your model is OK, but not generic enough to warrant being more than a ViewModel specific to your application.

Obviously there might be practical reasons that force you into this situation, but it's not ideal.

I guess we should note another case: Because you are writing a SPA you want the backend for this model to be one of many APIs. Here I would ask why you don't do the assembly on the client.

Answer 3

There is some risk with having one service call another service. If the SOAP API goes down, so does your aggregate microservice. This can lead to a chain of failures if callers send RESTful requests to your aggregate microservice. If the SOAP service is down, the aggregate microservice is down, and so is anyone calling your aggregate service. That is microservice hell. Well, that's just old school "service-oriented architecture." Your whole ecosystem is a house of cards. One card falls and the whole house collapses.

The alternative is to decouple services using message queues; something Martin Fowler called smart endpoints and dumb pipes. Message queues provide a buffer between services. The idea is that message queues are more robust and therefore fail less often, so outages in one service don't ripple across your technology ecosystem.

It might feel a little awkward at first, but sending a request for information to a message queue can help buffer your system against the SOAP service being down. Services calling the aggregate microservice would need their own message queue or web API endpoint to receive the data. Then the challenge is building the rest of the system to embrace eventual consistency. You break from the request-response model that is so easy to program for. Because of this, message queues aren't a panacea for your problems. They introduce complexity and a different set of problems you must deal with from both a software engineering perspective as well as an infrastructure perspective.

You will need to identify how you want the system to fail, how the system should respond to failure, and the desired response model. Can your system handle eventual consistency for information retrieval requests? If you introduce an asynchronous aspect to the system, what other systems would need to change to support that? I'm afraid none of us can make that judgement for you.

As for a "pattern" for one service calling many others? The closest I can think of is a Backend For Frontend, but that typically implies a user interface is the consumer, rather than other services.