MSDN Magazine > Home > Issues > 2008 > Июнь >  ПО как услуга. Подключение корпоративных прилож...
ПО как услуга
Подключение корпоративных приложений к размещенным службам BizTalk
Джон Фландерс (Jon Flanders) и Аарон Сконнард (Aaron Skonnard)

Эта статья основана на предварительной версии служб BizTalk. Любые содержащиеся в ней сведения могут быть изменены.
В этой статье рассматриваются следующие вопросы.
  • Службы BizTalk как служба ESB
  • Приложения WCF на службах BizTalk
  • Варианты ретранслированного подключения
  • Службы удостоверений и поставщики маркеров
 В данной статье использованы следующие технологии:
службы BizTalk, .NET Framework 3.0
Сейчас в большей, чем когда-либо, мере бизнесу требуется способность быстро разрабатывать, развертывать и интегрировать в существующие среды новые приложения. Растущая потребность в динамических, гибко связанных приложениях – это одна из основных причин, по которым многие компании перешли или переходят в настоящий момента на архитектуру, ориентированную на службы (SOA), в качестве новой платформы своих приложений.
По мере продвижения компаний к SOA все больше внимания уделяется составлению систем из различных приложений, имеющихся в предприятии. В этом новом мире работой разработчика является управление ходом бизнес-процессов из различных служб приложений, выложенных в сеть различными группами и организациями, которые могут использовать иные технологии реализации или бизнес-приложения, тем самым повышая общую сложность системы. Хотя SOA до некоторой степени упрощает каждое подключение типа «точка-точка», составные приложения могут стать неудобными в управлении и до некоторой степени неустойчивыми, поскольку общее число подключений к службам, требуемых приложением, со временем растет (см. рис. 1).
Рис. 1. Управление подключениями типа «точка-точка» в составных приложениях (Щелкните изображение, чтобы увеличить его)
Это привело многие компании к принятию более гибкого и удобного для поддержки шаблона служб, обычно именуемого корпоративной шиной служб (ESB). Популярность модели ESB возросла, поскольку она помогает предприятиям управлять многочисленными подключениями служб через центральную шину, что предоставляет дополнительный уровень абстракции поверх базовых подробностей обмена сообщениями. Например, ESB помогает улаживать различия между службами в области наименований, управления удостоверениями, форматов сообщений и протоколов связи. После того, как служба появляется на шине, все остальные пользователи шины могут подключаться к ней, даже если в обычных условиях они не смогли бы сообщаться со службой напрямую (см. рис. 2).
Рис. 2. Создание составных приложений с помощью ESB (Щелкните изображение, чтобы увеличить его)
Эта модель внедряет некоторую степень косвенности во взаимодействии различных служб на шине, а также между составными приложениями и службами, которые они потребляют. ESB также предоставляют различные функции обмена сообщениями, включая функцию публикации/подписки, которая предоставляет более свободную привязку внутри системы. При использовании функции публикации/подписки потребителям больше нет нужды напрямую подключаться к службам (всем нужно лишь подключение к шине), а узлы можно добавлять или удалять по желанию. ESB также обычно предоставляют механизм рабочего процесса для взаимодействий обмена сообщениями, которые составляют бизнес-процесс – этот уровень часто именуется управлением или потоком работ.
Одним из способов создания систем, применяющих шаблон ESB на платформе Майкрософт, является использование BizTalk® Server. BizTalk Server предоставляет все функции ESB, обсуждавшиеся выше, в своей стандартной комплектации.

Программное обеспечение как услуга
Тогда как ESB росли в популярности внутри компаний, внутри Интернета расцветала другая бизнес-тенденция, которая непременно повлияет на корпоративные системы в предстоящие годы. Эта тенденция, именуемая «Программное обеспечение как услуга» (SaaS), вращается вокруг компаний, представляющих в сети завершенные приложения и службы (порой это называется общественным Интернетом), за использование которых другие компании просто платят. Это позволяет клиентам избегать сложностей и затрат, связанных с созданием подобной программы и управлением ею (на проектирование, разработку, эксплуатацию и обслуживание), часто требующих больших первоначальных вложений.
Модель SaaS, по сути, позволяет клиентам получать удаленный доступ к программам, размещаемым другой компанией, являющейся специалистом в определенной области (такой как CRM, бухгалтерия, расчет заработной платы, хранение данных, электронная почта и так далее), как показано на рис. 3. При использовании SaaS поставщик обычно предлагает законченное решение для определенной программной потребности, позволяя клиенту использовать внешние услуги для данной конкретной части системы. Поставщик службы управляет программой в ходе эксплуатации и просто берет плату с использующих ее клиентов, а значит клиенту больше не нужно управлять этими программными службами локально.
Рис. 3. Удовлетворение программных потребностей за счет внешних услуг с помощью SaaS( Щелкните изображение для его увеличения).
Приложения и службы, предоставляемые поставщиками SaaS, обычно используют стандартные веб-протоколы и форматы данных, для повышения простоты использования и потенциального охвата. В наши дни они склонны во многом полагаться на HTTP и на повсеместно используемые сейчас форматы веб-данных типа XML, RSS и JSON. Хотя SaaS не ограничивает поставщика этими конкретными вариантами, требования охвата часто толкают поставщиков в этом направлении.
Некоторые архитекторы могут задать вопрос, насколько разумным является принятие внешних зависимостей, являющихся неотъемлемой частью системной архитектуры SaaS. Хотя это и может вызвать вопросы насчет подключения и соглашений об уровне обслуживания (SLA), при нынешней вездесущести подключений к Интернету, выставление программ в сети, похоже, стало полностью приемлемым и даже весьма выгодным, учитывая открываемые им новые пути.

Шина служб Интернета (ISB)
Корпорация Майкрософт с энтузиазмом приняла эти популярные идеи (ESB и SaaS) и смешала их наиболее привлекательные свойства в новую идею, названную шиной служб Интернета (ISB). В плане функциональности модель ISB подобна ESB. Однако ISB доступна в более широком масштабе Интернета, так что она подобна модели SaaS в плане стандартов, охвата и масштабируемости. Microsoft® ISB, по сути, упрощает принятие компаниями инфраструктуры ESB.
Хотя функции ESB и привлекательны для широкого диапазона компаний, похоже, что только крупные компании использовали их в значительном масштабе к настоящему моменту. В основном это вызвано значительными предварительными вложениями и финансовыми рисками, связанными в принятием инфраструктуры вроде ESB. Вместо этого, многие компании приходят к созданию своей собственной (и часто более дорогой) инфраструктуры интеграции систем. На настоящий момент это является одним из крупнейших препятствий к принятию BizTalk Server.
Более того, компании, способные применить ESB, все же испытывают затруднения при попытке заставить свои шины ESB общаться с шинами ESB их партнеров. Все экземпляры шин ESB индивидуальны, что осложняет интеграцию между предприятиями, даже при принятии слабо связанного шаблона шины ESB.
Платформа Microsoft ISB учитывает эти реалии, помещая ключевые компоненты шины служб в общественный Интернет для использования публикой вне зависимости от платформы, использующей компоненты. Майкрософт, по сути, делает шину служб доступной через модель SaaS, тем самым позволяя компаниям любого размера переходить на нее. ISB предлагает инфраструктуру публикации/подписки и необходимую инфраструктуру обмена сообщениями для прохода через брандмауэры предприятий, а также преобразователи сетевых адресов (NAT). ISB также предлагает интегрированное управление удостоверениями и уровень служб потоков работ для размещения нестандартных бизнес-процессов в сети, как показано на рис. 4.
Рис. 4. Развитие на основе новой шины служб Интернета(Щелкните изображение для его увеличения).
Корпорация Майкрософт активно работает над тем, чтобы сделать ISB реальностью и прослеживать ход ее работы можно на веб-узле служб BizTalk (см. labs.biztalk.net). Текущая предварительная версия (CTP) предлагает несколько фундаментальных служб, эксперименты с которыми можно начать сейчас. В ближайшие несколько лет Майкрософт планирует вырастить из этой инициативы матрицу связи с широкими возможностями, способную предоставлять эффективные стандартные блоки для широкого спектра современных «подключенных» приложений.
Однако, важно помнить, что фрагменты, доступные сейчас в виде CTP, предназначены только экспериментов и сбора отзывов, а не для использования в производстве. На данном этапе Майкрософт не предоставляет никаких гарантий качества. Также, корпорация Майкрософт пока не объявила, какой будет плата за использование ISB, когда та достигнет готовности к использованию в производственной среде.

BizTalk Services
Службы BizTalk– это первоначальное применение компонентов ISB, находящихся в Интернете. На данный момент службы BizTalk состоят из нескольких основных служб, включая службы связи BizTalk и службы удостоверений BizTalk. Другая ключевая служба – служба потоков работ BizTalk – станет доступной в ближайшем будущем. Большинство служб будут добавлены Майкрософт с течением времени, также дополнительные службы могут быть помещены в ISB сторонними производителями.
Давайте рассмотрим каждую из текущих основных служб подробнее. Одной из самых серьезных проблем при создании слабо связанных составных приложений является управление подключением служб на уровне сети. Например, одна служба может находиться в пределах сетевого периметра, а другая внутри брандмауэра, и им необходимо будет поддерживать связь. Либо может быть необходимо предоставить службу партнерам по бизнесу, но эти партнерские службы находятся за брандмауэрами – либо своими собственными, либо сетевых устройств, таких как прокси и NAT.
Службы связи BizTalk упрощают многие из этих проблем связи, предоставляя универсальное правило именования служб вместе с механизмом прямой/непрямой связи между двумя узлами, независимым от топологии и настройки сети. Они делают это, предоставляя контролируемый механизм безопасной передачи подключений через сетевые устройства. Но в тех случаях, когда может быть установлено прямое подключение, службы связи BizTalk могут не мешаться и позволить узлам подключиться друг к другу без ретрансляции трафика.
Код такого типа, можно, конечно, написать самому, хотя это будет сложно и обременительно. Основное преимущество возложения предоставления этих функций на службы BizTalk состоит в отсутствии необходимости писать или обслуживать этот код, который часто подгоняется под конечные точки. Это высвобождает силы для написания кода, решающего проблемы бизнеса, вместо траты их на обход проблем инфраструктуры. Службы связи BizTalk также предоставляют другие ключевые функции, такие как глобальное правило именования, основанное на унифицированных идентификаторах ресурса (URI) – простом механизме публикации/подписки и даже возможности многоадресности.
Другой основной частью служб BizTalk является служба удостоверений BizTalk, служба маркеров безопасности (STS), придерживающаяся стандарта WS-Trust. WS-Trust – это функционально совместимый стандарт для согласования безопасности, основанный на отношениях доверия между сторонами. Например, одна из сторон может проверить подлинность клиента и выпустить маркер, содержащий набор утверждений о клиенте. Этот маркер может быть затем безопасно представлен другим сторонам, которые доверяют стороне, выпустившей маркер. Такой подход позволяет унифицировать важную информацию о безопасности между несколькими организациями.
С учетом этого службы удостоверения BizTalk могут быть использованы в качестве службы удостоверений и управления проверкой подлинности сторонних лиц, даже если другие службы, вроде служб связи BizTalk, не применяются. Однако при использовании других служб BizTalk службы удостоверений BizTalk всегда будут применяться для проверки подлинности и авторизации пользователей.
При использовании службы связи BizTalk и клиент, и служба будут проверены службами удостоверений BizTalk с использованием имени пользователя/пароля, либо клиентского сертификата, либо управляемой карты. После проверки подлинности обрабатывается набор правил авторизации, который будет предоставлен службами связи BizTalk. Веб-узел служб BizTalk предоставляет интерфейс пользователя для управления правилами авторизации с помощью нескольких программных интерфейсов API, включая интерфейс RESTful.
Службы потоков работ BizTalk Workflow Services пока еще не были представлены публике. Однако ожидается, что в будущий выпуск служб BizTalk будет входить возможность размещения на ISB служб потоков работ, основанных на Windows® Workflow Foundation (WF). Потоки работ будут активироваться на основе сообщений, полученных ISB на определенном URI. Это единственные подробности, доступные в настоящий момент.

Комплект SDK для служб BizTalk
Комплект SDK для служб BizTalk – это бесплатная загрузка, доступная на biztalk.net, позволяющая приступить к программированию для ISB. Перед началом работы необходимо установить комплект SDK для служб BizTalk и создать учетную запись пользователя на веб-узле служб BizTalk. Службы BizTalk основаны на Windows Communication Foundation (WCF). Комплект SDK– это просто набор сборок на основе Microsoft .NET Framework 3.0, позволяющий использовать ISB через программную модель WCF.
Большая часть комплекта SDK для служб BizTalk содержится в сборке System.ServiceBus. System.ServiceBus использует стандартные точки расширения WCF для определения новой привязки, именуемой RelayBinding. Для тех, кто не знаком с WCF, – привязка определяет, какой род связи будет предоставлен или использован конечной точкой службы. Привязки используются средой исполнения WCF, чтобы создать уровень связи, известный как стек канала, для отправки и получения сообщений. Объекты в стеке канала выполняют связь через сеть и определяют, как безопасность и другие протоколы применяются в конечной точке.
На стороне слушателя RelayBinding позволяет предоставить конечную точку, которая будет доступна через глобальный идентификатор URI, поддерживаемый службами связи BizTalk. Когда открывается конечная точка, использующая RelayBinding, идентификатор URI будет зарегистрирован в службах связи BizTalk и, начиная с этого момента, любой авторизованный клиент будет иметь возможность посылать сообщения этому глобальному идентификатору URI, используя аналогично настроенный клиент. Тогда службы связи BizTalk становятся туннелем для связи между этими двумя конечными точками.

Типичное приложение WCF
Рассмотрим подробнее простой пример. Предположим, что мы – компания, что мы в настоящий момент предлагаем службу WCF в нашей внутренней сети и что ее вызывают из клиентского приложения с расширенными возможностями. Клиентское приложение используется работниками отдела продаж для обработки заказов. Приложение вызывает службу, после чего служба запускает серверную обработку, необходимую для выполнения заказа.
Служба в настоящий момент имеет настройку с единственной конечной точкой, использующей NetTcpBinding, что делает возможным высокоскоростные подключения через TCP/IP. NetTcpBinding, как правило, является лучшим выбором для служб, работающих внутри брандмауэра.
Вот код, настраивающий конечную точку и запускающий службу, используя стандартное размещение ServiceHost:
ServiceHost sh = new ServiceHost(typeof(SalesService));
sh.AddServiceEndpoint(typeof(ISalesService), 
  new NetTcpBinding(),
  "net.tcp://salesservicehost/SalesService");

sh.Open();
...
Это стандартный код WCF. Реализацией службы является тип SalesService, а контрактом – ISalesServices. Конечная точка ServiceEndpoint, созданная при вызове AddServiceEndpoint, использует NetTcpBinding и имеет адрес net.tcp://salesservicehost/SalesService.
Вместо того, чтобы жестко закодировать конечную точку подобным образом, мы могли бы также настроить ее в файле настройки приложения (как это обычно и делается). Но данный пример будет нагляднее, если оставить все в программном коде. Вот пример клиентского приложения, вызывающего SalesService для обработки продажи:
static void MakeSale(SaleData sd) {
  EndpointAddress ea = new EndpointAddress(
    "net.tcp://salesservicehost/SalesService");
  ChannelFactory<ISalesService> cf = 
    new ChannelFactory<ISalesService>(new NetTcpBinding(), ea);
  ISalesService service = cf.CreateChannel();
  service.EnterSale(sd);
}
С течением времени продавцы становятся более мобильными, и начинают приходить отчеты от сотрудников отдела продаж, не способных подключиться для обработки заказов, когда они находятся вне офиса и подключены к случайным сетям (некоторые из которых не допускают подключений виртуальной частной сети (VPN)).
Службы BizTalk способны решить эту проблему. Давайте взглянем, что требуется для предоставления SalesService через службу связи BizTalk:
ServiceHost sh = new ServiceHost(typeof(SalesService));
sh.AddServiceEndpoint(typeof(ISalesService), 
  new RelayBinding(),
  "sb://connect.biztalk.net/services/contososervices/SalesService");

sh.Open();
...
Как можно увидеть, для предоставления службы через службы BizTalk достаточно изменить одну строку кода – вызов к ServiceHost.AddServiceEndpoint. Вместо привязки NetTcpBinding мы используем привязку RelayBinding, которая, в свою очередь, использует службы связи BizTalk для открытия всем данной конечной точки по указанному идентификатору URI. Сообщения, посланные по этому адресу, ретранслируются локальному экземпляру SalesService.
Обратите внимание на формат URI – он начинается со схемы "sb", за которой следует имя узла служб BizTalk и, наконец, "services". После этого мы добавляем учетные данные служб BizTalk (установленное нами имя учетной записи), в данном случае это contososervices. Далее мы можем добавить все, что хотим, к идентификатору URI, чтобы сделать его уникальным. В данном случае просто добавлено SalesService.
При вызове ServiceHost.Open привязка RelayBinding заставляет WCF связаться со службами удостоверений BizTalk, чтобы проверить подлинность учетных данных службы и авторизовать ее на указанном идентификаторе URI. Поведением по умолчанию на данном этапе является появление селектора Windows CardSpace™, просящего кого-либо выбрать карту, представляющую удостоверение службы.
Тот факт, что в ходе проверки подлинности появляется интерфейс пользователя, очевидно, недопустим для большинства служб, поскольку они обычно работают в автономных средах, где нет вошедших в систему. Однако эту проблему можно обойти при помощи небольшого куска кода, который мы покажем ниже, так что не стоит беспокоиться. Пока что мы просто выберем карту, которая позволит SalesService начать прослушивание. С помощью служб удостоверения BizTalk можно управлять тем, каким удостоверениям позволено слушать на определенном идентификаторе URI.
Теперь давайте взглянем, что требуется для обновления клиента, чтобы он мог использовать конечную точку служб BizTalk:
static void MakeSaleISB(SaleData sd) {
  string uri =   
    "sb://connect.biztalk.net/services/contososervices/SalesService";
  ChannelFactory<ISalesService> cf = new ChannelFactory<ISalesService>(
    new RelayBinding(), new EndpointAddress(uri));
  ISalesService service = cf.CreateChannel();
  service.EnterSale(sd);
}
Обратите внимание, что клиент и служба остаются полностью идентичными, за исключением использования RelayBinding и указания идентификатора URI шины служб (sb://...) . Клиент также будет по умолчанию видеть селектор Windows CardSpace, что позволит клиенту выбрать удостоверение, которое будет затем оправлено службам удостоверений BizTalk для проверки подлинности и авторизации. Если клиенту разрешено отправлять сообщения на указанный идентификатор URI, службы удостоверений BizTalk возвратят маркер, указывающий это, который затем передается службам связи BizTalk в качестве доказательства.
Появление селектора Windows CardSpace в этой ситуации кажется достаточно приемлемым, поскольку речь идет об интерактивном клиентском приложении. Опять же, с помощью служб удостоверения BizTalk можно определить, каким клиентам позволено оправлять что-либо на определенный URI.
Когда службы связи BizTalk получают входящее сообщение от авторизованного отправителя, они просто передают это сообщение экземпляру SalesService, работающему локально. Не стоит особо волноваться, как именно это делается, поскольку данная деталь реализации, скорее всего, изменится в будущем. Однако «за кулисами» привязка RelayBinding использует TcpTransport платформы WCF для подключения к службе подключения BizTalk. При ретрансляции сообщений службы связи BizTalk могут туннелировать через существующее подключение TCP обратно к локальному экземпляру службы.
Почему это было так просто? Поскольку службы подключения BizTalk пользуются стандартными точками разрешения WCF для инкапсуляции подключения и логики ретрансляции как для клиента, так и для службы внутри новой привязки RelayBinding. Возможность вносить фундаментальные изменения в связь путем простого изменения привязки (которое можно целиком проделать в настройке) является одним из реальных преимуществ принятия программной модели WCF.

Варианты ретранслированного подключения
Одним из важных свойств объекта RelayBinding является ConnectionMode. Типом свойства является перечисление, названное RelayedConnectionMode. Этот параметр определяет, как выполняются подключения к службам подключения BizTalk. Службы подключения BizTalk допускают многочисленные режимы связи между отправителями и получателями, предлагающие большую гибкость для конкретных случаев связи (см. рис. 5).
 Рис. 5. Варианты ConnectionMode для RelayBinding
Значение ConnectionMode Описание
RelayedOneWay Подключение установлено на прием и отправку только односторонних операций. Для использования этого параметра все методы в контракте службы должны иметь OperationContractAttribute со свойством IsOneWay, установленным на true.
RelayedDuplex Подключение установлено на поддержку контрактов «запрос-ответ» (включая дуплексные контракты).
RelayedDuplexSession То же, что RelayedDuplex, но настроено на использование WS-ReliableMessaging.
DirectDuplexSession То же, что RelayedDuplexSession с оптимизацией. Первоначальное подключение между отправителем и получателем использует службы подключения BizTalk, но затем попытается создать прямое подключение между двумя узлами, если это возможно. Если прямое подключение может быть создано, отправитель и получатель установят связь без служб связи BizTalk между ними. Если прямое подключение не может быть создано, служба связи BizTalk продолжить предоставлять ретрансляцию для подключения.
RelayedMulticast Подключение настроено на предоставление возможностей публикации/подписки. При этом режиме несколько слушателей могут зарегистрироваться, используя один адрес. Для использования этого параметра все методы в контракте службы должны иметь OperationContractAttribute со свойством IsOneWay, установленным на true.
RelayedHttp Подключение установлено на предоставление конечной точки HTTP через службы BizTalk, которые ретранслируются обратно к службе, работающей на компьютере в локальной сети, даже если эта служба обычно недоступна через Интернет.
RelayedOneWay предназначен для случаев одностороннего обмена сообщениями, так что его можно использовать лишь для операций, помеченных как IsOneWay=true. RelayedDuplex, с другой стороны, предназначен для ситуаций «запрос-ответ», включая дуплексные контракты. RelayedDuplexSession подобен RelayedDuplex, но также позволяет надежный обмен сообщениями внутри стека канала. Это режим подключения по умолчанию, так что именно его мы использовали в предыдущих примерах. Вдобавок, режим DirectDuplexSession является оптимизацией RelayedDuplexSession в том плане, что он пытается создать прямое подключение между отправителем и получателем, если это возможно. Если это невозможно, он возвращается к ретрансляции трафика.
Два последних режима подключения мы разберем подробнее. Во-первых, RelayedMulticast позволяет публиковать/подписываться через WCF – шаблон связи, недоступный от любой из встроенных привязок WCF. Вдобавок RelayedHttp позволяет предоставлять конечные точки на основе HTTP из-за пределов корпоративного брандмауэра или из-за NAT – возможность, которой разработчики добивались с момент появления веб-служб.
Службы связи BizTalk позволяют нескольким слушателям зарегистрироваться на идентификаторе URI, когда первый слушатель указывает RelayedMulticast. Каждое размещение ServiceHost, имеющее конечную точку, прослушивающую на том же идентификаторе URI, косвенным образом становится подписчиком. Когда клиент отсылает сообщение на этот идентификатор URI, сообщение доставляется на все конечные точки служб, подписанных в настоящий момент. Единственное реальное ограничение при использовании RelayedMulticast состоит в том, что, как и для RelayedOneWay, все операции должны быть помечены IsOneWay=true.
Давайте вернемся к нашему предыдущему приложению продаж. Предположим, что в течении дня мы периодически обновляем цены различных продаваемых товаров. Мы желаем передавать цены всем сотрудникам отдела продаж, чтобы они немедленно узнавали об этом. Чтобы это произошло, каждое клиентское приложение может запустить ServiceHost и начать прослушивание одного и того же идентификатора URI, используя привязку RelayBinding с режимом ConnectionMode, установленным на RelayMulticast:
ServiceHost sh = new ServiceHost(typeof(PriceUpdateService));
sh.AddServiceEndpoint(typeof(IPriceUpdateService),
  new RelayBinding(RelayConnectionMode.RelayedMulticast),
  "sb://connect.biztalk.net/services/contososervices/priceupdate");
sh.Open();
...
Каждый клиент выполняет этот код при запуске приложения, так что все клиентские приложения будут подписаны на сообщения, отсылаемые на sb://connect.biztalk.net/services/contososervices/clientupdate. Каждый клиент теперь стал подписчиком с точки зрения этого контракта и идентификатора URI. В данном случае, серверная система играет роль клиента WCF и передает (публикует) широковещательное сообщение для всех подписчиков, как показано здесь: 
static void DoPriceUpdate(PriceUpdate pu) {
  EndpointAddress ea = new EndpointAddress(
    "sb://connect.biztalk.net/services/contososervices/priceupdate");
  ChannelFactory<IPriceUpdateService> cf = 
    new ChannelFactory<IPriceUpdateService>(
      new RelayBinding(RelayConnectionMode.RelayedMulticast), ea);
  IPriceUpdateService service = cf.CreateChannel();
  service.UpdatePrice(pu);
}
Когда вызывается UpdatePrice, сообщение PriceUpdate оправляется службам связи BizTalk, которые ретранслируют это сообщение для всех служб, подписанных на тот же идентификатор URI.

Передача через брандмауэры с помощью RelayedHttp
Режим RelayedHttp позволяет взять службу HTTP, работающую в локальной сети, и сделать ее общедоступной с помощью служб связи BizTalk через HTTP в общедоступной сети, даже если служба обычно не является напрямую доступной из-за пределов локальной сети. Эта функция особенно полезна при использовании в сочетании с новой моделью веб-программирования WCF, которую можно найти в .NET Framework 3.5.
Эта новая модель веб-программирования упрощает применение веб-служб RESTful при помощи WCF. Она также предоставляет функции, упрощающие интеграцию служб WCF в существующие теперь в Интернете инфраструктуры RSS/Atom и AJAX. Службы BizTalk не нуждаются в .NET Framework 3.5, но, с учетом этих новых функций WCF, режим RelayedHttp предоставляет больше функций, когда .NET Framework 3.5 установлена.
Возвращаясь к приложению продаж – порой сотрудники отдела продаж не используют клиентских приложений с широкими возможностями, но их все же нужно уведомлять о последних изменениях цен. Одним интересным способом предоставления часто обновляемых данных является веб-канал – конечная точка HTTP, возвращающая хорошо известные форматы XML, такие как RSS или Atom, приложениям, которые знают, как пользоваться этими каналами. Веб-каналы можно опрашивать на предмет нового содержимого по установленному расписанию с помощью средства чтения каналов (программы, которая сводит веб-каналы в обращенный к пользователю интерфейс). Это позволяет конечному пользователю получать обновления, не переходя на веб-узел прямо, но глядя на его средство чтения каналов.
Используя модель веб-программирования WCF, можно легко создать веб-канал, предоставляющий данные об изменении цен. В первую очередь нам нужен контракт, использующий новые атрибуты WCF, чтобы сделать возможными вызовы HTTP. Эти атрибуты информируют уровень обмена сообщениями WCF о том, как маршрутизировать входящие запросы HTTP к методам в службе, основываясь на идентификаторе URI, а не на заголовке действия SOAP. Приведу пример:
[ServiceContract]
public interface IPriceUpdateFeed {
  [OperationContract()]
  [WebGet(UriTemplate = "*")]
  Atom10FeedFormatter GetPriceUpdate();
}
Здесь WebGetAttribute говорит платформе WCF, что этот метод следует вызывать каждый раз, как в службу пребывает запрос HTTP GET (в отличие от запросов SOAP, всегда использующих HTTP POST).
Также обратите внимание на свойство UriTemplate на WebGetAttribute. Оно говорит WCF, как именно маршрутизировать входящие сообщения различным методам, основываясь на идентификаторе URI входящего запроса. Этот пример использует шаблон подстановочного знака ("*"), чтобы указать, что нам нужно маршрутизировать все запросы GET к этому конкретному методу. В службе можно легко настроить несколько методов, каждый из которых обрабатывает отдельный шаблон UriTemplate. Также имеется WebInvokeAttribute, который можно использовать, когда нужно ответить на другие глаголы HTTP, помимо GET (включая POST, PUT, DELETE и HEAD).
Кроме того, в этом контракте следует отметить тип возврата метода. В модель веб-программирования WCF входят новые типы, разработанные специально для того, чтобы помочь в создании стандартных форматов потоков. Два крупных формата, поддерживаемых сейчас, – это Atom и RSS. Приведенный здесь пример использует формат Atom.
На рис. 6 показана простая реализация операции GetPriceUpdate, предоставляющей канал централизованного распространения Atom. В этой реализации используется новый интерфейс API SyndicationFeed, чтобы предоставить логический канал, который она возвращает обернутым в объект Atom10FeedFormatter, чтобы предоставить верный формат XML.
 Рис. 6. Создание веб-канала 
public Atom10FeedFormatter GetPriceUpdate() {
  SyndicationFeed feed = new SyndicationFeed("Product Update Feed",
    "", null);
  List<SyndicationItem> items = new List<SyndicationItem>();
  feed.Items = items;
  IEnumerable<Product> products = GetUpdatedProducts();
  string iText = "Product update for {0}. Old price={1}. New Price={2}";
  foreach (var product in products) {
    items.Add(new SyndicationItem("Product update for " + product.Name,
      String.Format(iText, product.Name, product.OldUnitPrice,   
      product.UnitPrice),
      null, 
      product.Name, 
      product.UpdatedTime));
  }
  return new Atom10FeedFormatter(feed);
}
Теперь необходимо настроить конечную точку, которая будет слушать эти запросы. В составе WCF 3.5 поставляется новый класс привязки, чтобы упростить настройку конечной точки. Класс WebHttpBinding инкапсулирует подробности создания стека канала RESTful, не ожидающего сообщений SOAP. Он просто использует транспорт HTTP и кодировщик текстовых сообщений от WCF с версией сообщений кодировщика, установленной на None («Отсутствует»). Вот код, необходимый, чтобы подключить и заставить работать новую конечную точку:
ServiceEndpoint se = 
  sh.AddServiceEndpoint(typeof(IPriceUpdateFeed), 
  new WebHttpBinding(), "http://localhost:8099/ProductFeed");
se.Behaviors.Add(new WebHttpBehavior());
...
Обратите внимание, что конечная точка WebHttpBinding настраивается с помощью экземпляра WebHttpBehavior, внедряющего необходимую логику диспетчеризации на основе HTTP в среду исполнения. После того, как размещение ServiceHost приступило к работе, используя свеженастроенную конечную службу, можно перейти к идентификатору URI HTTP, который слушает служба, по адресу localhost:8099/ProductFeed и увидеть поток Atom.
Теперь предположим, что этот поток необходимо предоставить сотрудникам отдела продаж вне внутренней сети. Вместо того, чтобы открывать этот компьютер через брандмауэр, можно просто использовать службы связи BizTalk для ретрансляции трафика HTTP локальной службе. Мы проделываем это, добавляя еще одну конечную точку с помощью RelayBinding, но указывая RelayedHttp для ConnectionMode, как показано здесь:
ServiceEndpoint se = 
  sh.AddServiceEndpoint(typeof(IPriceUpdateFeed),
  new RelayBinding(RelayConnectionMode.RelayedHTTP),
  "http://connect.biztalk.net/services/contososervices/ProductFeed");
se.Behaviors.Add(new WebHttpBehavior());
...
После всего этого наша веб-служба теперь безопасно открыта общедоступной сети, но логика размещается на внутреннем сервере. На рис. 7 можно увидеть этот поток открытым через общедоступный из Интернета идентификатор URI. Само собой, поток выглядит точно так же, и теперь находящиеся в пути сотрудники отдела продаж могут подписаться на поток и получить обновления безо всяких осложнений, связанных с VPN, брандмауэрами или проблемами сети.
Рис. 7. Предоставление службы HTTP через службы связи BizTalk (щелкните изображение, чтобы увеличить его)

Настройка служб удостоверений
Вне зависимости от режима подключения, используемого для RelayBinding, как слушатель (служба), так и отправитель (клиент) должны подвергнуться проверке подлинности и авторизации службами удостоверений BizTalk. Проверка подлинности – это процесс определения клиента или запрашивающего на основе первоначального набора заявок. Авторизация – это процесс применения набора определенных пользователем правил авторизации на этом первоначальном наборе заявок.
Авторизация правил просто создает новый набор заявок через серию преобразований заявок (каждое правило соответствует набору входящих и набору исходящих заявок). Первоначальный набор входящих заявок предъявляется службам удостоверений BizTalk тем, кто подал запрос. Сейчас службы удостоверений BizTalk поддерживают три типа первоначальных наборов заявок: имя пользователя/пароль, сертификат клиента и управляемые карты. В случае имени пользователя/пароля имя пользователя является первоначальной заявкой, а пароль – подтверждающим ее свидетельством.
Службы удостоверений BizTalk начинают обработку правил авторизации, используя заявку имени пользователя как стартовую точку для предоставления исходящих заявок. По мере создания новых заявок они могут становиться входящими заявками для других правил, допуская, в некоторой степени, создание цепочек правил. Окончательный набор исходящих заявок содержится в маркере, возвращенном службами удостоверений BizTalk. При попытках доступа к службам связи BizTalk должны присутствовать определенные исходящие заявки.
Службы удостоверений BizTalk также можно настроить с помощью сертификата, чтобы защитить производимые ею маркеры. При настройке сертификата предоставленный запрашивающему маркер будет зашифрован с помощью открытого ключа из сертификата, что сделает его более защищенным при передаче и менее подверженным манипуляциям клиентов в ходе передачи.
Существуют несколько способов настройки этих правил авторизации. Один из них состоит в использовании интерфейса пользователя, предоставленного на веб-узле служб BizTalk (см. рис. 8). Другим способом является программное использование интерфейса API управления удостоверениями, имеющегося в комплекте SDK. Недавно была выпущена также версия данного интерфейса для RESTful.
Рис. 8. Пользовательский интерфейс сопоставления заявок веб-узла служб BizTalk (Щелкните изображение, чтобы увеличить его)
При настройке правил авторизации стоит подумать о том как используются службы удостоверений BizTalk. Опять же, службы удостоверений BizTalk можно использовать как общую STS или как механизм контроля доступа к службам связи BizTalk.
При использовании служб удостоверений BizTalk в качестве общей STS можно сопоставлять входящие заявки имени пользователя с любой исходящей заявкой. Исходящая заявка будет помещена в получившийся маркер, который будет затем представлен другим сторонам. При использовании его подобным образом необходимо иметь минимум одно правило, где входящей заявкой является имя пользователя. Дополнительные правила можно добавить в каскад, основываясь на новых исходящих заявках – например, беря исходящую заявку, произведенную правилом имени пользователя в качестве входящей заявки для другой исходящей заявки, что позволяет построить любой набор исходящих заявок. См. образцы контроля доступа в комплекте SDK для служб BizTalk, чтобы увидеть полный пример.
Чтобы проверять подлинность с помощью служб связи BizTalk, необходимо настроить службы удостоверений BizTalk с помощью нескольких конкретных правил. Как уже упоминалось, необходимо иметь минимум одно правило, где входящей заявкой является имя пользователя, а также можно иметь каскадные правила.
В чем службы связи BizTalk уникальны, так это в том, что они ожидают найти исходящую заявку Resource#Operation в окончательном маркере, где ресурсом должен быть идентификатор URI прослушивания службы, а операцией Listen («Прослушивание») либо Send («Отправка»). Например, {URI}#Listen позволяет пользователю запустить прослушивание конечной точки службы на указанном идентификаторе URI, тогда как {URI}#Send позволяет пользователю отправить сообщение на указанный идентификатор URI.

Специальные поставщики маркеров
Ранее упоминалось, что для серверного приложения необычно наличие интерактивного экрана входа в систему, каким представляется селектор Windows CardSpace, когда сервер начинает прослушивание. Это происходит потому, что каждая конечная точка, использующая RelayBinding, применяет объект, реализующий интерфейс ITokenProvider. Реализацией по умолчанию для этого интерфейса является CardspaceTokenProvider, заставляющий селектор Windows CardSpace появиться при выполнении подключения к службе подключения BizTalk Connectivity Services.
Помимо CardspaceTokenProvider, в комплекте SDK есть еще несколько реализаций ITokenProvider. UsernameTokenProvider получает маркер, использующий зарегистрированное имя пользователя и пароль от служб удостоверения BizTalk. AutomaticRenewalTokenProvider вызывает появление селектора Windows CardSpace, но он автоматически получит новый маркер по истечении текущего, делая возможным однократную настройку конечных точек. Обе эти реализации также являются поведениями конечных точек, которые можно добавить к серверной или клиентской конечной точке для замены стандартного CardspaceTokenProvider.
Наша служба теперь может избежать интерактивного входа в систему, настраивая UsernameTokenProvider на своей конечной точке перед вызовом ServiceHost.Open, как показано ниже:
ServiceHost sh = new ServiceHost(typeof(SalesService));
ServiceEndpoint se = sh.AddServiceEndpoint(typeof(ISalesService),
  new RelayBinding(),
  "sb://connect.biztalk.net/services/contososervices/SalesService");
UsernameToken token = new UsernameTokenProvider("someusername", 
  "somepassword");
se.Behaviors.Add(token);
sh.Open();
...
Так что теперь при запуске процесса службы он автоматически проведет проверку подлинности с помощью служб удостоверений BizTalk безо всякого человеческого вмешательства. Альтернативные реализации ITokenProvider также могут быть настроены на конечную точку RelayBinding путем простого добавления реализации как поведения конечной точки (базовый класс TokenProvider, имеющийся в комплекте SDK, применяет и ItokenProvider, и IEndpointBehavior).

Как приступить к работе
Если вы хотите приступить к работе с BizTalk Services, сперва перейдите на labs.biztalk.net и создайте учетную запись. Потребуется гарантировать наличие установленной .NET Framework 3.0, после чего можно будет загрузить и установить комплект SDK для служб BizTalk. Получив учетную запись и установив на своем компьютере комплект SDK, можно будет воссоздать примеры, приведенные в этой статье. Само собой, имя учетной записи, используемое в интерфейсе URI, надо будет изменить с "contoso" на имя своей учетной записи. Кроме того, комплект SDK поставляется с дополнительными примерами для пользователей, которые могут помочь проиллюстрировать некоторые из освещенных здесь концепций. Если после начала работы возникнут дополнительные вопросы, не забудьте посетить раздел часто задаваемых вопросов на веб-узле служб BizTalk. Удачи!

Джон Фландерс (Jon Flanders) - независимый консультант, лектор и инструктор в компании Pluralsight. Он специализируется на Windows Workflow Foundation, BizTalk Server и Windows Communication Foundation. Связаться с Джоном можно по адресу masteringbiztalk.com/blogs/jon.

Аарон Сконнард (Aaron Skonnard) является соучредителем компании Pluralsight, основного поставщика обучения по Microsoft .NET. Аарон – автор многочисленных книг, технических статей и документов, а также курсов «Pluralsight's Applied Web Services 2.0», «Applied BizTalk Server 2006» и «Applied Windows Communication Foundation». С ним можно связаться по адресу pluralsight.com/aaron.
Page view tracker