Автономный клиент и сообщения на лазурь

Question

Я играю с Windows Azure и хотел бы создать облачное серверное приложение, которое получает сообщения от множества разных клиентов, таких как мобильные и настольные компьютеры. Я хотел бы построить клиент так, чтобы он работал в «автономном режиме», то есть я хотел бы, чтобы клиент создал локальную очередь сообщений, отправляемых на сервер Azure, как только они подключаются к сети.

Могу ли я сделать это с помощью механизма очередей wcf и / или azure, чтобы мне не приходилось беспокоиться о том, подключен ли клиент к сети или нет, когда я пишу код?

Answer 1

Для этого вам не нужно стоять в очереди в облаке. Чтобы клиентское приложение было включено в автономном режиме, вам необходимо поставить в очередь на клиенте. Для этого существует множество параметров, локальная база данных, XML-файлы и т. Д. Когда приложение обнаруживает доступность сети, вы можете загрузить свою очередь в Azure. И да, вы можете использовать WCF для этого.

Что касается клиентской очереди / синхронизации, вы можете взглянуть на Sync Framework .

Answer 2

Я не нашел большой потребности в очереди до сих пор. Может быть, это просто, что я не вижу это в моем представлении приложения. Также возможно, что данные, которые вы можете хранить в очереди, минимальны. Вы в основном храните короткие текстовые строки (например, идентификаторы записей), а затем вам нужно что-то делать с идентификатором, когда вы извлекаете его из очереди, например искать его, удалять, что угодно.

В моем приложении я вообще не использовал очередь, как предлагает Питер. Я написал прямо в хранилище таблиц (доступ через интерфейс REST с помощью StorageClient) с клиента. Если вы хотите взглянуть на конкретный пример, взгляните на http://www.netalerts.mobi/traffic. Как и вы, я хотел изучить Azure, поэтому создал небольшой веб-сайт.

Есть рабочий_рол, который просыпается каждые 60 секунд. Используя один поток, он извлекает любые новые данные из своего источника (скриншот веб-страницы). Новые записи хранятся непосредственно в хранилище таблиц (нет необходимости в очереди). Другой поток удаляет записи в хранилище таблиц, которые старше указанного порогового значения (нет проблем с запуском нескольких потоков в хранилище таблиц). А потом я работаю над третьим потоком, который предназначен для отправки уведомлений на портативные устройства.

Само приложение, очевидно, является web_role.