Is it possible to call services hosted on the Service Bus from a Silverlight application? I tried googling around but none of the results helped.
Looking at the samples (EchoService) they are using a specific microsoft DLL to setup the authentication for the service. I cannot seem to add this DLL to my project (duh it is for the full CLR) and am not sure how to replicate its behaviour while on the client side.
Thank you for your help.
You can use it. You have to host a cross access policy file service on the service bus (a service that serves this file) An example of a service that does this is given on Clemens Vaster's blog. (just google it, it's on the msdn site) It is included with the reverse web proxy.
You have to use queued the rest APIs. Refer to the Http queue example included with the SDK.
Note that with Silverlight, you'll have to make use of the async libraries.
I've looked at the November 2008 CTP code and getting the EchoService client to work from Silverlight is highly unlikely due to the dependancy on the NetTcpRelayBinding and Silverlight's limited TCP support.
I suggest getting your Silverlight client to call a back-end service that you control and proxy the requests to the Azure platform. Not an ideal solution, but a workaround for now.
Update: The Azure Service Bus is now accessible from Silverlight using REST API calls. See http://msdn.microsoft.com/en-us/library/ff797957.aspx for more information.
Related
We have built a simple mobile app that connects to ASP.net Web-API 2.
We would like to use Microsoft client SDK for it's offline sync support.
Now that Azure Mobile Apps support custom authentication we could actually take the leap.
I want to know out if the offline sync SDK absolutely requires us to use Azure Mobile App or Azure Mobile Services.
Microsoft documentation is full of how-to guides but does not explain what happens under the hood. The best I could understand, both are just OData rest API's and swagger for documentation.
Can the Azure Mobile Client SDK work with API server created on top of ordinary ASP Web-App, outside Azure?
What is it about the Azure Mobile App that makes the magic happen?
Vladmir,
On top of OData, in order to support features like soft delete, offline sync and others, the Azure Mobile Client SDK expects the server to implement a certain protocol. So although the answer to your question:
[does the] sync SDK absolutely requires us to use Azure Mobile App?
... is no, and in theory, you could implement your own API, but I would recommend against doing so, since (among other reasons) even if you manage to implement the expected conventions and behaviors, this will become a maintenance challenge down the road if you need to upgrade the client SDK to take advantage of bug fixes and/or new features.
The good news is that with the latest release of the Azure Mobile Apps server SDK, adding mobile capabilities to an existing ASP.NET Web API application is trivial, and you should be able to enable the scenarios you're looking for simply by adding the appropriate Table controllers. So you can just enhance your existing application and not have to develop and maintain the Azure Mobile Apps specific logic yourself.
About your last question, since both, the client and the server SDK are both open source and developed in the open, you can look at what what makes the magic happen here:
https://github.com/Azure/azure-mobile-apps-net-server
https://github.com/Azure/azure-mobile-apps-net-client
I hope this helps!
The answer for your first question: Yes the SDK can be used in any Server API you have since it will be your entry point to work with Azure Mobile Services.
The Azure Mobile app creates a mobile services instance which has push notifications and SQL tables to store all messages you would like to send with the capability to customize the message as needed. Also it creates a notifications hub instance under the hood to manage notifications for all mobile platforms. Azure mobile apps provide offline capabilities through native sync services between db on your devices and the server when connectivity is present.
Feel free to ask more questions to have a full understanding on How mobile apps works.
Hope this helps.
UPDATE: DNX does not exist anymore. Please ignore this question.
Current WindowsAzure.ServiceBus (3.0.4) nuget package (http://nuget-preprod-0-v2gallery.cloudapp.net/packages/WindowsAzure.ServiceBus/) requires .NET Framework 4.5 Full Profile and it is not usable with an application build specifically to use DNX Core.
As I understand, the only way to build such application at this moment is to use REST API.
What is the recommended way to include authentication information to requests? Do we have any open source nuget to handle it or should the SAS token creation be implemented by each developer? Links to the REST API authentication samples are broken.
While the Service Bus nuget package is not open sourced, do we have any active channels to reach the developers to find out if they have any plans to support DNX Core and we should not use REST API because the library update is coming soon?
The REST URL to publish a message on Queue/Topic will be like,
http{s}://{serviceNamespace}.servicebus.windows.net/{queuePath|topicPath}/messages
The authorization SAS Token has to be part of the request header
For further read, REST Run-Time APIs
It's also possible by using the AMQP protocol. I recently used AMQP to communicate with an Azure IoTHubClient, all in a DNXCore5.0 project. I used the AMQPNetLite Library to do so, it also has Service Bus Examples!
(Reposting as my prior answer was erroneously deleted by the moderators.)
Microsoft now provides a .NET core version of this library. I am shipping a .NET Core app on Linux that calls it.
https://github.com/azure/azure-service-bus-dotnet
Announcement post:
https://blogs.msdn.microsoft.com/servicebus/2016/12/20/service-bus-net-standard-and-open-source/
is there any way to publish my API in azure mobile service API instead of using its own. I want just to know it, because assume I have a backup server in amazon and as you know I don't have access to azure sdk in there and it means technically I cant use the API anywhere outside the azure.
Azure mobile services is actually based on the .Net web api in their C# flavor and on node.js on the Javascript side. You could surely write an API using those technology and have the same behavior. You will gain the fact of being more portable, however you will lose some of the preconfigured stuff from Mobile services.
If you are using .NET, please check this to see how to build a Web api! http://www.asp.net/web-api.
If you are using Javascript, here is where you should start : https://nodejs.org/
Both tech are quite easy to learn and super powerfull, have fun! When your API is built, you could just publish them as an azure Web APP (http://azure.microsoft.com/en-us/services/app-service/web/) or an Azure API (https://azure.microsoft.com/en-us/services/app-service/api/) instead of the mobile App
Hope it helps, if you have more questions, please ask!
You can create and publish your own custom APIs in azure mobile service. You could even access in via azure mobile service sdk in client by using "InvokeApiAsync<>()" method.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn614130.aspx
If you want to access the api via fidder/httpclient than AZM SDK, pass the mobile service key in HTTP header as Name:'x-zumo-application' value:'application key from portal'
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.
I'm new to Azure Mobile Services so this may be a stupid question, but I like the look of working with the client SDK especially the offline sync framework. (I haven't seen any other offline client sync frameworks in c# that would work with Xamarin)
But unfortunately I am not building the API and instead I'm working against an existing web API which cannot be changed or moved to azure hosting.
Is this scenario possible and has anyone got this working? If so, are there any standards that my API would need to conform to (above a standard asp.net web api with correct http verbs)
Right now, the client SDK is hard coded to only make calls to <mobile service url>/table/, etc. The team is looking at options of letting the client SDK consume other endpoints, but that will be awhile yet.
You could possibly do this using an HttpHandler, and changing any outgoing HTTP request to another URL. (IE. look for /table/tablename and redirect it to your custom path) But that would get pretty messy at this point.
Its also possible to wrap the call to the API from the within the mobile services SDK as well. It will be cleaner than the above, with the drawback of adding another middle man. However if their shape is incompatible with that required by offline, it will be easier to tweak it into the expected format.