Я взял на себя ответственность за разработку системы, которую я изначально не проектировал, и не могу спросить оригинальных дизайнеров, почему были приняты определенные дизайнерские решения, поскольку их больше нет. Я - младший разработчик по вопросам дизайна, поэтому не знал, о чем спрашивать, когда начинал проект, который был моим первым проектом SOA / WCF.
В системе имеется 7 служб WCF, число которых возрастет до 9, каждая из которых будет размещаться в отдельной консольной службе app / windows. Все они единичные и однопоточные. Все сервисы имеют одинаковый OperationContract: они предоставляют методы Register () и Send (). Когда клиентские службы хотят подключиться к другой службе, они сначала вызывают Register (), а затем, в случае успеха, all оставшуюся часть своей связи с 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) Необычно ли выставить в OperationContract только 2 метода и использовать перечисление MessageType, чтобы определить, для чего предназначено сообщение / что с ним делать? Разве служба WCF не должна предоставлять множество методов с конкретными целями, а клиент выбирает, какие методы он хочет вызвать?
3) Осуществляет все общение с клиентом через CallbackContracts. Конечно, синхронизация или асинхронный запрос-ответ проще.
4) Является ли идея службы не позволяющей клиентским службам подключаться к ней (регистрироваться) до тех пор, пока она не подключится ко всем своим службам (для которых она является клиентом), звуковой дизайн? Я думаю, что это единственный аспект разработки, с которым я согласен, я имею в виду, что DataAccessService не должен принимать клиентов до тех пор, пока он не подключится к службе журналирования.
У меня так много вопросов о WCF, что они будут обсуждаться позже. Заранее спасибо.