Блог

Главная - Вопросы по программированию - WCF: передача данных между двумя независимыми приложениями

WCF: передача данных между двумя независимыми приложениями

#c# #wcf

#c# #wcf

Вопрос:

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

Я хотел бы, чтобы приложение A отправляло данные в приложение B. Приложения A и B на данный момент независимы.

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

Служба S будет иметь контракты и методы для получения (получения) данных из A (вызывается A) и для передачи (установки) данных в B (вызывается B — ну, я думаю ..)

По вашему мнению, это актуально?

введите описание изображения здесь

Комментарии:

1. О боже. Нарисуйте FTW. Если A отправляется B , почему это не A так, что данные также передаются из H to B ?

2. @Otiel: я изучал UML и купил дорогую лицензию Visio, но я не могу перестать думать, что хороший эскиз на картоне убийственно эффективен: -P Все дело в том, что «A» не видит «B». Но да, я предполагаю, что действие «push towards B» также может быть запущено по инициативе «A». Тем не менее, мне все еще интересно, как B должен получать данные. Я хочу, чтобы он был пассивным и получал данные всякий раз, когда они доступны из S

Ответ №1:

В ответ на ваше «Однако мне все еще интересно, как B должен получать данные. Я хочу, чтобы он был пассивным и получал данные всякий раз, когда они доступны из S» комментарий: вам также следует внедрить сервис B , который позволит H отправлять B некоторые данные.

Вот как я вижу ваш проект макроскопическим способом:

H и B реализуют [OperationContract] called ReceiveData(Data myData) .

  • Когда A хочет отправить данные, он вызывает ReceiveData() on H .
  • Когда H получает данные и обнаруживает, что это для B , он вызывает ReceiveData() on B .

Весь смысл в том, что B это, как H хостинг службы.

Комментарии:

1. Это именно то, что мне было интересно. Это означает вторую службу. Во-первых, я рассматривал возможность встраивания обоих вариантов поведения в одну единственную службу…

2. Подумав об этом, я думаю, что ваше предложение разумно для того, что я хочу сделать… Он выполняет эффективную развязку, поскольку B предоставляет свой сервисный интерфейс для подачи «извне», следовательно, он пассивен, а не для того, чтобы вызывать S для обновления или быть «увиденным» S, что нарушило бы развязку. Спасибо, ваша помощь была ценна для меня. Кстати, я так люблю сообщество SOF, я работаю фрилансером один в своем офисе, и сообщество похоже на огромное открытое пространство, заполненное квалифицированными коллегами, готовыми помочь. Очень люблю чуваков 🙂

3. Я мог бы даже избавиться от H и хоста S непосредственно на B и вызвать его с помощью A, что упростило бы архитектуру

Ответ №2:

Если вы хотите разделить два приложения, безусловно, можно добавить службу «между ними».

Существует несколько шаблонов проектирования, которые решают проблемы такого рода. Следующая книга / сайт содержит действительно хорошую информацию: Шаблоны корпоративной интеграции.

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