I would like to post brokered messages using an Azure API App to a Service Bus queue in Azure. The only
problem I have with this is that the messages must be encrypted using asymmetric encryption
(public/private key). So the idea is that the API App sends encrypted messages using the public key
to the Service Bus and later BizTalk polls the Service Bus and decrypts the messages with the private key.
Is it possible to do this?
Data encryption is not something that is built into Service Bus, but you could definitely encrypt the data on your own using a .NET library. This is really easy if your messages are below the max size (256 KB for standard messaging and 1 mb for premium messaging). Just set the message body to be the resulting encrypted message.
Related
I want to send the call offer message (sdp) over fcm to offline users. But the issue is the limit of fcm is 4096 bytes and the sdp of call offer exceeds this limit in case of video calls.
My mechanism for call offer: User creates a call offer message for remote peer, get the message and emit it to server via SocketIO. Server then checks if the remote peer is online (connected via socket).
Now if the remote user is offline I need to send the sdp to the user via push notification.
Is my approach to this problem correct? Or do I need to change the mechanism to first signal the call offer and then when the remote user get notified, I generate call offer and use my SocketIO to transmit the sdp
Or do I need to change the mechanism to first signal the call offer and then when the remote user get notified, I generate call offer and use my SocketIO to transmit the sdp
I would suggest the above approach instead. Use the push notification to "wake" the remote user (callee) and make them connect via SocketIO. Then, make the caller generate the offer SDP and send the SDP via SocketIO to the callee.
you can reduce the amount of information with some of the techniques described in https://webrtchacks.com/the-minimum-viable-sdp/
Given that the information in the SDP is somewhat time-critical a small push notification and then fetching the full SDP from your local server is the better approach.
In case of iOS, You can use VOIP notification. Also you need to increase VOIP push notification size while sending the notification from server side(e.g. java).
I have a task to implement a message broker at choice in a distributed system. Is Firebase Cloud Messaging considered one?
No. At the very least not identical in a sense, however both are related to interchanging of messages.
Firebase Cloud Messaging (FCM) is a messaging service commonly (if not always) used for Push Notifications:
A push notification is a message that is "pushed" from backend server or application to user interface, e.g. (But not limited to) mobile applications and desktop applications. It is more user experience specific which is different from Push technology, which pushes the requests between components such as server to server communication. A common scenario of push notification is the client application pops up a message in front of application's user information, along with the alert sounds. The notification could also coupled with images and hyper text link in some cases. Via interacting with the push notification it usually brings up the client applications to the front.
The service could be described as a middleware that handles the sending/delivery of the message between the App Server (usually the sender) and the client (the receiver). But for them to communicate accordingly, both the Sender and Receiver must be configured to receive the message itself (i.e. they are the ones that have to adjust to the message).
While a Message Broker is described as:
In computer programming, a message broker is an intermediary program module that translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver. Message brokers are elements in telecommunication or computer networks where software applications communicate by exchanging formally-defined messages. Message brokers are a building block of Message oriented middleware.
From the description itself, the message broker could also be considered as a middleware, but it's task is more on transforming/translating/adjusting the message so that it is would be smoothly received by the receiver.
There is also an available list of Message Broker softwares from the Wikipedia page, containing:
Apache ActiveMQ
Apache Kafka
Apache Qpid
Celery
Cloverleaf (E-Novation Lifeline)
Comverse Message Broker (Comverse Technology)
Enduro/X Transactional Message Queue (TMQ)
Financial Fusion Message Broker (Sybase - acquired by SAP in 2010)
JBoss A-MQ (aka. Fuse Message Broker - enterprise ActiveMQ - acquired by RedHat in 2012)
Gearman
HornetQ (Red Hat) (donated to Apache ActiveMQ community)
IBM Integration Bus
IBM Message Queues
JBoss Messaging (JBoss - moved to HornetQ and now it's in bug-fix mode)
JORAM
Azure Service Bus (Microsoft)
BizTalk Server (Microsoft)
NATS (MIT Open Source License, written in Go)
Open Message Queue
Oracle Message Broker (Oracle Corporation)
QDB (Apache License 2.0, supports message replay by timestamp)
RabbitMQ (Mozilla Public License, written in Erlang)
Redis An open source, in-memory data structure store, used as a database, cache and message broker.
SAP PI (SAP AG)
Solace Systems Message Router
Spread Toolkit
Tarantool, a NoSQL database, with a set of stored procedures for message queues
WSO2 Message Broker
This is an architectural question. I haven't implemented FCM yet, but as far as I understand someone needs to deploy an XMPP server in a real world scenario which provisions the inventory of the registered device tokens.
In my use case I'd like to just broadcast short messages about important update information, like "XY presenter's session at 15:00 got cancelled" and I'm not interested in the device tokens. My application is a Progressive Web App, so I would use FCM for Web.
The demos I saw so far showed a client receiving the device token, then that specific device token was picked up from the debug environment and used to send the demo message to the client - thus bypassing the need of a deployed stand-alone XMPP server, but just for demo purposes.
I'd want to avoid the use of an XMPP server, I'm not interested in dealing with the device tokens at all - if possible. Firebase's FCM/GCM server have them anyway. My plan is to pick a single topic name for that channel (the only topic what my app would use actually at this point), and push messages to the devices who listen to that topic. Is this a viable plan? I haven't found any mention of this whatsoever. Firebase knows all the tokens internally and it would make the architecture simpler if I don't have to deploy a server.
I don't know how the decomission/expiration of the device tokens would happen on Firebase's side, but that's another issue I'd have to deal with if I'll run my own XMPP server and provision tokens.
To send messages to a device (so-called downstream messages), you need to specify the server key. As its name implies, this key should only be present on a server or in some other trusted environment. So to send messages to devices you will need to run code in a trusted environment.
The server doesn't have to speak the XMPP protocol however. You can also just use HTTP to call the FCM servers. But a server will be needed, simply because sending downstream messages can only be done from a server.
For a simple example of sending device-to-device messages with this approach, see my blog post Sending notifications between Android devices with Firebase Database and Cloud Messaging. It's about Android, but the same approach of using the Firebase Database as a message queue will work across all platforms.
The tricky bit to map will be (as you already mention) the fact that topics are not available to FCM for the web yet. Last time I tested, you could call a server-side end-point to subscribe to a topic, like described in this answer: GCM: How do you subscribe a device to a topic?.
I am reading a bit about the message oriented middleware for SOA. The question which is not clear to me is difference between Instant messaging and Messaging service. Could someone help me to understand this ?
Instant messaging is communication between humans using text messages.
Messaging service is event communication between machines using messages. Those messages are typically packed with information about an event that needs to be processed somehow. There are some pattern commonly implemented by messaging services.
Publish/Subscribe - A publisher sends events to multiple subscribers that can decide what events they want to subscribe to.
Message queue - Messages are sent to a queue used to hold events in a buffer. The messages awaits a consumer to consume messages and process the events. This implements a decoupling in time between systems as well as workload balancing.
Message events typically hold data in some machine readable format, such as XML, JSON, EDIFACT etc.
Another way to look at it: Messaging services can be used to build instant messaging software. The XMPP protocol is an example of that.
I'm using a gsm modem itengo 3800. I'm currently doing a project that interface with a website to send/receive bulk sms, schedule sms and etc.
The problem is, i don't really know which should it be coded in. Should it be coded as a asp.net web application? or should it coded as a windows programs that interface with the web application for send/receiving sms?
Also receiving/sending multiple sms is important, so i requires queue or anything for buffer? Would be glad if sample programme is provided.
Because sending messages via gsm modem can be slow, what I'd do is have the ASP.NET app post the messages to a message queue, then have a windows service read the queue and send the messages. This allows the website to avoid any degradation issues when sending out lots of messages.
Here is a decent article that discusses using MSMQ: http://www.15seconds.com/issue/031202.htm
The ASP.NET app would:
MessageQueue queue = new MessageQueue(QUEUE_PATH);
Message msg = new Message("5555551212|message");
queue.Send(msg);
And the service would listen:
MessageQueue queue = new MessageQueue(QUEUE_PATH);
Message msg = queue.Receive();