Now I'm using service bus topic as a backplane for signalr. But event hub is much cheaper than topics. Therefore, I want use Event Hub as a backplane for SignalR.
Can I do this now or in near feature ?
Not sure this is a real answer, but it looks like to me. I am not sure whether Event Hub is suitable for your goal, but assuming you verified and it is, then you can write your own backplane supporting it. For exercise I wrote one which was using SignalR itself (doh) as a backplane system and it was not damn difficult. You can take inspiration from the source code of the one for Service Bus and roll out your own. In particular you'll have to put most of your logic when implementing your version of a ScaleoutMessageBus-derived class.
Related
I have a DDD application and I am trying to understand where SignalR fits in my layers:
1. Presentation (Angular)
2. Distributed Services (Web API)
3. Application
4. Domain
5. Data
Basically, my SignalR hub notifies clients (Angular web app) when there is new data. For which I run a background service in a background thread that checks the database on an interval and notifies clients when there is new data.
I am inclined to think in this way:
The SignalR hub belongs to the Presentation layer. Given that my presentation project is purely client-side (Angular), I would add a new project under Presentation just for the hub.
The background service that checks the database on an interval seems appropriate for the Application layer. I would inject an INotify interface with a Notify method, which I would implement with SignalR.
Is this along the DDD principles?
DDD is all about ensuring that changes to your data only happen in a well-defined way, and where the code that executes those changes is defined in terms from a Ubiquitious Language which is well-understood throughout the whole business (not just the dev team).
DDD is silent on the mechanism used to interface with your users and other systems, other than recommending a layered architecture - which it sounds like you're already doing.
So - I wouldn't worry too much about DDD here - but it is worth considering your overall architectural approach - and in terms of layered architectural patterns, one that matches well to your approach is called Ports & Adaptors or Onion architecture. (see 1 and 2)
In this architecture, the outside of your system is considered as a set of adaptors that adapt between specific technology and your application layer. In your case your WebAPI layer is an example of an adaptor.
I would recommend creating a new SignalR adaptor - you can consider it at the same 'level' as the WebAPI adaptor (although in ports and adaptor parlance it's an 'output' adaptor, so you might diagram it on the bottom right of the onion).
In terms of the location of your background process - personally I would not consider that a part of the application layer, as it does not guide any use cases or process flows in your application. So, you could put it in your SignalR adaptor, or create a new dedicated component for it.
That said, you may find another concept from DDD useful - DomainEvents - they could remove the need for the background thread altogether. In your SignalR adaptor, include event handlers that register to handle DomainEvents, and in those handlers, propagate the information about the event via SignalR to your client side presentation layer - no need to poll the database at all! (Warning - depending on your domain event implementation, you may need to consider the risk of advertising events via SignalR before the aggregate is successfully persisted... but that's a whole 'nother topic.)
I am using the latest version of SignalR and Crank.
I want to use the standard switches to spin up multiple simulated clients. Thus: /NumClients:N and /ControllerUrl:URL. I don't understand why I have to specify the second option when I specify the number of clients, N. I see that a single "controller hub" is started, but I don't understand why. What is it's purpose? What is it controlling?
When you use multiple clients, you have to pick one client, which will be responsible for collection of information. To achieve this, Crank try to spin own mini hub to which all other clients will connect and report information (and if you don't provide ControllerUrl which has to create this internal hub will fail).
At least, this is what I understood from reading the code.
I'm implementing a Core Service "Facade" for some lazy programmers that don't want to change their coding style (me included), and wanted to implement object cache, which obviously leads to the grand question of "how long and how much should I cache".
The ideal answer is to cache forever except when data is changed.
Is there a way (via some WCF event perhaps) to implement a "listener" for data changes that could be used to remove items from their cache?
BTW, I am using .NET's native ObjectCache (MemoryCache) with a 1 minute sliding cache policy for now.
Thanks,
N
There is no such system built-into either WCF or Tridion that I know of.
You could of course roll your own, where you:
Listen for changes to the relevant data on the TCM server with Event Handlers
Have those event handlers forward the event to a central notification server
Have your WCF clients register with that notification server when they start up
Have notification server subsequently send the notifications on to the connected clients
This is essentially quite similar to how Tridion's Broker Object Cache works on the Content Delivery tier.
If you're interested in implementing such an approach, I'd suggest having a look at the Signalr project, which takes a lot of the hassle out of it.
Edit: it turns out WCF has something akin to what you're asking for called Callbacks. See this question and this blog post.
I have an ASP.NET Webform which currently calls a Java WebService. The ASP.NET Webform is created/maintained inhouse, whereas the Java WS is a package solution where we only have a WS interface to the application.
The problem is, that the Java WS is sometimes slow to respond due to system load etc. and there is nothing I can do about this. So currently at the moment there is a long delay on the ASP.NET Webform sometimes if the Java-WS is slow to respond, sometimes causing ASP.NET to reach its timeout value and throw the connection.
I need to ensure data connectivity between these two applications, which I can do by increasing the timeout value, but I cannot have the ASP.NET form wait longer than a couple of seconds.
This is where the idea of a queuing system comes into place.
My idea is, to have the ASP.NET form build the soap request and then queue it in a local queue, where then a Daemon runs and fires off the requests at the Java-WS.
Before I start building something from scratch I need a couple of pointers.
Is my solution viable ?
Are there any libraries etc already out there that I can achieve this functionality with ?
Is there a better way of achieving what i am looking for ?
You can create a WindowsService hosting a WCF service.
Your web app can them call the WCF methods of your Windows Service.
Your windows service can call the java web service methods asynchronously, using the
begin/End pattern
Your windows service can even store the answers of the java web service, and expose them through another WCF methods. For example you could have this methods in your WCF service:
1) a method that allows to call inderectly a java web service and returnd an identifier for this call
2) another method that returns the java web service call result by presenting the identifier of the call
You can even use AJAX to call the WCF methods of your Windows Service.
You have two separate problems:
Your web form needs to learn to send a request to a service and later poll to get the results of that service. You can do this by writing a simple intermediate service (in WCF, please) which would have two operations: one to call the Java service asynchronously, and the other to find out whether the async call has completed, and return the results if it has.
You may need to persistently queue up requests to the Java service. The easiest way to do this, if performance isn't a top concern (and it seems not to be), is to break the intermediate service in #1 into two: one half calls the other half using a WCF MSMQ binding. This will transparently use MSMQ as a transport, causing queued requests to stay in the queue until they are pulled out by the second half. The second half would be written as a Windows service so that it comes up on system boot and starts emptying the queue.
you could use MSMQ for queuing up the requests from you client.
Bear in mind that MSMQ doesn't handle anything for you - it's just a transport.
All it does is take MSMQ messages and deliver them to MSMQ queues.
The creation of the original messages and the processing of the delivered messages is all handled in your own code on the sending and receiving machines: the destination machine would have to have MSMQ installed plus a custom service running to pick them up and process them
Anyway there is a librays for interop with MSQM using JAVA : http://msmqjava.codeplex.com/
Another way could be you can create a queue on one of your windows box and then create a service that pick up the messages form the Queue and foreward them to the Java service
How could I implement a Comet architecture in a ASP.Net MVC?
The paid alternative
There are great comments about the question in this thread.
And based in the fact you can use handlers in a MVC app:
WebSync
will do the work : )
As long as you need to implement server push support onto your ASP.NET MVC application you will need some extra functionalities like detection of client status etc. I suggest you to try PokeIn comet ajax library which you can find sample project here
I doubt you will find something out of the box for MVC but you can always implement the client side code that handles timeouts and reconnects to an AJAX-enabled WCF service that polls for whatever event you want to be notified for. Be sure to set the timeout of the service to a higher value.
Edit 24.11.2013
Since the original question was posted SignalR was released which is a library to do just that.