Hi we are thinking to implement a chat feature in our web app. (MVC 3 running on Azure) like Facebook or Gmail applications.
So the idea about this question is to have your technical architecture opinion about it.
How would you design it and which services you would use (worker role, queue, blob, Sql azure etc.).
Thanks
Instant Messaging is about asynchronous delivery of messages between multiple publishers and subscribers. This sounds like a perfect recipe for Azure Queues.
If the number of users who will use this feature is small, you can create a queue per recipient. Web-app would drop a message onto the recipient's queue and would check queue of its own user.
The positive about this approach is its simplicity The downside of this approach is the frequency of checking the queues per user and the cost associated with that.
If you have 10,000 users logged into IM and the app is checking their queue's once per second, that's 1penny per second. Which translates to ~$26k/month.
Windows Azure Service Bus provides Publish-Subscribe messaging with Topics that can be used for this scenario. You can see a Silverlight based Chat sample for this: http://servicebus.codeplex.com/SourceControl/changeset/view/9715
In addition you can see a Multi-tier app sample that shows using Service Bus Topics/Subscriptions from Web/Worker roles here: http://code.msdn.microsoft.com/windowsazure/Multi-Tier-application-6c033cad
Related
Best practice for realtime chats seems to be web sockets. But what if I want to have a moderator who can delete certain messages for all users? Especially when all other users don't have to register but only choose name and start chatting. Is this a better job for REST than web sockets? Generally and specifically in implementing using AWS/Node?
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.
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.
I am creating a system where a CEP engine looks like a good fit (I need detect time based patterns between events in a number of streams). The events detected need to be displayed to end users in a WPF application but not all users are entitled to see all events.
How is this typically handled when using a CEP engine? Do I need an additional service layer between the UI application and the CEP engine or can it be done in the CEP engine itself?
I'm not sure there's a "usual" answer to this question across all CEP engines. CEP engines are really not at all uniform in the services they provide.
You tagged this question with "streambase", so I can talk about that some. The StreamBase CEP runtime has support for user authentication when creating a client connection to a server to dequeue tuples from output streams. People typically hook this up to their local LDAP or AD server.
That said, there's no per-tuple dequeue authorization/entitlements enforcement mechanism in the StreamBase CEP runtime, at least as of the current release (7.3).
So, when StreamBase users want per-tuple entitlements enforcement, we usuallygude them toward building that in at the application layer, or use some other piece of available infrastructure. For example, rather than using native StreamBase Client connections, use an adapter to something like TIBCO EMS or IBM MQSeries and use the per topic/queue entitlements there to restrict access. Or as another example, have the StreamBase server send back a token to an authenticated user after connection, and use that token as a key for entitlements checks on the client side against LDAP using a dequeue interceptor.
Or, as you say, use your own services layer.
There's another example of "Poor Man's Entitlement Service" on the StreamBase Component Exchange. Search for "StreamBase Entitlements". This uses an in-memory or JDBC database to store users, roles, and entitlements and applies them on the server side with an efficient runtime entitlements checking mechanism. But there's no strict runtime restriction on the connections with this; it's just an example of implementing entitlements functionality with a nice UI. The clients voluntarily respect the restrictions, which is probably not what you were asking for.
Disclosure/Disclaimer: I am an employee of TIBCO Software, Inc. Opinions expressed here are my own and not TIBCO's.
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.