Tag Archives: WCF

Интеграционная архитектура. Контракты.

Основная мысль этой статьи:

Контракты — важная часть интеграционных систем.
Основные требования к контрактам:

  • простая процедура создания/получения контрактов;
  • возможность простого обмена контрактами.

Успех конкретных интеграционных систем в немалой доли зависит от этих требований.

Определения

Рассмотрим несколько стандартных шаблонов обмена сообщениями (MEX — Message Exchange Patterns). Это Запрос-Ответ (Request-Response) и Pub-Sub (не знаю, как это по-русски, буду так и писать Паб-Саб).

В отношении создания, инициирования данных можно определить две роли: инициатор и получатель данных.

В шаблоне Запрос-Ответ есть две роли: клиент и сервис (client и service). Сервис «владеет» контрактами. В том смысле, что клиенты должны слать запросы в нужном формате (формат этот принято называть контракт), и формат этот задает сервис, не клиент. Клиенты должны следовать этому контракту. Задается этот контракт сервисом. В WCF веб-сервисах есть специальный адрес (mex address), по которому сервис выдает этот контракт, а клиенты могут получить этот контракт. Если, к примеру адрес (URL) веб-сервиса http://MyServer.com/MyService.svc, то mex адрес получается из этого адреса с добавлением ?wsdl, то есть в нашем примере получится  http://MyServer.com/MyService.svc?wsdl Если смотреть с точки знения инициации данных, здесь получатель данных определяет контракт.

В шаблоне Паб-Саб есть тоже две роли: издатель и подписчик (publisher и subscriber). Здесь уже не получатель данных определяет контракт, а наоборот,  инициатор данных. В данном случае это издатель. Издатель публикует сообщение ничего не зная о том кто получит его. Он даже не интересуется, а получит ли это сообщение вообще хоть один подписчик. Дело подписчика подписаться на это сообщение, получить его и обработать. И тут уж подписчик никак не может повлиять на формат этого сообщения. Он должен сам позаботиться о получении каким-либо образом контракта и далее использовать этот контракт, чтобы получить нужные данные из сообщения.

Кстати, я не определил, что же такое контракт. Контракт — это некое описание формата сообщения. В контракте описана структура сообщения. Какие поля и в каком порядке располагаются внутри сообщения, иерархия этих полей, типы этих полей и тому подобная информация.  Описания должны следовать неким правилам. Эти правила определяются специальным языком описания данных. С помощью контракта получатель сообщения имеет возможность проверить корректность сообщения и разобрать сообщение на исходные поля. Соответственно инициатор сообщения имеет возможность создать сообщение, разместить данные в нужные поля, соблюдая нужный формат.

Если мы имеем дело с XML сообщениями, то под контрактом понимается XML схема (XML Schema), специальный стандарт, определяющий язык описания XML документов. Обычно XML схемы хранятся в файлах с расширением xsd, поэтому часто говорят об xsd, имея в виду XML схему.

С сообщениями в других форматах не все так однозначно. К примеру для JASON не существовало до последнего времени однозначного стандарта языка описания. Понятно, что так долго продолжаться не могло, поэтому уже появился JASON Schema IETF стандарт.

Мы в данном контексте просто предположим, что некий язык описания наших сообщений существует и именно он используется для контрактов.

Системы могут обмениваться сообщениями напрямую, а могут использовать некую промежуточную систему. Иногда в этом контексте говорят о Point-to-Point шаблоне/архитектуре и Брокер (Broker) и ESB (Enterprise Service Bus) архитектурах.

Point-to-Point архитектура хорошо ложится на Запрос-Ответ шаблон, а  ESB — на Паб-Саб.

Основное отличие здесь в том, что исходное сообщение будет доставлено только одному получателю в Point-to-Point, а в ESB исходное сообщение может быть доставлено одновременно многим подписчикам или может быть не доставлено никому. В ESB сообщение двигается в одном направлении, от издателя к подписчику/подписчикам, обратная связь, если она существует вообще, осуществляется по другим каналам. В Point-to-Point легко реализовать двунаправленную связь, поэтому Point-to-Point — вотчина Ответ-Запроса.

И Брокер, и ESB маршрутизируют (route) сообщения. Они обладают некой информацией, которая помогает им решать куда направлять то или иное сообщение. Вы не найдете нигде точного определения ESB, но одно общее утвержение об ESB, объединяющие большинство определений, гласит, что в ESB сообщения должны двигаться асинхронно, то есть это — квинтэссенция Паб-Суб шаблона.  Сообщения просто «бросаются» в ESB, а она знает, что с ними делать.

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

Давайте посмотрим  на то, как инициаторы и получатели данных обмениваются контрактами в разных системах.

WCF

Здесь система обмена контрактами является частью технологии. Клиент делает запрос по <АдресСервиса>?wsdl адресу и в ответ сервис возвращает контракты. В этой системе нет никаких отдельных сервисов или инфраструктурных программ, которые обеспечивают обмен контрактами. Каждый сервис полностью ответственен за свои контракты. Конечно, сервисные библиотеки WCF обеспечивают автоматическую генерацию XML схем и разработчику сервиса не надо беспокоиться об этом самому.

Попытка протолкнуть в массы стандар UDDI, призванный управлять метаинформацией сервисов, в том числе и контрактами, не удалась. Массы отвергли этот стандарт. Другие подобные стандарты не возникли в силу невостребованности. Практика показывает, что существующий в веб-сервисах метов обмена контрактами получился удачным и востребованным. К примеру намного более быстрые и простые REST веб-сервисы после быстрого и шумного старта так и не стали безоговорочным победителем. Одна из главных причин, в том, что система обмена контрактами не встроена в REST сервисы, так, как это было сделано в WCF сервисах.

BizTalk Server

BizTalk Server — это по сути брокер.

Все контракты в BizTalk — это XML схемы. BizTalk хранит все схемы в конфигурационной базе данных. Дальше по тексту термин контракт будет эквивалентен термину XML схема.

Как получаются контракты?

Если собственник контракта обладает способностью выдавать их по запросу, то BizTalk предоставляет визарды для подключения и скачивания этих контрактов. К примеру, контракты можно автоматически получить от WCF веб-сервисов, от SQL Server, от Dynamics CRM, от SAP R/3 и нескольких других приложений. Практически все адаптеры из WCF Adapter Pack и WCF LOP Adapter Pack имеют визарды для генерации контрактов.

Если внешняя система или транспорт не предоставляют контракт, то в BizTalk есть обходной маневр. Берется образец сообщения и специальный визард генерирует XML схему по этому образцу. Есть визарды для XML сообщений и для текстовых сообщений, так называемых Flat File messages.

Если обмен сообщениями осуществляется по стандарту EDI (X12 или EDIFACT), то BizTalk предоставляет уже готовые контраты, более 7000, для этого стандарта. Кроме этого предоставляются контракты для стандартов HL7, HIPAA, EANCOM и некоторых других.

Как контракты предоставляются потребителям?

Обычно интегрируемые системы имеют собственные контракты, собственные форматы данных и собственные требования к транспортным протоколам. Владельцы этих систем вряд ли будут менять эти контракты. Разработчики, которые интегрируют эти системы, должны использовать эти контракты. Каки образом разработчики получают эти контракты? Иногда интегрируемые системы имеют API для автоматической выдачи контрактов. В BizTalk нет API или общего интерфейса по выдачу контрактов потребителям. Есть возможность сгенерировать WCF веб-сервис для receive port, что предоставит потребителю запрашивать и получать контракты этого порта. Но это обходной путь. Прямого пути получения контракта из конфигурационной базы данных BizTalk к сожалению не существует.

BizTalk и контракты

С одной стороны в BizTalk — мощные и разнообразные каналы генерации контрактов. С другой стороны в BizTalk мало что сделано, чтобы обеспечить простой и быстрый,  и вместе с тем организованный обмен контрактами. В результате на BizTalk довольно просто делается инеграция «по площадям», когда множество разнообразных систем хаотически интегрируются. Но большие интеграциооные проекты, где требуется системный подход к управлению контрактами, на BizTalk делать сложно.

Всегда ли контракты хранятся и передаются отдельно от данных?

Обычно контракты хранятся и передаются отдельно. Но есть системы и стандарты, где они передаются вместе с данными.

К примеру в  Google Protocol Buffers.

XML также имеет возможность «вшивать» определения типов с помощью Instance Type атрибутов, задаваемых с http://www.w3.org/2001/XMLSchema-instance namespace.

Реклама

Оставьте комментарий

Filed under BizTalk, Integration Architecture, WCF

BizTalk course: 08 Web-services

Что учим:

  • Создание Web-service (WS)
  • Интеграция BizTalk с WS
    • Publishing WS — Создание WS из BizTalk
    • Consuming WS — Обменн данными между WS и BizTalk

 Одна из важнейших частей системной интеграции — Web-services (WS). Для начала сделайте Лабораторную работу (см.ниже 1), потом почитайте немного теории. Чтобы сделать следующие (см.ниже 2 и 3) примеры, вам понадобится установить Windows Samples. Здесь инструкции по загрузке и установке. Сами примеры небольшие и не загромождены частностями.

BizTalk может делать (publish) WS на базе Orch, т.е.он показывает Orch внешнему миру, как будто это WS. Кроме этого он может использовать (consume) WS, т.е. запрашивать и получать данные у WS.

Для независимой отладки WS чаще всего используется утилита SoapUI. Ее бесплатную версию желательно скачать и установить.

Все это может занять 4-10 часов.

Практика:

  1. MSDN Virtual Lab: BizTalk Server 2009: Using the WCF Adapters in BizTalk Server 2009
  2. Windows Communication Foundation (WCF). Getting Started sample
  3. Windows Communication Foundation (WCF). Getting Started Tutorial

Теория

  1. Windows Communication Foundation (WCF) Conceptual Overview
  2. BizTalk Server 2010: Using Web Services
  3. BizTalk: Document: Consuming and Exposing Web Services from an Orchestration

Оставьте комментарий

Filed under BizTalk, BizTalk course, WCF

WCF: QA Вопросы и ответы для подготовки к интервью

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

Часть 1: «BizTalk 2004, Questions for interview without answers» http://geekswithblogs.net/LeonidGaneline/archive/2006/05/22/79267.aspx  
Часть 2: «BizTalk interview questions and principle» http://geekswithblogs.net/LeonidGaneline/archive/2007/07/03/113663.aspx  
Часть 3: «WCF: Questions for studying and interview» http://geekswithblogs.net/LeonidGaneline/archive/2008/01/07/wcf-questions-for-studing-and-interview.aspx  


 

Отладка:

  • Какие утилиты используются для отладки WCF сервисов?
  • Возможно ли регистрировать (log) сообщения на стороне сервиса? На стороне клиента? Как включить регистрацию?
  • Какая разница между сервисными (service) и транспортными (transport) сообщениями?
  • Какая разница в функционале между SoapUi утилитой и VS2008 функциональностью, использующейся в тестировании Веб-сервисов (WS)?
  • Опишите, как используется утилита LoadGen для тестирования WS? Для какого типа тестирования?


Конфигурационные файлы (config):

  • Перечислите самый верхний уровень элементов в <system.serviceModel> секции.
  • Что такое атрибут name в <service> елементе?
  • Что такое атрибут contract в <endpoint> елементе?
  • Какая разница между атрибутами binging и bindingConfiguration в <endpoint> елементе?
  • Какая разница между атрибутами binging и bindingName в <endpoint> елементе?
  • Уникальны ли адреса, bindings и контракты между разными сервисами?
  • Как зависят друг от друга app.config и machine.config файлы?
  • Перечислите самый верхний уровень элементов в элементах the <bindings> и <binding>.
  • Как редактировать конфигурационные файлы WCF?

Сервистные контракты (Service contracts):

  • Перечислите три шаблона обмена сообщениями (MEX, message exchange patterns) в модели WCF.
  • Если операция сервиса (service operation) ничего не возвращает (=возвращает void), то какой используется шаблон обмена сообщениями? В этом случае ожидает ли клиент завершения операции?
  • Какая разница между шаблоном «запрос-ответ» (request-response) и дуплексным (duplex) шаблоном?
  • Кто задает адрес клиента при дуплексной связи, клиент или сервис? [Сервис использует этот адрес, чтобы ответить клиенту.]

Контракты ошибки (Fault contracts):

  • В каком порядке надо отлавливать следующие исключения: TimoutException, FaultException, FaultException<MyException>,
    CommunicationException?
  • Вы разрабатываете WS. Как вы будете возвращать ошибки клиенту? Создадите ли специальные елементы/атрибуты (error(s)/success nodes) в возвращаемом сообщении (response) или же будете использовать Контракт ошибки? Какая разница в этих подходах?

Версии WCF:

  • В какой версии .NET появился WCF?
  • Чем отличаются WCF в разных версиях .NET?
  • Перечислите основной функционал последней версии WCF.

Сессии, Инициализация и Параллельность (Sessions, Instancing, and Concurrency):

  • Для чего нужны сессии,
  • Где сессии сохраняют свою информацию? Какое основное хранилище для сессий?
  • Что такое корреляция (correlation)? Какие параметры обязательны для корреляции?
  • Кто инициирует сессию, сервис или клиент?
  • В каком порядке доставленные сообщения обрабатываются во время сессии?
  • Как можно создать singleton сервис?
  • Увеличивает ли параметр SessionMode.NotAllowed производительность?
  • Что такое Terminating и Initiating в OperationContract? Можно ли использовать одновременно оба?
  • Как клиент страртует сессию?

Транспорты (Transports):

  • Как обеспечить последовательную обработку (streaming)?
  • Какие типы параметров операций могут обрабатываться последовательно?
  • Надо ли изменять параметр maxReceivedMessageSize , чтобы обеспечить последовательную обработку?
  • Какие ограничения имеют WCF транспорты?
  • Что такое Teredo? Как мы можем использовать его?
  • Что такое Net.TCP Port Sharing? ? Как мы можем использовать его?

Очереди и Надежные сессии (Queues and Reliable Sessions):

  • Какие типы надежного обмена сообщениями (reliable messaging) реализованы в WCF?
  • Что такое надежная (Reliable) сессия?
  • Какие WS стандарты отвечают за надежый обмен сообщениями?
  • Должны ли быть надежные сессии асинхронными (asynchronous)?
  • Привязана ли надежная сессия к сессионному транспорту?
  • Может ли надежная сессия быть односторонней сессией (one-way), сессией запрос-ответ (request-reply) или дуплексной (duplex)? Или может быть любой из перечисленных?
  • Поддерживают ли стандартные (system-provided) bindings надежную сессию? Какие binding опции разрешены по умолчанию?
  • Надежные сессии в Windows Communication Foundation (WCF) используют окно передачи (transfer window). Что это такое? Что оно означает для отправителя сообщения и что для получателя сообщения? Как оно зависит от задержки в передаче (latency)?
  • Что такое Transmission queue и Target queue? Какая между ними разница? 
  • Что такое Dead-letter queue и Poison queue? Какая между ними разница? 
  • Могут ли двусторонние операции (two-way service operations) использоваться вместе с queued binding?
  • Может ли параметр ExactlyOnce netMsmqBinding быть истиной (true), если очередь (queue) не транзакционная (transactional)? 
  • Когда используются MsmqIntegrationBinding и NetMsmqBinding?
  • Есть ли ошибка в Msmq адресе «net.msmq://MyHost/private$/MyQueue»?
  • Можем ли мы использовать общие очереди (public queues) без Windows domain? Если нет, то почему?
  • Использует ли MsmqIntegrationBinding схему msmq.formatname или схему net.msmq?

Хостинг (Hosting):

  • Какая новая возможность хостинга появилась, начиная с Vista OS?
  • Должны ли мы использовать относительные (relative) адреса или абсолютные (absolute), когда хостинг в IIS? Почему?
  • Может ли WCF-сервис, «хостингующийся» в IIS, использовать HTTPS, если виртуальный каталог IIS, содержащий сервис, не поддерживает transport security?

 

Оставьте комментарий

Filed under WCF

Почему стандарт UDDI стал нишевой технологией?

Несколько лет назад, когда был объявлен новый стандарт UDDI [см. в Википедии], будущее для стандарта выглядело многообещающим. Имеющаяся информация убедила меня в том, что стандарт ждет хорошее будущее.
Будущее однозначно за Веб-сервисами, так я думал, и, как оказалось, я не ошибался. А это значит, что нужен сервис для поиска нужного Веб-сервиса в сети, либо реестр/каталог Веб-сервисов.
Действительно, как мы можем найти в сети Веб-сервисы? Гугл не очень эффективно ищет Веб-сервисы даже сейчас, в наше время. Однозначно, идея реестров UDDI должна была победить, все Веб-сервисы должны были взаимодействовать с этими реестрами. Другого пути не было. Веб-сервисов будет очень много и среди них нам нужно будет искать нужные сервисы, и создание реестров Веб-сервисов (используя стандарт UDDI) естественный путь развития. Так нам тогда казалось.
Тогда подключились большие компании с большими ресурсами, IBM, Microsoft, SAP. Умные люди писали стандарт, разработчики писали системы, поддерживающие реестры UDDI. Большие компании объявили об общедоступных реестрах, которые скоро будут доступны в сети. Будущее было безоблачным.

Прошло уже много лет. Майкрософт закрыл свой реестр в интернете. Сейчас практически не осталось UDDI реестров общего пользования. Те, что были или остались, представляют из себя жалкое зрелище. Похоже, никто не хочет публиковать свои Веб-сервисы в этих реестрах.

Почему?
Почему UDDI реестры так и не стали популярными, такими же, как Yahoo когда-то?

Состояние дел напоминает мне, с одной стороны, «пред-гугловские» дни, когда каждый новый сайт требовал так называемой «раскрутки в поисковых сервисах». В каких-то поисковиках можно было зарегистрировать новый сайт без помех, в каких-то требовалось либо заплатить, либо пройти процедуру утверждения. Потом появился Гугл, который сам находил новый сайт и сам его включал в свою базу. Явный процесс регистрации стал неявным, автоматическим. Может быть нечто подобное случилось с реестрами Веб-сервисов?
С другой стороны оказалось, что большинство Веб-вервисов не хотят себя «рекламировать». Большая их часть создана для использования узкого круга пользователей, которые должны знать всю необходимую информацию о Веб-сервисе, его адреса, его метаинформацию (wsdl, wsd-s, bindings и т.д.). Более того, нежелательно, чтобы кто-то вне круга своих пользователей знал бы и мог бы получить эту информацию.
Были еще другие сильные факторы, негативно повлиявшие на внедрение стандарта.
К примеру, сам стандарт. Вместо того, что сделать его простым, понятным и легким в использовании, разработчики сделали его всеобъемлющим (так, наверняка, казалось им) и просчитанным до мельчайших деталей, большим и неповоротливым. В те годы, когда XML только становился популярным, было очень модно впихивать в стандарты все, что только приходило на ум. Стандарты тех лет отличались своей монолитностью и колоссальностью. Считалось, что стандарт должен вместить в себя все знания данной области. Конечно, до старых стандартов-монстров, типа EDI или HL7 им было далеко. Но им также было далеко и до нынешней моды делать лаконичные, сегментированные стандарты (например, стандарты WS-* семейства).
Но самым сильным негативным фактором оказалось то, что UDDI реестры оказались «подвинутыми» другими технологиями. Поясню. Сейчас практически все Веб-сервисы «выставляют» в сети по своему адресу и всю свою метаинформацию. То есть и wsdl-ы, и xsd-и, и bindings, все это размещается не в отдельных реестрах, а вместе с самим Веб-сервисом. Веб-сервисы таким образом становятся самодостаточными, пользователю не надо искать метаинформацию где-то еще. Пользователю достаточно знать только URL-адрес Веб-сервиса, после чего он извлекает всю нужную метаинформацию, с помощью которой он и работает с Веб-сервисом. А для каталогизации одних адресов сервисы UDDI становятся слишком сложными и перегруженными ненужными функциями.
Вот так и оказалось, что стандарт UDDI и UDDI сервисы используются только в очень узких областях. К примеру он используется в BizTalk (см. ESB Toolkit 2.0). B ESB реестр Веб-сервисов несомненно нужен, так как сама идея ESB базируется на принципе, что пользователи публикуют свои сообщения в ESB, а шина сама знает какие сервисы будут обрабатывать эти сообщения и направляет сообщения по нужным адресам, в нужных форматах.
Но обычному пользователю Веб-сервиса как правило надо знать только адрес этого сервиса.
UDDI позволяет искать Веб-сервисы по ключевым словам, так же, как это использовалось в каталогах Yahoo. Но оказалось, что эта возможность пока не востребована.
Стандарт UDDI пока является нишевым стандартом, не универсальным.

—————————————-
Ссылки:
[UDDI. Официальный сайт]
[Небольшой список реестров UDDI]
[Почему IBM, SAP и Microsoft закрыли свои UDDI реестры]
[Страничка UDDI у Microsoft]
[BizTalk. ESB Toolkit 2.0. UDDI в BizTalk]

Оставьте комментарий

Filed under BizTalk, WCF

Обзор книги «MCTS Self-Paced Training Kit (Exam 70-503): Microsoft .NET Framework 3.5 Windows Communication Foundation (PRO-Certification)»

Обзор книги «MCTS Self-Paced Training Kit (Exam 70-503): Microsoft .NET Framework 3.5 Windows Communication Foundation (PRO-Certification)» http://www.amazon.com/MCTS-Self-Paced-Training-70-503-PRO-Certification/dp/0735625654/ref=sr_1_12?ie=UTF8&s=books&qid=1224042536&sr=8-12

Что мне нравится в книгах этой серии, так это то, что теория всегда закачивается практическими примерами. И примеры эти показывают реальные проблемы, ситуации.
Это сильно отличается от документации, где все функции продукта просто перечислены без расстановки приоритетов. В книгах серии Self-Paced Training Kit (СПТК) нет места, чтобы излагать все функции, цели здесь другие. Здесь даются только ОСНОВНЫЕ функции и показываются цепочки действий для достижения *реального* результата. К примеру, часть о MessageContract. В документации по WCF масса информации об этом типе контракта, но чрезвычайно трудно понять, для чего же вообще (!) можно его использовать. В СПТК дан *конкретный* пример, где MessageContract используется для передачи лицензионного ключа. Все становится понятно.

Я работаю с Web-сервисами больше 3х лет, последний год исключительно с WCF сервисами. Книгу я использовал не для сдачи экзамена, а для систематизации своих знаний. (Здесь дискуссия о пользе сертификационных экзаменов http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3280207&SiteID=1)

Я использую любой источник информации, для того, чтобы *понять*, что происходит внутри продукта, почему данные конкретные функции были введены в продукт, какие альтернативы есть. Почему? Без ответов на этот вопрос, информация просто не укладывается в моей голове. Я не могу как обезьянка выучить действия, приводящие к результату. Мне надо знать, *почему*.

В любой методике объяснений немаловажную часть занимают объяснения *неправильного* использования, примеров *неправильных* техник. Не давая Cons, очень тяжело рассказать о Pros. Иногда десяток примеров правильного использования продукта не заменит одного примера «неправильного» использования.

Чем серия СПТК серия отличается от других книг издания Microsoft:

* в книгах этой серии приведен только *основной* функционал продуктов. На описание всего там нет места. Этот функционал выбран с точки зрения Microsoft, то есть с точки зрения производителя. И это важно.

* в них приведены примеры *реальных проблем* и как они решаются с помощью основного функционала продукта.

* в книгах сжато рассказано, что послужило основанием для создания именно этого функционала.

* здесь приведены примеры *неправильного* использования.

Pros:

* По сути СПТК — видение Microsoft о том, для чего замышлялся продукт, какие основные шаблоны его использования.

* в разделах Lessons приведена концентрированная информация об основных характеристиках WCF. Рядом находятся примеры из практики. Примеры тоже концентрируют на самых необходимых вещах.

* Мне очень нравятся разделы Lesson Summary. Это списки важнейшего функционала основных частей WCF.

Cons:

* Иногда используемые в примерах методы устарели много раньше выхода книги. К примеру, генерация классов из XSD с помощью XSD.exe утилиты. Несколько поколений Software Factory поддерживают уже эту функцию. Как и SvcUtil.exe

* частенько объяснения, что именно было сделано и какой в этом смысл, далеки от совершенства. Чувствуется, что писатели сами многого не понимают, а следуют лишь подробным инструкциям. Что, в общем-то, и неудивительно, принимая во внимание невообразимое количество функционала WCF. (К примеру, на стр.66 просится закомментировать директиву [XmlSerializerFormat…] после чего сгенерировать схемы заново и убедиться, что новые схемы будут очень сильно отличатся от схем, сгенерируемых по-умолчанию. Без объяснений, почему мы получили различия, все эти упражнения с комментированием имеют мало смысла.)

Я знаю несколько хороших источников информации о WCF именно в приведенном выше разрезе:
* Samples in .NET SDK
* Книга «Programming .NET Components», 2nd Edition by Juval Lowy
* форумы MSND (http://social.msdn.microsoft.com/forums/en-US/wcf/threads/ )
— и теперь к этим источникам прибавилась эта книга.

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

C уважением,
Leonid Ganeline [BizTalk MVP] http://geekswithblogs.net/leonidganeline/

Оставьте комментарий

Filed under Certification, WCF