I have reading and developing my understanding with SOA, I found this approach of development useful. However there are couple of thing confusing me which are:
Background: we are designing online financial application, recently we are in phase of designing brain storming sessions. (audit & logging need to be done)
1 - how to make sure Secure inter process communication?
My thinking: to restrict external access to these API's by firewall. So these can only be call internally by system.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
My Thinking: For read we can use Rest and for ACID compliance transactions we can utilize soap as its provide point to point security. Or for IPC we are thinking to utilize soap as its provide audit mechanism also.
3 - What is Role of API gateway? specially is it involve in inter process communication?
I am confused on this specially with IPC. I think all request even services to services call will perform via API gateway. Kindly elaborate this in detail if I am wrong.
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
What ever I have research we can do this.
5 - What is major difference and pros and cons of SOA and Micro SOA?
My view: Msoa is extention of SOA.
Thanks in advance.
Can anyone draw a diagram or provide link of MSOA architecture diagram with API gateway.
APIGEE is primary source of my understanding, then google it specifics which move in different directions.
Security is our major concern.
1 - how to make sure Secure inter process communication?
Internally, whitelisting IP's and firewalls are probably the most secure. If these servcies scale and have dynamic IP's you may have an issue with that, in which case shared secrets can work, but ned to be put in place and respected across all services. JWT's are quite good for this (similar to SAML, but not as painful), used with an authentication microservice.
Externally - tokens, OAuth2 depending on how much pain you want to go through.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
I would use REST, SOAP is slowly becoming an antiquated standard, you can secure comms p2p by using TLS or HMAC signing.
3 - What is Role of API gateway? specially is it involve in inter process communication?
An API gateway is usually used to expose legacy APIs to the public, or to manage a large set of internal services via single amanged interface. An API gateway can also help manage tokens for clients and offer a single token for multi-service access and obfuscate the internal APIs from the external interface.
Gateways tend to also offer developer portals and some kind of self-enrollment process as well as control flows for request content (inbound and outbound).
Tyk.io is an open source API Gateway - you can see the kind of features to expect from a gateway on their home page
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
Yes, you can with an API gateway. So long as there are no inter-service dependencies.
5 - What is major difference and pros and cons of SOA and Micro SOA?
I think one is a subset of the other, SOA tends to be interconnected with a messaging structure like an ESB, but micro-SOA will bhe even more specialised and may not use an ESB.
Related
Several articles about Event Driven Architectures recommend an event broker (for example Kafka via topics) to integrate backend services and in addition RESTful interfaces for these backend services (here an example from Guido Schmutz: Building event-driven (Micro)Services with Apache Kafka, 2019, p. 19).
The RESTful interfaces provide access for GUI and external services. These GUI and external services access the RESTful services via an API Gateway. So each backend service has two interface types: a RESTful interface and a channel interface (event broker).
My question is: what are the advantages of providing RESTful API in addition / in parallel to the integration of backend services via an event broker? The reason for this question is that the event broker could provide the same capabilities (synchronous request response).
You're correct, the event broker could provide the same capability: one of the purposes of an API Gateway is to perform 'protocol translation'.
The advantage of using a RESTful API for your 'frontline' microservices depends significantly on your specific situation. Interestingly, there is nothing stopping you from providing a RESTful API via an event broker (REST is explicitly protocol agnostic). However, if by RESTful you mean over HTTP, then there may be benefits to using this protocol. As an example, if you intend for your microservices to be consumed by 'other' clients, then (despite the rise in event-driven architecture) HTTP is still objectively the most ubiquitous protocol in existence.
This is very subjective, but 'request-response' is an afterthought for event-based frameworks. If you want to follow that model, you might be best served using frameworks and technologies that are designed for it.
As you mentioned, you can of course provide a RESTful API in parallel. If this is appropriate really depends on your use-cases.
My two cents: use whatever architecture is easiest and makes the most sense for you behind your API Gateway. The Gateway provides abstraction, so if the approach you take doesn't work out, you can change with little impact.
I basically have a smaller software that is using the Microservice architecture. I am currently using RabbitMQ to do the communication between UI and services and that works great.
However I am thinking about creating a new microservice, a API Gateway, that basically takes the RabbitMQ logic from the UI and encapsulate into a service, which would become the entry point to all the other services.
The benefit is that I would encapsulate the logic that give access to the services and also being able to add authentication in the API Gateway.
However I would need to use HTTP request to interact with the API as I am moving the messaging logic from the UI. Could there be any major drawbacks in this approach?
I have being able to find examples about RabbitMQ and examples about API Gateways but never those two together, I might just be overthinking it a bit.
We have just started splitting our monolith into services. We are going to extract the authentication/authorization service out of the monolith first. Now we have a choice - API Gateway to provide authentication vs a standalone service (Like IdentityServer4 for example).
Our auth scenarios are pretty broad - web app, mobile apps, internal tools, Oauth1 that needs to be deprecated, some hand-written API authentication.
I'm leaning towards the separate service approach, because of pros:
We can deploy/scale auth and gateway separately
We can swap gateway for another one easier
Auth server is open source and written in familiar language, easier for us to undestand - customizing it is likely to be easier
But the Cons I can see:
More moving parts
We will need to integrate Auth Server and Gateway that may be hard
I wonder what are other pros/cons of both approaches that I'm missing?
We're building:
A bunch of services exposed through a web API.
A mobile app and a browser app.
Is it common practice for the apps to respond to their own conduit servers that end up talking to the API services? We're going to be setting up a reverse proxy - is it enough to directly hit our APIs (instead of setting up a conduit)? This is definitely a general architecture question.
I'm not sure what you mean by a "conduit", but a lot depends on how complete and hardened your APIs are. Do they already handle things like authentication, abuse detection/control, SSL, versioning, etc...
There are companies that specialize in providing this "middleware" of APIs (Apigee, Amazon API Gateway, Azure API Management, and many others). Your reverse proxy is a start, and is probably good enough to get going with (at least you do things like terminate your SSL, and lock down your API servers behind a firewall). If you make your API services stateless, you will probably be able to add new layers at a later date without too much pain and complexity.
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)