So I'm using dotnet core 3.1, and working with a client that requires access to a web service. I was wondering if it's possible to use/integrate an API Gateway architecture so that the API Gateway points to that web service (SOAP messages)? I'm researching and certainly the first choice is to use Ocelot, but I'm still on the phase of checking the feasibility. What is important to consider here is that the reason I'm using the API Gateway approach is because there will be other endpoints (other clients) that are going to indeed require it so it will be easier to use microservices with those, with all the RestAPI's and the whole all shebang...
The other thing that I'm not very well versed, is if the webservice can be containerized into a microservice to achieve the goal.
I appreciate the response.
Cheers!!!
Also if there is a better approach to this I'm more than open to "hear" about it
Here is a pic to have a better reference, just keep in mind that one of the microservices wouldn't be a Web API but a SOAP web service
CodePudding user response：
You can certainly place a gateway in front of your microservices and your SOAP service if it makes sense to do so from an architectural point of view.
If you wrap the SOAP webservice into a microservice with similar type of communication as all your other microservices or if you just call your SOAP web service directly is up to the gateway implementation. Can the gateway (your example: ocelot) make a SOAP call? Or do all backend services need to use the same "language" to communicate?
From an architectural point of view your solution makes sense and is feasible. It's all just a matter of how you "massage" the communication between the components so that the client of the gateway doesn't have to care if their requests reach a microservice or a SOAP web service.
P.S. I'm talking here about the SOAP service and "the other" microservices to highlight the different integration type between them and the gateway, but you can certainly build a microservices architecture using only SOAP. You can get the characteristics of resilience, independence and ease of deployment, scaling, composability, etc, from SOAP services just as well as from REST services (which seems the preferred way of building microservices; mostly for historical reasons since SOAP was often used as an integration option with monoliths).
CodePudding user response：
I will answer in the form of a rant.
<rant> So my advice on anything like this would be, do what works for you and your company. The "overlords" may hate me for saying you can use a soap based offering in your microservices implementation, but they don't have to support your system, you do. Do what makes sense. I have used transformations like OSB to convert SOAP to ReST, I have use translations services, you cannot look at tech decisions as yes/no. They need to be tradeoffs that make sense for you and your needs. </rant>