Разработка архитектуры для обмена данными между двумя системами

Question

Мне было поручено создать промежуточный слой, который должен обмениваться данными (через HTTP) между двумя независимыми системами (например, Receiver <=> Intermediate Layer (IL) <=> Отправитель). Получатель и Отправитель предоставляют набор API через веб-сервисы. Каждый раз, когда в системе отправителя происходит транзакция, IL должен знать об этом (я думаю о создании службы Windows, которая постоянно проверяет отправителя), обрабатывать данные, а затем доставлять их получателю. IL может временно хранить данные в базе данных SQL, пока они не будут переданы в Receiver. У меня есть следующие вопросы -

1. Можно ли использовать WCF (не очень часто) для общения с Отправителем и Получателем (оба предоставляют веб-сервисы)?
2. Как обеспечить гарантированную доставку?
3. Как обеспечить безопасность сообщений через Интернет?
4. Каковы лучшие методы для решения проблем параллелизма?
5. Каковы лучшие практики для обработки ошибок?
6. Как я могу гарантировать надежность данных (данные не изменяются по пути)
7. Как я могу обеспечить получение данных обратно Отправителю?
8. Какие ограничения мне нужно знать?

Мне нужно реализовать это на платформе MS с помощью специального решения.NET. Мне сказали не использовать промежуточное программное обеспечение, такое как BizTalk. Получатель является экземпляром SDFC, если это имеет значение.

Любые указатели очень ценятся. Спасибо.

Answer 1

Служба Windows, которая управляет обменом, звучит нормально. Да, WCF может работать с традиционными веб-сервисами.

Как обеспечить гарантированную доставку?

Для обеспечения доставки вы можете использовать TransactionScope для обработки передачи данных между Receiver <=> Intermediate Layer а также Intermediate Layer <=> Sender но я бы не стал делать их вместе.

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

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

Подумайте о сценариях:

• Как вы справляетесь с неудачными поставками?
• Что произойдет, если получатель (или отправитель) не будет доступен в течение определенного периода времени (и как долго это будет продолжаться?); например: вам нужно "эскалировать" к оператору по электронной почте?

Как обеспечить безопасность сообщений через Интернет?

HTTPS. Предполагая, что другие существующие клиенты совершают звонки в веб-службы, как они обеспечивают безопасность? (Я думаю шифрование).

Каковы лучшие методы для решения проблем параллелизма?

Хм наверное отдельный вопрос. Вы должны быть в состоянии найти информацию об этом достаточно легко. Сколько данных мы берем? какая частота? Сколько экземпляров службы Windows вы думали иметь - если одного достаточно, почему параллелизм может быть проблемой?

Каковы лучшие практики для обработки ошибок?

То же самое, что и для параллелизма, но я могу предложить несколько указателей:

• Используйте установленную структуру ведения журналов, мне очень нравятся MS EntLibs, но есть и другие (повторное использование того, что в настоящее время используется, вероятно, будет иметь больше смысла - если есть что-то).
• Помните, что выполнение выполняется без присмотра, поэтому убедитесь, что информация является полной, четкой и однозначной. Я бы соблазнился войти еще и набрать номер, как только уровень комфорта будет достигнут.
• используйте обработчик верхнего уровня, чтобы гарантировать, что ничего не потеряно; но не бойтесь глубоко заходить в приложение, где вы все равно можете получить полезный контекст (например, метаданные отправляемых / получаемых данных).

Как я могу обеспечить получение данных обратно Отправителю?

Включите его (отправка квитанции) как шаг, который является частью транзакции.

С другой стороны - взгляните на CodePlex для библиотек типов ESB, вы можете найти что-то полезное: http://www.codeplex.com/site/search?query=ESB&ac=8 Например, ESBasic, который кажется библиотекой классов который вы могли бы использовать повторно.