Связь (Interprocess) между приложениями?

Question

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

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

Серверные и клиентские приложения могут находиться или не находиться на одном компьютере. Вся разработка ведется в .NET (C #) 2005.

Итак, мой вопрос: как лучше всего решить эту проблему общения?

MSMQ? МЫЛО? WCF? Remoting? Другой?

Answer 1

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

Очередь сообщений на сервере, вероятно, следует рассматривать как отдельную проблему, особенно с учетом необходимости удаления сообщений в очереди.

Answer 2

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

Удаленное взаимодействие, по сообщениям, очень медленное. в зависимости от целевых операционных систем, на которых вы планируете развернуть решение, у вас могут быть такие опции, как WCF et.all. Однако при принятии решения вы можете посмотреть на издержки этих протоколов.

Answer 3

Remoting

Если все разработки ведутся в .NET 2005, лучше всего использовать удаленное взаимодействие. http://en.wikipedia.org/wiki/.NET_Remoting

Answer 4

.NET Framework предоставляет несколько способов взаимодействия с объектами в разных областях приложений, каждый из которых разработан с особым уровнем знаний и гибкости. Например, рост Интернета сделал веб-сервисы XML привлекательным методом связи, поскольку веб-сервисы XML построены на общей инфраструктуре протокола HTTP и форматирования SOAP, в котором используется XML. Это общедоступные стандарты, и их можно немедленно использовать с текущей веб-инфраструктурой, не беспокоясь о дополнительных проблемах с прокси-сервером или брандмауэром.

Однако не все приложения должны быть построены с использованием какой-либо формы веб-службы XML, хотя бы только из-за проблем с производительностью, связанных с использованием сериализации SOAP через соединение HTTP.

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

Answer 5

MSMQ имеет смысл, хотя есть и соображения безопасности и развертывания. Вы можете взглянуть на служебную шину (например, NServiceBus или MassTransit), а также есть брокер служб SQL Server, который может помочь (а также может использоваться служебной шиной в качестве транспорта).

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

Я не рекомендую удаленное взаимодействие, потому что трудно поддерживать разделение проблем, и, прежде чем вы это узнаете, вы разрабатываете действительно болтливый интерфейс, не осознавая этого. Удаленные вызовы в относительном выражении стоят дорого, поэтому вы должны стараться, чтобы сообщения были достаточно грубыми. WCF будет моей рекомендацией. Не в последнюю очередь потому, что вы можете настроить его на использование транспорта HTTP и избежать большого количества проблем при развертывании и безопасности.