I am implementing an application using Prism.
The application has a few distributed components that resides on various machines or servers. In order to communicate them, I am planning to implement messaging service using Event Aggregator. But before I start working on that I would like to have a few clarifications:
Can Event Aggregator be used on a distributed environment. If yes
than how to define the server or hub where the message would be
published or subscribed?
What is the performance impact on the applications using Event
Aggregator? I feel it is negligible but still I would like to know.
Is Event Aggregator approach is good for future expansion in an
enterprise environment?
Thanks and Regards,
Ashish Sharma
PRISM is client-side technology. So, EventAggregator as it is won't do what you need. This is mechanism to communicate between modules in a loosely-coupled way. It is not about communicating between different clients.
For what you need - I would look into HTTP Polling Duplex
http://www.devproconnections.com/article/silverlight-40/using-http-polling-duplex-in-silverlight-applications
If you use PRISM on front end - you can write your own service and subscribe/publish EventAggregator events from that service while making server calls and receiving responses back.
Related
I'm using Application Insights (AI) to instrument my code. AI uses Activity to provide some data. Activity.ParentId can be used as a per-transaction identifier, across multiple services, so that a single API call can be tracked through the code, to the database and other HTTP services etc.
MassTransit has a message ConsolidationId, to track (I believe) Sagas, but I don't think it is using the Activity.ParentId.
Am I right?
How can I get MT to use the Activity.ParentId as a ConsolidationId, both as a publisher and consumer?
MassTransit supports Open Telemetry, which can easily be configured to push data to Azure Application Insights.
There is a complete sample that shows how to configure it.
We have microservices architecture that the services are publishing (and also subscribing) events (+ a gateway api). And we want to start using MassTransit, since the system consist of services which are feeding each other with events to achieve the flow to the end..
Every services in the flow, are generally making some api calls to complete its mission for the events they received.
Looks like we should use MassTransit Courier in order to keep all the services as they are (with only adding consumers) and create a saga state machine as an orchestrator in the gateway api.
Is this a good approach? Or should we try something different?
I'm looking to implement a event-based communication pattern between my microservices and I'm looking to use Azure Service Bus to handle the messaging. In the examples I've seen so far (e.g. Microsoft's eShopOnContainers) the events are handled by a common library that handles the event subscription/publishing. I'm wondering if the common library could be replaced with Azure's Event Grid service (I realise this could generate an opinion-based answer, so please remove this question if it is deemed so)?
I like how Event Grid has retry capabilities, receives events from Azure Service Bus, push-like functionality (meaning my microservice doesn't need to poll), as well as other features, so in my mind it seems like a good fit. However, I'm fairly new to the event-based communication concept so I'm well aware I could be missing something.
If Azure Event Grid could be used to handle the events, is it possible to send the event to a Web Api endpoint? Once again, the examples I've seen so far all send the event to a Azure Function trigger, but I'm not planning on using any Azure Functions for my microservices.
If anyone had any examples they could point me to where Azure Service Bus and Event Grid were used for communication between microservices, that would be appreciated.
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'm looking at having thousands of simultaneous connections from mobile phones to the server whereby anytime a user interacts with his cell phone, the data is sent and logged by the server. Also, anytime the server has new information for that user, the server can push that information without a browser refresh. I am wondering what is more stable and how you would build this?
A good real-time framework or infrastructure will have numerous APIs that should let you connect any device, no matter the technology, to the real-time server e.g. an iOS client library for iPhone and iPad, a JavaScript client library for numerous platforms including normal and mobile web, an Android compatible Java library and so on.
An interesting idea might be to choose which ever framework or real-time service suits your needs best and then using something like PhoneGap. But, as #rt2088 says, it depends if you need the notification app to be running as a service on the phone or as a standalone application.
The choice will also depend on whether you want to install, host, maintain and manage the scaling of your own real-time services or not. If not, there are a number of services out there who you could use so you can concentrate on building your application. If you do want to manage your own infrastructure then the Comet Maturity guide could be a good start. It's a little out of date but is still probably the best reference available.
the ability to push new content the
user based on his GPS location which
is "pinged" to our server. Based on
that, we deliver local content. What
frameworks are you talking about?
There are a number of real-time frameworks available at the moment. Some are hosted services and others require installation on your own hardware. The majority of them will come with a bunch of libraries in different technologies that make it easier to get up and running with them e.g. a JavaScript library that wraps the WebSocket object and also manages fallback for web browsers that don't support WebSockets.
I've just created a Real-Time Technologies Guide in which I've listed all the real-time technologies that I could think of and provided a bunch of tags associated with each.
wouldn't a javascript client library
cover all platforms if it is a web
appilcation?
If the application is a web application then yes, a JavaScript library would be all you need for the client application. The server side libraries that you require would depend on the real-time technology you choose.
Best solution to achieve this is to use the WebSocket communication. It is bidirectional asynchronous communication. Currently every browser supports this new standard and plenty of code snippets available. You just have to google it. There are many server and client side frameworks. choose the one best suits to your requirement.
The details of the WebSocket specification is available at -
Websocket specification
Do you need notification when user uses mobile browser of handset or the mobile handset itself (performing non-browser tasks)? Based on that, the framework to record user activity can be selected.