Встраивание стороннего веб-сервиса в дизайн вашего приложения - PullRequest
0 голосов
/ 19 марта 2009

У нас есть процесс, который запускается несколько раз в день (через службу Windows) и также может быть вызван в любое время пользователем уровня администратора (через веб-приложение). Этот процесс получает набор данных от партнера через веб-сервис, затем мы объединяем эти данные с нашей локальной копией в нашем собственном формате. Достаточно просто.

Мой вопрос: как это вписывается в наш дизайн приложения? У нас есть довольно простой уровень Application Services, который взаимодействует с нашим хранилищем для работы с объектами нашего домена. Домен невежественен.

Как этот процесс должен вписываться в эту архитектуру? Мы,

  1. Поставить больше всего логики в сервисе приложений? Просто вызовите стороннюю службу, возьмите наши локальные объекты из репозитория и сделайте наши обновления / добавления / и т.д. и сохраните их обратно в репозиторий. По сути, просто относитесь к сторонней службе как к другому хранилищу.
  2. Попросите службу приложения взять наши локальные данные (пока не беспокойтесь об объеме данных), передайте их в службу уровня домена, которая будет вызывать стороннюю службу, объедините данные по мере необходимости, а затем верните новый набор данных в Служба приложения для фиксации в хранилище?
  3. Другие опции ...

1 Ответ

0 голосов
/ 19 марта 2009

Я бы попробовал "шаблон" шлюза удаленного обслуживания.
Ниже приведена ссылка на концепцию, будь то с точки зрения Ajax, а не процесса. Однако, когда я впервые увидел концепцию, представленную в мире архитектуры и дизайна Dobbs в 2006 году, этот пример больше походил на ваш случай - сервис, вызывающий время от времени.

http://blog.ontheheap.com/2008/06/06/ajax-and-the-service-gateway-pattern/

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

У меня был успех с этим подходом.

...