Хороший протокол для межсвязи приложений FAST? [закрытый]

Демон будет быстрее в ближайшей перспективе по цене гибкости. Преимущество демона состоит в том, что можно просто передать ответ обратно в компактной форме в случае как поток двоичных целочисленных значений. Это будет то, с такой скоростью, как можно добраться.

Если количество запросов увеличивается вне определенного предела, можно использовать DNS с Циклическим алгоритмом для распределения нагрузки по нескольким машинам, таким образом, нет никакого преимущества использования сервера HTTP.

Основной недостаток состоит в том, что Вы не можете отладить этот интерфейс легко (с большинством Протоколов Интернета, Вы можете просто telnet к порту, на котором сервер слушает и выполняет несколько команд и видит результат). Кроме того, если необходимо изменить интерфейс по какой-либо причине, необходимо будет изменить каждый клиент также. Это ухудшается, когда необходимо использовать этот сервис где-то в другом месте, например, в мэшапе.

Таким образом, если Вы хотите быть более гибкими, используйте протокол как HTTP и JSON как формат данных. Это не столь компактно как двоичный файл, таким образом, времена ответа будут хуже. Насколько хуже зависит от размера данных. Если можно соответствовать, JSON закодировал ответ в стандартный пакет IP (приблизительно 1 500 байтов), Вы, вероятно, не заметите различия.

Я знаю, что это - своего рода общий ответ, но Вы говорите различие миллисекунд между демоном и веб-сервисом.

После этих слов пойдите с более гибкой архитектурой. Хороший дизайн Явно перевесит технологию, которую Вы используете для выполнения его.

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

При разработке сервера демона что взаимодействует через интерфейс, Вы обеспечиваете клиенты для соединения? Вы реализовали бы сокеты или RMI или что-то еще. Не очень гибкое и легкое для поддержания решения когда дело доходит до масштабируемости.

Пойдите с веб-сервисом.

Если производительность является так большой частью проблемы, я подозреваю, что хорошо необходимо пойти для некоторой сетки кластерного решения. Я записал обзор библиотек сетки/кластера Java некоторое время назад, который является полезным фоном.

Если бы коммерческое программное обеспечение является опцией, я предложил бы смотреть на GigaSpaces (или некоторое бесплатное программное обеспечение реализация JavaSpaces если не). Это позволит Вам делать:

• Упорядочивание FIFO сообщений, если это важно для Вас (хотя это идет со стоимостью производительности);
• Подмиллисекунда транзакционные обновления сетки;
• Это идет с реализацией JMS, основанной на вершине, если Вы хотите использовать ту организацию очередей API; и
• Сообщения определяются классом, таким образом, Вы можете просто чтение-запись соответствующие операции.

GigaSpaces (и любая серьезная технология сеток/кластеризации действительно) масштабируется хорошо. Намного лучше, чем чистое решение для организации очередей, с которым любой не масштабируется, публикуют - подписываются (так как все слушатели получают сообщение; не обычно, что Вы хотите) или ответ запроса (где необходимо удостовериться, очередь не заблокирована плохим сообщением).

Вы не упоминаете, какую технологию сервер использует. Если это - Java затем, Вы в порядке. Если не это становится немного более интересным. Если это так, можно хотеть считать здание чем-то с помощью Google Protocol Buffers, который является высокоэффективным двоичным форматом обмена и поддерживается на Java, C++ и возможно других платформах.

Лично я не огромный поклонник веб-сервисов, потому что они не являются транзакционными (в том смысле, что они не могут зарегистрироваться в распределенных транзакциях). Это может или не может быть проблемой для Вас. Плюс совместимость между различными технологическими стеками (например, Java и .NET) все еще проблематично в лучшем случае

Вы могли следовать за лидером и пользователем HTTP для этого :)

Например, в их Ajax API, они используют его в сочетании с JSON (или это плоскость JavaScript?)

Вот пример.

Для следующего запроса:

http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=hello%20world&langpair=en%7Cit&callback=foo&context=bar

Полный вывод - это:

HTTP/1.0 200 OK
Date: Thu, 12 Feb 2009 05:13:31 GMT
Content-Length: 97
Content-Type: text/javascript; charset=utf-8
Expires: Thu, 12 Feb 2009 05:13:31 GMT
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
X-Backend-Content-Length: 16
X-Embedded-Status: 200
X-Content-Type-Options: nosniff
Server: GFE/2.0

{"responseData": {"translatedText":"ciao mondo"}, "responseDetails": null, "responseStatus": 200}

Конечно, тест очень прост, но использование Java реализация не могло быть более простым это это.

Конечно, это зависит от Ваших потребностей проекта, безопасности, управление доступом и т.д., но при помощи HTTP можно передать на супер протестированном протоколе.

если Вы не попробовали несколько методов, Вы, привычка знает, какой "лучше". Лучший способ состоит в том, чтобы моделировать каждого и попробовать его! это не должно даже делать всего, что Вы хотите сделать, просто внести свою лепту (как возврат предопределенных данных), и можно загрузиться, тестируют его для наблюдения, какой лучше.

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