I am planning a 3-tiered architecture in which I need to track changes to domain objects on the client (a Windows Store app) then send those changes back to the server (an Azure worker-role). I just found out about WCF Data Services which I can run on the client and integrate with Entity Framework Code First on the server. It looks okay but I'm wondering what other tools may also be available.
Are there any alternatives to WCF Data Services for tracking changes in client then sending them to server? If available, I'd like a solution that doesn't require generated DTO classes but instead sends the deltas alone.
Have you considered using rest services?
Im not an AZURE user, but use elsewhere.
Azure rest services docu
Related
We are looking into authentication/authorization for a mobile reporting app which consumes hourly/weekly/monthly commercially sensitive data over the wire using an internally provided RESTful web api service running within the MS Azure Cloud.
Stormpath's offering looks interesting in that it would appear to provide some heavy lift for the whole identity management side of things, registering users, authenticating them and producing JWT tokens etc.
Otherwise, we would have to write our own auth/user db tables and have some management overhead with that.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Can anyone, especially those familiar with Stormath elaborate on this?
I get that all the user registration, password recovery use cases would go via Stormpath and I am guessing that JWT token creation for a user would require our existing service to talk to Stormpath. Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
I guess I am sensitive to performance issues regarding the whole token validation step within the Web API pipeline.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet.
Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
One thing which looks attractive about something like Stormpath is the possibility of two factor authentication.
Without having gone into too much analysis yet, a typical use case scenario would be that sign up or password recovery would mandate that an SMS was sent to the user's preregistered smartphone number to provide a stronger validation that they (and their pre-registered device) are the intended user of the mobile app which uses the RESTful service to consume and visualise commercially sensitive data.
I work at Stormpath on our .NET libraries.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Stormpath acts as your API's source of access tokens. When someone using your mobile app needs to log in, your backend API uses Stormpath to generate an access token, or the mobile app talks directly to Stormpath to get an access token. Either way, the token allows the mobile app to make authenticated requests to your API.
Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
The access token (JWT) integrity can be validated locally using middleware like UseJwtBearerAuthentication in ASP.NET. For more security, you can send the token up to Stormpath to be verified even further (for revocation and other cases), but the tradeoff is a network request. Local (fast) validation is the default, but we give you both options.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet. Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
Using either Stormpath or Azure AD B2C is "outsourcing" your identity and user management. The benefit is that you don't have to write it yourself, and you can focus on writing your business and app logic instead. The features are similar, although Stormpath is a little more flexible on the mobile side of things (since you aren't forced to use a browser/page-based flow).
I am developing a mobile application using Telerik Platform. The services consumed by the app are ASP.NET Web API RESTful services which are hosted on Azure. I'd like to build some resilience into the app by adding a service bus and have been looking at Azure Service Bus which seems to be what I'm looking for.
It's fairly new to me and I have a few questions.
Can Azure Service Bus be used for RESTful services that return data or are they fire-and-forget only?
For simple RESTful services is Azure Service Bus the way to go or Azure Storage Queue? When would you use one vs the other?
When would I use a Queue vs Topic / Subscription?
ASB is about messaging. You use messaging for communication between parts of your system/services. RESTful services can leverage ASB by translating a request into a message to perform some work. Emphasis on converting the intent into a message, to instruct about work that needs to take place, not execute the work itself.
ASB or ASQ is your choice. This is where you need to choose between the features and capabilities each provides. There's a good MSFT comparison documentation on it.
Queues vs Topics/Subscriptions - if you need to send a message to a single destination (a command) then queue is simpler. In case a message needs to be broadcasted to multiple receivers (events), topics/subscriptions are your friends.
We're building a real-time Web-based monitoring system for .NET applications (ASP.NET and Windows executable). Those applications can start a long-running operations and statistics are displayed in real-time on Web page.
For ASP.NET ones we found SignalR a perfect solution: Long running operation (even caused by simple WebForms form postback) periodically call JS client-side functions via SignalR RPC to update monitoring page. But we hit 2 caveats:
In ASP.NET we need to monitor several different apps located in several different virtual directories. How do we push data from those different apps onto a single HTML monitoring page?
Another app is a .NET Windows console executable that runs periodically on a schedule. How do we push its run-time statistics to the same monitoring HTML page? One thing comes to mind - have EXE store temporary statistics in a DB and have client pull same data from the DB, but we'd like to avoid polling. Another - periodically at a given intervals the EXE would call the WebApp, passing the data - and WebApp would pass it to client via the same SignalR call. But are there better ways?
One architecture that I've used is a small monitoring collection service, with embedded monitoring clients in every monitored application, Asp.net, Windows desktop app, console app, Windows service, or otherwise.
The collection service is always running. A webapp then connects directly to the service and requests the state of all monitored apps.
Monitored apps run some small embedded client that feeds back application-specific metrics to the monitoring service. The client can either provide data on events or timers, or the monitoring service an ask for it on a timer itself.
With this, we have a unified monitoring architecture - everything that runs just talks to the monitoring service to send updates, and the health viewer clients just ask the service for data using a unified protocol.
It's basically the Application Server pattern applied to monitoring, and takes a couple cues from the design of SNMP.
Very new to SignalR, didn't realize it has multiple clients for different platforms. We will go with SignalR .NET client for all the apps - they will all talk to main SignalR hub directly invoking server-side methods, which in turn update monitoring page.
I am having trouble wrapping my head around whether or not my scenario will require scale out. I have a process in a windows service that pushes messages to a hub hosted in a web app via the signalr .net client. These are user specific messages and are distributed using the Client(connectionid) approach. If this is deployed in a web farm scenario will I need to use a scale out approach? When a user joins I am storing that connection info in the database. I store the url of the webserver and connectionid so I can target that when I publish messages from the windows service.
I would use this if it is an option.
http://www.asp.net/signalr/overview/performance/scaleout-with-windows-azure-service-bus
Louis
I have the following scenario in my project :-
The client makes use of ASP.NET Web API to make HTTP service requests. The Web API sits on top of a couple of WCF services, which in-turn handle all the business logic. The client subscribes to a particular type of event with the Web API. Whenever the Web API receives notifications from the internal WCF services about the occurrence of the event, the Web API in-turn needs to notify (push events to) all the subscribed clients about the events along with their details.
I want to understand the different options which are available for
sending asynchronous callbacks from an ASP.NET Web API to the
clients.(Currently we are working on a prototype for which the
client is a C# Windows Forms application. Later we might opt for
ASP.NET MVC4 web application.).
I also want to know which option would be ideal to send asynchronous
notifications back to the client when the data that accompanies the notification is of large sizes. In our scenario, the notification data that is sent back from the service may be of large sizes (~ in the range of 5KB - 50 MB).
In our scenario which I described above, can SignalR be used for notifying the c# client from Web API, as and when the Web API receives the callback from the internal WCF services?
Note :- The Web API is currently hosted in a Windows Service and the client is a .NET Windows Forms application.
Any pointers to such code samples or directions on how this can be achieved would be extremely helpful.
Cheers
SignalR is a good fit for the scenario you're describing, so I'd suggest using it for the notifications (especially since you want to start with a WinForms application and later switch to browser clients - with SignalR, you'll be able to connect to the same server-side code).
However, I'd also suggest keeping the notication messages lightweight, so instead of sending the data to the client with them, I'd send a token the client can retrieve the data with from WebAPI (SignalR isn't really ideal for large file transfers).