I am relatively new to JPOS and I have only used it to pack and unpack messages and I would like to understand how Q2 can help me. At the moment I am developing an application that receives requests from mPOS to a central server using REST and then I transform the messages to ISO8583 using JPOS which I then forward to a banks switch. I am supposed to maintain 1 persistent connection to the bank's switch. Can Q2 help me achieve this?
The question is quite broad, so it will be this answer.
I believe jPOS tutorials page is exactly what you need.
In particular the first 3:
Basic gateway: How to Implement a gateway from scratch
Customize your gateway: Adding custom code to customize it.
jPOS REST tutorial: How to implement a REST API interface in Q2.
Then you can use concepts of the previous 3 tutorials to build a transaction manager that process REST request to query the bank switch using ISO8583 interface
Related
I'm working on a project that has multiple microservices behind a API Gateway and some of them expose WebSockets API.
The WebApp needs to be able to interact with those APIs.
.
Those WebSocket API can be built with frameworks that have their own protocols, using socket.io or not etc.
The main goal of this reflexion is to be able to scale and keep flexibility on my WebSockets APIs implementation.
I thought about two solutions :
The first one is to simply proxy requests on the gateway, the webapp will have to open a websocket for each microservice, this looks like a design flaw to me.
The other one is to create a "Notifier Service" that will be a WebSocket Server and that will keep outgoing connections with users and be able to bridge the incomming messages and outgoing ones based on a custom protocol. The drawback is that i need to implement a pub/sub system (or find a solution for). I didn't dig a lot into it but it looks like a lot of work and a homemade solution, i'm not a fan of it.
I didn't find articles that give feedback after exposing such an architecture and websockets in production, i was hoping to find some here.
I agree with you that a simple proxy solution seems to be inadequate as it exposes the internal interfaces to the clients. I found two articles which I think are addressing your problem:
The API Gateway Pattern
Pattern: API Gateway / Backends for Frontends
Both talk about the issues that you have already mentioned in your question: Protocol translation is an advantage of this architecture as it decouples the external API from the protocols internally used. On the other hand, increased complexity due to having another component to be maintained is mentioned as a drawback.
The second article also suggests some existing libraries (namley Netty, Spring Reactor, NodeJS) that can be used to implement an API gateway, so you might want to spend some time evaluating these for your project.
I've been reading up on Microservice Architecture But I still can't understand the inter-microservices communication mechanism.
In many articles they said that microservices are usually exposed over a RESTful API. But when you search the internet you always see implementations based on messaging and events for the backend communications.
So I'm confused, Is REST API a standard for all the microservices or we can see microservices without a REST endpoints.
For your problem , first lets understand the ways in which one service interacts with each other , lets create two service order service and customer service :
One service need some data from other service to process its requests, eg: lets say you want to place an order , so from ui you must hit http request to order service (which can be rest , or have a api gateway in between n that use some other protocol like protobu ) to call order service for placing an order , now assume order service needs to check the validity of the customer , so order service needs to call customer service in sync — most probably you will hit rest or create a protobuf or have a persistent websocket between the service and then after response from customer service , order service move ahead.
In this case sync communication needs to be imitated , one direct approach is rest or protobuff , or imitate it through messaging
Based on one service events , you want to update other service : in this generally the preferred style is messaging bus , where one service emits out event and multiple other services have a listener on the messaging bus and react accordingly . Eg : lets say on update of customer name in customer service , you want to update the cached name of the customer in order service , in this when name is updated in customer service , it emits customer name updated event , order service subscribe to it , then react to it
Your third question is , is it possible to have service with no rest endpoint ::: yes its possible , but every service needs to be reachable . So use rest or other form is needed
Above mentioned link : microservices.io is very good , go through it once again
REST is not the only style available for microservice-to-microservice (aka inter-process communication/IPC) but it is the most popular IPC technology used by applications based on microservices-styled architecture. There are other technologies like Apache Thrift and gRPC which can serve the same purpose. Essentially all of these technologies are industry-grade implementations of RPC (Remote Procedure Call).
I highly recommend you to read this link by Microservices Expert - Chris Richardson
One of the benefits of using microservices (if not the biggest) is that it eliminates any long-term commitment to a technology stack. When developing a new service you can pick a new technology stack. Similarly, when making major changes to an existing service you can rewrite it using a new technology stack.
So, you can choose whatever communication mechanism you want as long as it does not prevent you changing the technology stack. REST over HTTP is a good choice because it hides the technologies used by the microservice to generate the responses in a request-response synchronous style. Message-based communications are also a good fit because the messages could also hide the technologies used to produce them (as long as you don't use the builtin serialization of the producer programming language), i.e. RabbitMQ or Apache Kafka.
REST is universally supported, its accepted on all languages, if all your backend services are running in the same location you may not see much different in throughput.
Anyhow its a good idea to invest and learn gRPC or Thrift as mentioned above, you could convert all your internal services to gRPC for example (supported on most languages) and do a conversion between gRPC and REST at your Universal Gateway.
There are two approaches to internal architecture, CQRS vs Plain REST calls. The eventing/messaging is an example of CQRS, where you can separate read/write side operations and all write side operations can be implements through eventing for better scalability and throughput.
tl;dr
Requesting suggestions, guidelines or examples for possibilities to extend spring-boot-adminto use methods other than HTTP requests for health moitoring of non-spring projects like MariaDB.
Full version
There is a requirement to setup a monitoring application using spring-boot-admin. Several of the clients are spring-bootapplications and are easily implemented. There are however a couple of non spring-boot projects like the database server MariaDB.
The question is therefore formulated thusly : Is it possible to extend SBA to monitor the databse status by methods other than HTTP requests. One possible approach, for example, might be to check if it is possible to connect to the application specific TCP port to verify if the db server is still running. However, other possibilities can be exploited too.
One post I found similar to my question was this :
https://github.com/codecentric/spring-boot-admin/issues/504. The key difference here though is that the provided answer still sugests a HTTP approach. The reference guide also does not suggest an alternative.
Should such a possibility exists, a brief outline of the approach or an example implementation would be most welcome.
SBA currently only supports checking health via http. But your DB should be implicitly monitored if you have an according health indicator on your business application.
It should be possible to extend the StatusUpdater#queryStatus() doing a tcp connect if it encounters an health-url beginning with tcp:// instead of http://...
And in case you accomplish that a PR is appreciated :)
How does telepat-io differ from socket-io and other socket based real time sytems ? what is the underlying technology - is it a wrapper on top of socket-io ?
Reading through their website, you can see references to socket.io...
Reading through their code, for example, their client code, you can also find references to socket.io...
It seems to me that the word wrapper doesn't fit, as they focus on creating an optimized design for meshing different technologies to create a real-time application backend... I would go with the word framework if I had to put a name on it. If you like their approach, you'll probably enjoy simplified scaling as this is one of their main concerns.
As Myst pointed out, Telepat is more of a framework, a full stack software. This framework uses socket.io for the notification part of the system: clients manipulate application resources -> API -> workers -> subscribed clients get notified of the changes through various means (Apple Push Notifications, Google Cloud Messaging and web sockets for any other client).
So in short: Telepat uses socket.io for client notifications.
I am devising a solution for investment firm wherein we want to fetch bse/nse index feeds, process them and provide realtime update to standalone client.
We've come up with following integration :
Serverside spring component which will consume index feed webservices from feed provider.
It will publish processed data on ActiveMQ topic.
Client side application will be subscribed to the topic, this way updating client with server push.
Please suggest if any better solution comes to your mind.
Facts to consider : Initially we are targeting 1000 customers(there will be only 1000 standalone clients). Every 2 seconds there need to be update to the client.
Sounds like a good approach to me. Not familiar with ActiveMQ, but if you are still at the evaluation stage you should also consider RabbitMQ if you havn't already.