Как я создал бы асинхронную систему уведомления с помощью УСПОКОИТЕЛЬНЫХ веб-сервисов?

Question

Как я создал бы асинхронную систему уведомления с помощью УСПОКОИТЕЛЬНЫХ веб-сервисов?

Когда я не в состоянии использовать C# 3.0, я использую функцию помощника, которая переводит ряд параметров в словарь.

public IDictionary<KeyType, ValueType> Dict<KeyType, ValueType>(params object[] data)
{
    Dictionary<KeyType, ValueType> dict = new Dictionary<KeyType, ValueType>((data == null ? 0 :data.Length / 2));
    if (data == null || data.Length == 0) return dict;

    KeyType key = default(KeyType);
    ValueType value = default(ValueType);

    for (int i = 0; i < data.Length; i++)
    {
        if (i % 2 == 0)
            key = (KeyType) data[i];
        else
        {
            value = (ValueType) data[i];
            dict.Add(key, value);
        }
    }

    return dict;
}

Использование как это:

IDictionary<string,object> myDictionary = Dict<string,object>(
    "foo",    50,
    "bar",    100
);

18

events rest messaging notifications message

задан John Saunders 11 May 2014 в 16:46

3 ответа

Другие вопросы по тегам:

events rest messaging notifications message

Похожие вопросы:

score 8 · Answer 1

Я могу придумать четыре подхода:

Подход Twitter: вы регистрируете клиента, а затем он периодически перезванивает с помощью GET для получения любых уведомлений.
Клиент описывает, как он хочет получать уведомление, когда он делает запрос на регистрацию. Таким образом, вы можете разрешить JMS для тех, кто может с этим справиться, и вернуться к электронной почте или тому подобному для тех, кто не может.
Возьмите URL-адрес во время запроса регистрации и отправьте POST обратно каждому клиенту индивидуально, когда у вас есть уведомление. Вряд ли Pub / Sub, но эффект был бы похож. Конечно ты' Я предполагаю, что Клиент прослушивал эти уведомления и реализовал свой Клиент в соответствии с вашими спецификациями.
Купите IBM WebSphere MQ (MQSeries). Лучший продукт IBM. Не REST, но он отлично подходит для такой многоплатформенной интеграции.

score 3 · Answer 2

В ответ на запрос RESTful вы можете указать индивидуальный URL-адрес RESTful, который клиент может отслеживать на предмет обновлений.

То есть у вас есть один URL-адрес (например, /Signup.htm), который принимает информацию о клиенте (идентификатор, если необходимо, идентификатор объекта для мониторинга) и возвращает настроенный URL-адрес (/ Monitor / XYZPDQ), где XYZPDQ - это UUID, созданный для этого конкретного клиента. Клиент может опрашивать этот настроенный URL через некоторый интервал, и он получит уведомление, если обновление произойдет.

Если вас не волнует, кто является клиентом (и не

score 4 · Answer 3

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

Опрос: Забейте список необходимых ресурсов с помощью запросов GET.
Обновления событий потоковой передачи: Предоставляет ресурс монитора. Сервер поддерживает соединение. При возникновении событий сервер передает поток описаний событий с использованием составного типа содержимого или кодирования передачи по частям.