служба wcf (REST или SOAP или WEB API), которая принимает любые данные в любой структуре

Я пытаюсь создать сервис/API. В моем сценарии будет много устройств, которые следят за здоровьем. Например, монитор сердцебиения будет отслеживать сердцебиение и отправлять данные о сердцебиении. Монитор частоты пульса будет отслеживать импульсы, отправляющие данные, и аналогичным образом вы можете представить себе множество устройств, которые отправляют данные в мой сервис в своем собственном формате. Служба/API, которые я пытаюсь создать, должна иметь возможность принимать данные в любом формате и хранить их в лазурной таблице или хранилище больших двоичных объектов. Любые указания о том, как начать работу с этим дизайном, будут полезны. Я также не уверен, что лучше выбрать asp.net web api или WCF.

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


person Hari Subramaniam    schedule 18.06.2012    source источник


Ответы (3)


Некоторые вещи для размышления...

Вам по-прежнему нужно будет иметь возможность определить, какие данные есть какие, поэтому минимум, с которым вы можете справиться, - это структура с полем идентификатора или имени, а затем упомянутые вами строковые данные, которые будут содержать остальные данные любого формата. .

Таким образом, вам либо нужно, чтобы отправитель понимал этот формат и отправлял его с полем «Идентификатор» или «Имя», либо вам нужно настроить несколько методов, которые пользователи будут вызывать при отправке данных в службу, например:

.addHeartBeat()
.addPulseRate()

и т. д. ... и этот метод добавит идентификатор или имя к вашим данным. Затем вам понадобится соответствующий способ запроса этих данных обратно - с использованием той же структуры (либо пользователю нужно знать идентификатор, либо вызывать определенный метод). Вам также необходимо учитывать, какие другие критерии может использовать запрашивающий, такие как диапазоны дат, конкретный пациент и т. д., тогда все эти возможные поля фильтра должны быть отделены от данных BLOB-объектов, чтобы эффективно запрашивать их.

person Ron Savage    schedule 18.06.2012
comment
Именно то, о чем я думал. Я раскрою базовый контракт с идентификатором, именем и т. д. В основном поля, чтобы различать и идентифицировать сообщение. Больше фильтров. Остальная часть тела будет просто строкой - person Hari Subramaniam; 19.06.2012

Учитывая, что вам (в конечном итоге) нужно будет знать, что это за данные, я бы рекомендовал определять каждый из них по мере их появления, а затем обрабатывать эти данные.

Платите сейчас или платите позже.

person KevinDTimm    schedule 18.06.2012
comment
Спасибо, Кевин. Но я забыл добавить, что в сервисе, который я упомянул, нет никакой бизнес-логики. С точки зрения службы мне не нужно знать структуру данных. Все, что мне нужно сделать, это сохранить его и получить, когда его попросят. Больше ничего - person Hari Subramaniam; 18.06.2012
comment
Затем просто примите строку конечной длины / ascii / hexa и сохраните ее. - person KevinDTimm; 18.06.2012

Похоже, вы хотите создать службу загрузки файлов, которая принимает файлы любого типа и сохраняет их в большом двоичном объекте (буквально вы можете рассматривать все, что хотите отслеживать, как файл). Прежде всего, рассмотрите возможность создания SAS и разрешения клиенту напрямую загружать файлы в хранилище BLOB-объектов. Это может сэкономить некоторые усилия и повысить производительность. Если это не вариант, используйте веб-API ASP.NET. Хотя WCF также поддерживает REST, в долгосрочной перспективе рекомендуется использовать веб-API ASP.NET для создания новых служб RESTful. WCF можно использовать для создания служб SOAP, но SOAP требует, чтобы клиент отправлял конверты SOAP, а не произвольные данные.

Наилучшие пожелания,

Мин Сюй.

person Ming Xu - MSFT    schedule 19.06.2012
comment
Это означает подпись общего доступа, вы можете обратиться к msdn.microsoft.com/ en-us/library/windowsazure/hh508996.aspx для получения подробной информации. - person Ming Xu - MSFT; 21.06.2012