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

В системе 7 служб WCF, число которых возрастет до 9, каждая из которых будет размещаться в отдельной консоли приложения / службы Windows. Все они однопоточные и однопоточные. Все сервисы имеют одинаковый OperationContract: они предоставляют методы Register () и Send (). Когда клиентские сервисы хотят подключиться к другому сервису, они сначала вызывают Register (), а затем, в случае успеха,все остальное их общение с Send (). У нас есть DataContract, который имеет перечисление MessageType и свойство Content, которое может содержать другие «полезные нагрузки» DataContract. То, что служба делает с сообщением, определяется перечислением MessageType ... все идет через метод Send (), а затем перенаправляется на оператор switch ... Я подозреваю, что это необычно

Register () и Send () на самом деле являются OneWay и Async ... ВСЕ результаты сервисов возвращаются клиентским сервисам посредством CallbackContract WCF. Я считаю, что резонанс использования CallbackContracts заключается в том, чтобы облегчить используемую нами модель публикации-подписки. Проблема не в том, что все наше общение подходит для публикации-подписки, и использование CallbackContracts означает, что мы должны включить сведения об источнике в возвращаемые сообщения о результатах, чтобы клиенты могли выяснить, для чего были возвращены результаты ... опять же, у клиентов есть операторы switch для работы что делать с сообщениями, поступающими от сервисов на основе MessageType (и других встроенных деталей).

С точки зрения топологии: сервисы образуют «узлы» в графе. Каждая служба жестко закодировала список других служб, к которым она должна подключиться при запуске, и не позволит клиентским службам «регистрироваться» с ней до тех пор, пока она не выполнит все необходимые ей подключения. Например, у нас есть LoggingService и DataAccessService. DataAccessSevice является клиентом LoggingService, поэтому служба DataAccess будет пытаться зарегистрироваться в LoggingService при запуске. До тех пор, пока он не сможет успешно зарегистрироваться, служба DataAccess не позволит ни одному клиенту зарегистрироваться на нем. В результате, когда система запускается в целом, службы запускаются каскадно. Я не вижу в этом проблемы, но разве это необычно?

Чтобы усложнить задачу, одно из системных требований состоит в том, что службы или «узлы» не должны быть непосредственно зарегистрированы друг для друга, чтобы отправлять сообщения друг другу, но могут обмениваться данными через косвенные ссылки. Например, скажем, у нас есть 3 службы A, B и C, соединенные в цепочку, A может отправить сообщение Cс помощью B ... используя 2 прыжка.

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

До этого проекта я только 3 года работал над настольными приложениями winforms, лучше не знал. Я подозреваю, что этот проект слишком усложнен: я хочу подвести итог, мои вопросы:

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

2) Экспонирует ли только 2 метода в OperationContract и использует перечисление MessageType, чтобы определить, для чего предназначено сообщение / что делать с ним необычным? Разве служба WCF не должна предоставлять множество методов с конкретными целями, а клиент выбирает, какие методы он хочет вызвать?

3) делает все общение с клиентом через CallbackContracts необычным. Конечно, синхронизация или асинхронный запрос-ответ проще.

4) Является ли идея службы не позволяющей клиентским службам подключаться к ней (регистрироваться) до тех пор, пока она не подключится ко всем своим услугам (для которых она является клиентом), является ли звуковой дизайн? Я думаю, что это единственный аспект разработки, с которым я согласен, я имею в виду, что DataAccessService не должен принимать клиентов до тех пор, пока он не подключится к службе журналирования.

У меня так много вопросов WCF, больше будет в следующих темах. Заранее спасибо.