В этой заметке я отталкиваюсь от определения архитектуры, которое предложил Мартин Фаулер в своей статье “Who Needs an Architect?”, перевод которой я публиковал в прошлый раз.
В чем главное отличие WCF от своих предшественников, таких как .NET Remoting, веб-сервисы, MSMQ или более старых технологий, таких как DCOM?
Расширяемость? Так .NET Remoting тоже содержит 100 500 слоев и расширяем донельзя. Возможность взаимодействия с приложениями на других платформах? Так это же умели делать и веб-сервисы. Ориентированность на обмен сообщений? Так именно эта идея заложена в основе MSMQ.
.NET Remoting представляет собой навороченный RPC, предназначенный для взаимодействия двух .NET приложений. Веб-сервисы являются реализацией сервис-ориентированной модели, а MSMQ исключительно ориентирована на обмен сообщениями.
Все это прекрасно, но каждый из вышеперечисленных фреймворков представляет разный API с точки зрения пользователя: разный набор базовых классов, инструментов конфигурирования и диагностики. Допустим, вы приняли решение об использовании .NET Remoting, но потом захотели выставлять свой сервис в мир и дать возможность подключиться к нему не только дот-нетному приложению. В результате придется выкинуть значительную часть кода и все переписать заново! А как быть существующим .NET клиентам, расположенным внутри закрытой сетки вашей компании, которых взаимодействие через .NET Remoting полностью устраивало?
В результате, использование одной из старых технологий, делало модель распределенного взаимодействия архитектурным решением, о котором должны знать большинство разработчиков и которое довольно сложно изменить в будущем.
Главное отличие и преимущество WCF заключается в том, что эта технология абстрагируется от вида распределенного взаимодействия и легко позволяет изменить свое решение в будущем!
WCF с другой стороны, хотя и является «сервис-ориентированным» по умолчанию, позволяет достаточно легко перейти от SOA модели к RPC модели, а потом к модели на основе обмена сообщениями. Модель распределенного взаимодействия является деталью, причем даже не реализации, а конфигурирования. В результате, у вас может быть один и тот же сервис, который будет «торчать» во внутреннюю сеть в качестве RPC-style сервиса, торчать в мир в виде классического сервиса, а в некотором режиме может использовать «персистентные» сообщения от стороннего вендора.
Но этого мало!
Несмотря на то, что WCF может абстрагировать его пользователя от нижележащей модели распределенного взаимодействия, это не значит, что WCF не будет частью архитектуры вашего приложения.
Так, например, в большинстве случаев мы можем «абстрагироваться» от конкретной технологии (включая WCF) путем написания дополнительных фасадных классов или же просто ограничить количество мест приложения, использующих инфраструктуру WCF.
Такой подход подразумевает, что наши классы WCF сервисов должны заниматься лишь коммуникационными вопросами и не содержать бизнес логики. Это позволит запускать и тестировать наши приложения в виде консольного приложения, эмулируя данные от сервиса или клиента. Это же позволит сделать WCF лишь тактикой, а не стратегией и даст хоть какие-то шансы перейти на другую технологию, если WCF все же не будет нас устраивать в будущем.
В этом подходе не стоит перегибать палку; не нужно делать распределенное взаимодействие полностью прозрачным. Ранние технологии, такие как .NET Remoting и DCOM проповедовали идею прозрачности местоположения (location transparency), но как показывает практика, мы должны понимать, что за вызовом некоторого метода последует сетевое взаимодействие, с другой длительностью вызова и другими причинами возникновения ошибок (именно поэтому WCF четко разделяет коммуникационные ошибки от ошибок на сервисе).
Вместо прозрачности местоположения мы можем добиться независимости от распределенной технологии (distribution model transparency), что сделает конкретную технологию деталью реализации, и даст разумный компромисс между гибкостью и сложностью.
Я уверен, что есть приложения, в которых WCF является архитектурным решением, когда приложение состоит лишь из десятка сервисов с минимумом логики внутри. В большинстве же случаев, конкретная распределенная технология не должна проникать во все слои приложения, а должна быть ограничена относительно небольшим количеством модулей.
Комментариев нет:
Отправить комментарий