Как всегда, «это зависит».Во-первых, давайте проясним терминологию.
Twisted's Perspective Broker в основном представляет собой систему, которую вы можете использовать, когда у вас есть контроль над обоими сторонами распределенного действия (как клиентской, так и серверной).Он позволяет копировать объекты с одного конца на другой и вызывать методы на удаленных объектах.Копирование включает сериализацию объекта в формат, подходящий для передачи по сети, а затем передачу его с использованием собственного протокола передачи Twisted.Это полезно, когда оба конца могут использовать Twisted, и вам не нужно взаимодействовать с не-Twisted системами.
Вообще говоря, Веб-сервисы являются клиент-серверными приложениями, которые полагаются на HTTPдля связи.Клиент использует HTTP для отправки запроса на сервер, который возвращает результат.Параметры могут быть закодированы, например, в.GET или POST-запросы или использование раздела данных в POST-запросе для отправки, например, документа в формате XML, описывающего выполняемое действие.
REST - это архитектурная идея, котораявсе ресурсы и операции с ресурсами, предоставляемыми системой, должны быть непосредственно адресуемыми.Проще говоря, это означает, что URI, используемый для доступа к ресурсу или манипулирования им, включает в себя имя ресурса и выполняемую над ним операцию.REST может быть и обычно реализуется как веб-служба с использованием HTTP.
SOAP - это протокол для обмена сообщениями.Он состоит из двух частей: на выбор нескольких транспортных методов и единого формата сообщений на основе XML.Например, транспортным методом может быть HTTP, что делает SOAP кандидатом на внедрение Wed Services.Формат сообщения определяет все подробности о запрошенном действии и результате действия.
JMS - это стандарт API для систем обмена сообщениями на основе Java.Он определяет некоторую семантику для сообщений (например, один-к-одному или один-ко-многим) и включает в себя методы адресации, создания сообщений, заполнения их параметрами и данными, их отправки, а также приема и декодирования.API гарантирует, что вы можете теоретически изменить базовую реализацию системы обмена сообщениями без необходимости переписывать весь ваш код.Однако реализация системы сообщений не должна быть совместимой с протоколом с другой системой обмена сообщениями с поддержкой JMS.Таким образом, наличие одной системы JMS автоматически не означает, что вы можете обмениваться сообщениями с другой системой JMS.Вам, вероятно, нужно создать какой-то мостовой сервис, чтобы это работало, что будет серьезной проблемой, особенно когда речь идет об адресации.
AMQP пытается улучшить ситуацию, определивпроводной протокол, которому должны подчиняться системы обмена сообщениями.Это означает, что системы обмена сообщениями от разных поставщиков могут обмениваться сообщениями.
Наконец, SOA - это концепция архитектуры, в которой приложения разбиваются на повторно используемые службы.Эти службы затем объединяются («оркестрируются») для реализации приложения.Каждый раз, когда создается новое приложение, существует вероятность повторного использования существующих сервисов.SOA также требует нетехнической поддержки, поэтому повторное использование действительно происходит, а сервисы разработаны достаточно общими.Кроме того, SOA - это один из способов начать упаковку функциональных возможностей в унаследованных системах в осмысленное целое, которое затем можно расширять и развивать, используя более современные методы.SOA может быть реализован с использованием различных технологий, таких как веб-службы, системы обмена сообщениями или Enterprise Service Bus.
Вы обдумывали компромисс между одним соединением на запрос и сохранением соединения открытым для нескольких запросов. Это зависит от доступных ресурсов, схемы обмена сообщениями и размера ваших данных. Если поток входящих сообщений постоянно один и тот же, то было бы неплохо оставить соединения открытыми, поскольку их количество не сильно изменится. С другой стороны, если есть пакеты сообщений от нескольких систем, то может быть полезно высвободить ресурсы и не позволять соединениям задерживаться слишком долго. Кроме того, если по одному соединению передается много данных, накладные расходы на открытие и закрытие соединения невелики по сравнению с общей длиной транзакции. С другой стороны, если вы передаете много очень маленьких сообщений, то сохранение соединения может оказаться полезным. Сравнительный анализ с вашими конкретными параметрами - единственный способ убедиться в этом.
AMQP действительно может заменить специфичный для Twisted протокол. Это позволит взаимодействовать с не-витой системой.
Надеюсь, это окажется полезным для вас. Если вам все еще интересно что-то (а я думаю, что это так, поскольку это такая большая область), то я бы предложил разделить вещи на более мелкие вопросы и разместить их по отдельности. Тогда ответы могут быть более точными.