I need instances of a web-app to receive notifications via WebSocket.
These notifications derive from events in backend systems; these events need to be handled in multiple ways, not only pushed to clients.
Thus a pub/sub system is ideal: events are published and n consumers handle them if they are relevant for their operations (e.g. by topic).
Given my lack of knowledge on WebSocket I'm having a hard-time understanding the overall architecture I need to put in place.
In the pub/sub world consumers subscribe to queues of messages related to "topics" of interest to them.
Can the same be done in WebSockets? (i.e.: when connecting to a WebSocket from the browser, can I specify a set of topics that the client is interested in?).
If so, is it possible to directly connect to the pub/sub system or do I need a middle-layer that consumes from the pub/sub and pushes to websockets?
I guess that the answer to the last question depends on the pub/sub used and would need some library over WebSocket.
I am familiar with RabbitMQ, but I can choose another pub/sub system as at the moment nothing is in place so I have no migration costs.
Thanks
Related
I m building a spring boot microservices, and i have some questions
I have an account microservice, a payment microservice, a product microservices... in these microservices, some requests sometimes need to use a mailing api, an sms sending api, or a push notification api..
What i have done now is create a microservice for mailing, microservice for sending sms and microservice for push notification.
What i can't seem to solve is how to make these microservices used only internally. for example, forbid users to directly call the mailing microservice.
before creating this question on stackoverflow, i dud myself, why i'll not put the code for sending sms in a library, and the same for sending emails and push notifications and add them to the microservice .. and when a microservice has need to use one of these apis i add the needed library .. for example i create a push notification library, and i add it to each microservice that needs to do a push notification ..
what is the best approach to integrate these mailing, sms and notification services into my microservice project, and respecting security by forbidding users to use them directly
I don't know what to do, can someone advise me?
Well it is not exactly clear to me what do you mean by "forbidding users to use them directly" but usually as it is pointed out #kavhakaran's answer you should put the security measures to prevent your services from abuses.
In that answer only network related part is focused as far as I can see. There should also be a second level which is about user authorization. That means you can/should have proper roles and authorization definitions for the services you would like to secure. And based on provided roles you can authorize the client to use the services.
That is how it works for cloud services usually as well. You will be provided an api-key in order to consume some cloud service and they will check if the api-key is authorized for the requested service etc.
You shouldn't worry about other micro services calling the mailing microservice or sms microservice in the application code. If you think about this concern, this will apply to any internal mircoservice. This concern can be handled in infrastructure level
Let me give you an example, you have a database running somewhere, does your microservice does anything to make sure, it is the only one talking to that database. The answer is no. At infrastructure level, whatever cloud infrastructure you are using, they allow to define security rules/ network policies, that lets you define who can talk to who. ie. rules for incoming traffic and rules for outgoing traffic
If they are public facing microservices, that is a different question. These are internal services
Some examples based on infrastructure
AWS SecurityGroups
AWS subnets
Kubernetes Network Policy
And also I want to add a point which may not be directly related to your question. The services in question seems to be very good candidates as asynchronous services. Then no services talk to them directly, sending services put the notifications in queue or kafka topic and these services consume from the topic. So now it is making sure only relevant services send it to queue or topic at network level
I would not recommend to use libraries for sending sms, emails and push notifications across your Microservices. This would lead to dependencies on source code level which I would try to avoid in a Microservices architecture if possible.
Concerning the architectural issues of your question:
From my experience it is a good idea to have separate services for handling notifications such as sms, email, etc. because with that you create an abstraction between your Microservices and the concrete notification infrastructure such as third party sms, email or push notification services.
Usually the core requirements to, for instance, sending an email will more or less be the same over time. But you might come into a situation where you want to exchange one third party service for another - for instance due to cost concerns, performance concerns or other reasons.
If you choose to directly communicate with the notification infrastructure from each Microservice that needs to send emails you would have to adapt all these Microservices when you switch from one email service to another, no matter if you use a shared library or each Microservices implements the communication with that service on its own.
But if you have a separate Email Microservice that is used by all your Microservices that need to send email notifications, you only have to change the Email Microservice itself to communicate with, for instance SendGrid instead of MailJet (just to name two third-party Email services). Your other Microservices aren't even concerned with that change.
Concerning the security aspects:
As it was already mentioned, if you choose to communicate with your notification services asynchronously the security aspects will be addressed on the infrastructure level by allowing the Microservices to access messaging infrastructure based on the authentication and access control mechanisms provided by the corresponding messaging services (be it RabbitMQ, Azure Service Bus, Kafka, AWS SQS, etc.)
Or if you choose to call your notification services via REST APIs from your Microservices you can look into token-based authentication via OpenID Connect (e.g. via Client credentials flow for machine-to-machine security).
One other thing to consider:
I would also think about other shared functionality that could be common to sms, email and push notification services such as user preferences - e.g. which kinds of notification does a user want to receive. This could also be some functionality you do not want all of your Microservices have to know about. So you could think of a notification service that is concernced with this kind of responsibility and would be responsible to delivery the notifications over the different kinds of channels (email, sms, push) based on the user prferences. Or you could have separate Microservice for user preferences which is than accessed by your sms, email and push notification Microservices. But there is no obvious answer to which option is better because this strongly depends on the use cases you have to deal with.
I wonder to know which technique and tools I should use to have the ability to send real time notifications to users. Specifically if I build a messaging system.
I can see that modern social networks can send notifications about new messages almost immediately. Even when the user 'A' from one country writes a message to the user 'B' in another country you can see that the user 'A' writes a message and you immediately see it (even if those users live in different continents).
I tried to figure out how it is possible and find any information about this but without success.
The only thing I found out is the technique when we use a Redis or RabbitMQ server with several servers which acts like publishers and subscribers. Our API servers receive new messages then they push a new message in the queue then subscribers receives the messages and if they have an open WebSocket with the recipient they push this message in the WebSocket and a client receives the message.
But it really won't work if you have a distributed project and your clients are connected to the nearest servers in the nearest data center.
The question is: what technologies/techniques/anything we should use to be able to build notifications in a distributed project?
If you develop your distributed app/system using web technologies, you can consider building what is referred to as a Progressive Web App. With PWAs you can add push notifications in a relatively easy way. You could start with a PWA approach, and then decide later on if developing a native app as well (i.e. iOS or Android) would be necessary.
There are many resources to learn and guide you in developing progressive web apps. Check the references I mentioned above, and you can do this codelab as a starting point.
When making something like a chat application using Spring Websockets, it is useful to know who all is subscribed to any given topic. For, e.g. presence data displayed in the clients.
I know that I can implement ApplicationListener and keep my own list of "connected users", but it seems like the library must already be doing this work.
What's the recommended way to get active subscription info from the library directly (and without maintaining my own list in memory or db).
You're right, you could use ApplicationContext events, but unfortunately those events deal with user sessions events and broker events - so you won't be notified when a user subscribes to a particular topic.
You could do that when using the SimpleBrokerMessageHandler, by getting the SubscriptionRegistry. But again, the SimpleMessageBroker is not for production use.
If you're using RabbitMQ, you can get that information from its REST API.
The thing is, this is very specific to the broker implementation, so I'm wondering if a feature like that makes sense in Spring Framework. Could you open a JIRA issue to start the discussion?
I am developing one distributed system application, besides than other thing, it use real time messasing to chat service and push notifications to many concurrent users notifications.
First, my actual project system is one Spring Framework Webservices with another two servers, one to real time messaging service, and another Google Cloud Messages to push notifications service.
Now, I am thinking to implement my own real time messaging and push notifications through my Spring Framework Webservices.
In here I have some doubts about application performance, Android/iOS chat and notifications services allways will be in up on Movile Services (like facebook, twitter, whatssap...). To few concurrent users less than 1000 for example, I have not doubt about it would be necessary a low features server to run system, but, if will be to many concurrent users more than 10000 running persistent websockets... Somebody can tell me the features server to run it?
For each Websocket connection Java getting up one persistent new Thread until close connection or only is getting up one new Thread by server to each Websocket request/response?
Which of the above two implementations is better?
Thank you in advance and best regards.
Neither nor;) You will want a server that does not need a new thread per connection or request, but per CPU core. And do asynchronous networking. E.g. Netty or Jetty.
Play Framework would be a perfect fit for this : full asynchronous/non blocking and very good websocket support.
Can anyone give me some suggestions of a business scenarios where I can implement Java Messaging Services (JMS). The message can be sent either by queue(point-to-point) or topic (regular/durable subscription).
I will be using JMS (enabled through TIBCO Enterprise Messaging Services).
The business scenarios must involve atleast 3 IT systems/applications.
The classic use case is that of an Enterprise Service Bus with JMS as one of the available transports. In this case any number of IT systems can request a service invocation by placing a message on a well-known queue. The service provider listening on that queue dynamically determines the reply based on the JMS message's Reply-To fields. An example of a typical service is to inquire on or update customer demographic information. For purposes of inquiry, this definitely meets your requirement of involving at least 3 IT systems since pretty much everything dealing with customers would need to request this service.
Another example with broad application is logging. I have several customers using JMS messages to capture log records from across the network and forward them to a hub of central servers. Because it is JMS, the central hub can be highly available by using redundant servers and can scale horizontally to absorb seasonal loads.
For pub/sub an example I really liked is from an insurance company. They publish events on topics that are subscribed in various call centers, internal news tickers and to business partners. During a hurricane a few years back, these events included updates on landfall predictions and then after the storm passed the updates included locations of mobile claims adjusters and other support services. Pub/Sub was a great way to coordinate this massive mobilization of personnel and communicate back to ground support back at headquarters.
A more mundane pub/sub use case with broad applicability is systems management. Instrumented applications can publish their status and interested parties can receive those notifications. If something is acting weird in Production, the administrator can dynamically enable a subscription to a stream of diagnostics. Ordinarily with no subscribers, the diagnostics are not produced. However, without any interruption in the running system, simply by subscribing, diagnostic messages from the app are produced on demand.
It's actually harder to find examples where JMS messaging should not be used. The most common contraindications are truly synchronous messaging and a requirement to process messages in strict sequence. All JMS providers I'm aware of make allowances for these requirements to varying degrees and I'm aware of many deployments of systems with these requirements. However the ideal use cases for JMS messaging are truly asynchronous or pseudo-synchronous communication and messages that are atomic (that is to say messages have no dependencies on each other or to specific broker instances).
Here are some of the scenarios where we (food retailer) use messaging:
-connection systems between remote locations, in our case POS and inventory management systems in stores, and central ERP and forecast systems: master data changes are sent as XML messages from the central ERP system to the store systems. the store systems send changes in inventory, orders and sales to the central systems. This is completely PTP based, as the master data is unique for each store.
-usage as a central messaging backbone, either directly for systems that are capable to do messaging, or via some adapter functionality for databases, files, SAP systems or HTTP. Here the messaging system builds the base for our ESB.