О технологии Windows Communication Foundation (WCF) сказано достаточно много. В сети существует множество примеров, начиная от самых простых и заканчивая довольно сложными. И, казалось бы, все уже прекрасно понимают, что представляет собой эта технология, каковы ее преимущества, а главное то, как применять ее в собственных разработках. Поскольку я довольно давно работаю с WCF, мне тоже так казалось, пока не возникла та задача, которая заставила меня, наконец, изучить тонкости WCF. Собственно, знания, которые я приобрел в ходе решения обозначенной задачи, а также личные соображения по этому поводу, я изложу в данной статье.
С обработкой ошибок сталкивался и сталкивается каждый день любой разработчик. И мы к этому привыкли, привыкли делать проверки на null и прочее, чтобы избежать наших «любимых» исключений или сформировать и сгенерировать собственное, более информативное исключение. Но когда речь идет о распределенных приложениях, тут следует учитывать их специфику.
В распределенной системе в качестве источника ошибок может выступать как клиентская, так и сервисная сторона.
Любая операция сервиса может вызвать исключение, о котором бы хотелось как-то оповестить клиента. На этом этапе и начинает работать специфика, о которой я говорил ранее, - специфика передачи ошибок между клиентом и сервисом. О ней и будет разговор.
Говоря о WCF, следует четко понимать основную концепцию сервисов. Сервис в WCF рассматривается, как нечто самодостаточное и совершенно независимое от своих клиентов. К этому и следует стремиться, проектируя собственные сервисы. Помимо этого, сервис должен быть отказоустойчивым, иначе говоря, он не должен переходить в ошибочное состояние в случае какой-либо некритичной для него ситуации. Последнее очень важно в плане понимания идеи обработки ошибок в WCF.
Если в сервисе и происходит исключение, то клиенту не обязательно знать обо всех тонкостях этого исключения, ему важен факт ошибки и основная причина ее возникновения. Все тонкости важны только на этапе отладки, но в реальной жизни они не должны выходить за пределы сервиса. Для того чтобы как-то следить за жизнью сервиса, обычно пользуются журналом событий или определяют собственную реализацию логирования. Об этом мы тоже поговорим, но чуть позже, а пока рассмотрим основные типы исключений в WCF.
В WCF работа hosting-процесса организована таким образом, что исключения, возникающие в WCF-сервисе, не нарушают работу этого процесса, а также работу других запущенных сервисов и клиентов, не имеющих отношения к этим исключениям. Как и в любой другой технологии удаленного взаимодействия, ошибка сервиса (fault) передается только тому клиенту, который стал ее инициатором.
Ясно, что для передачи ошибки, между клиентом и сервисом должна существовать некоторая договоренность, благодаря которой клиент однозначно воспринимает сервисную информацию и наоборот. Частью такой договоренности служат ошибки, о которых знает и клиентская и сервисная сторона.
Пытаясь обратиться к сервису, клиент, фактически, может столкнуться с тремя типами ошибок:
С первыми двумя типами ошибок, как правило, все понятно, к тому же они обеспечиваются самой инфраструктурой WCF. Что касается ошибок, возникающих при обращении к сервису, – тут все намного сложнее и интереснее, поскольку существует множество причин возникновения ошибки, при выполнении сервисного запроса. В связи с этим, именно ошибки запросов, и представляют наибольший интерес, собственно им и посвящается данная статья.
Текущая реализация логической модели WCF на .NET-платформе такова, что исключения, вызванные на стороне сервиса, как правило, достигают клиента в виде FaultException.
public
class FaultException : CommunicationException
{ ... }
|
Версия для печати