Вопрос

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

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

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

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

МСМК?МЫЛО?ВКФ?Удаленное взаимодействие?другой?

Это было полезно?

Решение

Удаленное взаимодействие

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

Другие советы

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top