Использование веб-службы BizTalk для повторной публикации внутренней веб-службы

Объем вашего вопроса довольно велик, и я думаю, что ответ на него, вероятно, не очень подходит для формата SO «Q + A».

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

Я построил быстрый и грязный пример (BTS 2010 / VS 2010) и загрузил его на GitHub здесь ( скачать исходник в виде zip справа внизу)

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

Создайте новое решение в Visual Studio

Добавить проект службы WCF и опубликовать его в IIS (область действия не рассматривается в этом примере)

• Использовал проект WCF VS2010 по умолчанию и назвал проект WCFService
• Используется basicHttpBinding для простоты, но, очевидно, можно использовать и другие привязки (но потребуются дополнительные проблемы, такие как безопасность и т. д.)
• Обратите внимание, что NameSpace на ServiceContract, ServiceBehavior и в веб-конфигурации для behaviour namespace все были установлены (в противном случае по умолчанию они будут tempuri)

Добавьте в решение 4 новых проекта BizTalk:

Я назвал их BizTalkWCF.Orch, BizTalkWCF.Maps, BizTalkWCF.WCFPorts и BizTalkWCF.Schemas.

Сначала WCFPorts

• Щелкните правой кнопкой мыши проект WCFPorts и выберите «Добавить», затем «Созданные элементы».
• Выберите Использовать службу WCF.
• Проверьте конечную точку обмена метаданными (Mex)
• Укажите URL-адрес вашей службы WCF (например, http://localhost:57582/Service.svc)
• Оставьте пространство имен (BizTalkWCF.WcfPorts)
• Завершите работу мастера — теперь должны присутствовать артефакты WCF.
• Если вам нужно импортировать более одной веб-службы, я бы посоветовал вам создать отдельные папки решений Visual Studio для каждой из них.

Поскольку мы разделили проект в BizTalk (что, как правило, является хорошей идеей), к сожалению, мастер пометит все импортированные артефакты как внутренние, что не очень полезно, если на них есть ссылки из других сборок. Откройте импортированную сгенерированную оркестровку (MyService.odx) (примечание: никогда не удаляйте и не перемещайте этот ODX, поскольку он содержит сгенерированные порты — просто оставьте его со сгенерированными артефактами WCF).

В представлении оркестровки внизу откройте типы. В разделе «Типы портов» вы должны увидеть интерфейс WCF (IService). Щелкните его и измените модификатор типа свойства на «Общедоступный». Сделайте то же самое для типов сообщений, состоящих из нескольких частей (4 x IService_* — обратите внимание, что существует 2 типа сообщений для каждого метода WCF в службе (один для запроса, один для отклик).

Теперь должен быть построен проект портов WCF.

Далее идет проект Schemas. Добавьте 2 x Schemas, представляющих то, что будет представлено (опубликовано) из BizTalk (я назвал их BizTalkServiceRequest и BizTalkServiceResponse). Этот пример просто обеспечивает тонкий фасад базовой службы WCF. , поэтому я только что получил поля, аналогичные исходной службе WCF, в запросе и ответе с теми же типами xs. Обратите внимание, однако, что концепция «сущности» в базовой службе WCF была заменена сообщениями запроса и ответа. Однако возможен рефакторинг и повторное использование общих элементов в схемах (xsd:import) в нескольких сообщениях. Я только что использовал пространства имен по умолчанию и узел «Root», но обратите внимание, что они будут видны вашим потребителям услуг BizTalk, поэтому в реальном проекте вам следует подумать об этом подробнее.

Обратите внимание, что мы не использовали повторно импортированные/сгенерированные схемы службы WCF. На комплексном предприятии также может использоваться 3-й набор схем, «канонические» схемы, которые не зависят как от форматов, используемых потребителем службы BizTalk, так и от потребляемой службы (и также потребовалось бы больше карт).

Далее идут сопоставления между входящим запросом и входной схемой WCF, а затем еще одно сопоставление для ответа от выходной схемы WCF обратно к потребителю службы BizTalk. В проекте карты добавьте ссылки .Net как на проект WCFPorts, так и на проект Schemas. Добавьте новую карту в проект карты. Для исходной схемы найдите схемы, на которые ссылаются, — схему BizTalkServiceRequest. Для схемы назначения выберите схему портов WCF (искаженное имя ужасно, но это будет имя с MyService, а не схемы данных или схемы Microsoft). Обратите внимание, что затем вам необходимо выбрать, какую из содержащихся схем вам нужно использовать. Выберите схему GetDataUsingContract. Под элементами перетащите мышь от исходного элемента Name к целевому значению схемы и от IsAddSuffix к элементу BoolValue. Сделайте то же самое для ответного сообщения — очевидно, на этот раз сообщение WcfResponse является источником, а открытый ответ BizTalk — получателем. Логическое значение бесполезно в ответе, поэтому отображается только строковое значение. Карты теперь должны компилироваться.

Последним проектом является оркестровка

• Добавить ссылку на проекты Maps, Schemas и Ports
• Добавьте новую оркестровку (я назвал AddServiceOrchestration).
• Вам нужно будет добавить порт получения (добавлен слева) и порт отправки (справа).
• Порт отправки использует существующий импортированный порт WCF (который мы сделали общедоступным ранее). Я отправлю запрос и получу ответ.
• Привязка порта выберите Прямая привязка и маршрутизация по выражению фильтра.
• Для порта получения вам необходимо создать новый тип порта — ответ на запрос. Получение запроса, отправка ответа и снова Прямая привязка, с маршрутизацией через выражения фильтра.
• Опять же, вам нужно сделать порт общедоступным
• Вам нужно будет установить типы сообщений в порту получения как для запроса, так и для ответа (нажмите на запрос и ответ, а затем найдите типы сообщений в сборке схем)
• Формы в оркестровке должны быть понятными и простыми — в основном просто привяжите порты для получения и отправки фигур, а затем используйте карты в формах преобразования.
• Начальная форма приема — это активация.

Создать + опубликовать

Теперь все должно быть построено, поэтому пришло время опубликовать его в BizTalk (я предположил, что это локальный сервер). Сейчас мы опубликуем оркестровку с помощью мастера и будем использовать IIS для доступа к открытой веб-службе, хотя обратите внимание, что Biztalk также может сам хозяин. Не забудьте установить имя приложения на вкладке «Развертывание» для всех 4 проектов Biztalk (иначе они попадут в приложение по умолчанию). Кроме того, помните, что сборки BizTalk должны быть подписаны, поэтому создайте .SNK (вкладка «Подписание»).

Щелкните решение правой кнопкой мыши и выберите Развернуть. (Обратите внимание, что проект должен быть создан + развернут, прежде чем вы сможете использовать мастер публикации для предоставления службы). При условии успешного развертывания вам необходимо настроить оркестровку (другой Orch — это тот, который создается импортом WCF — он владеет порты WCF) Создайте порт отправки ответа на статический запрос — WCF basicHttpBinding, укажите его URL-адрес веб-службы WCF. Вы можете получить действие SOAP из WCF WSDL, например. YourNameSpaceHere/IService/GetDataUsingDataContract Добавьте фильтр к порту отправки сообщения (xmlns#root), например, YourNameSpaceHere#GetDataUsingDataContract

Вернувшись в Visual Studio, вы можете опубликовать Orch как веб-службу (Инструменты: мастер публикации BizTalk WCF Services). Включите публикацию метаданных. Я снова использовал basicHttpBinding. И создайте Receive Port, выбрав приложение (BizTalkWCFSample)

При появлении запроса выберите сборку, содержащую Orchestrations (BizTalkWCF.Orchs). Вам также будет предложено установить целевое пространство имен службы WCF. пространство имен такое же.

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

Теперь вам нужно запустить приложение BizTalk — решить все нерешенные проблемы с конфигурацией (например, назначить orch для процессов)

Вам понадобится новый пул приложений .Net 4 в IIS (назовите его как-то вроде BizTalkIsolatedHost),
А затем переместите созданное мастером приложение в IIS в этот пул приложений. Теперь вы сможете перейти к «конечной точке» Orchestration. , например: http://localhost/BizTalkWCF.Orchs/BizTalkWCF_AddSuffixService_RcvSuffixService.svc

Подводя итоги: оно того стоило?

Как вы можете видеть из вышеизложенного, повторное представление веб-службы в BizTalk требует довольно много работы, и мы на самом деле не добавили никакой ценности в BizTalk, за исключением, возможно, некоторой возможности отслеживания и повторных попыток BizTalk :) . При оркестровке составной службы (для выполнения одного входящего запроса требуется несколько вызовов серверной службы, а также при использовании канонических схем) потребуется учитывать гораздо больше схем и карт, а также дополнительные сложности с оркестровкой. А при работе с веб-сервисами вы очень быстро получаете большое количество артефактов (схем, карт, сообщений, портов и т. д.), поэтому строгое соглашение об именах имеет важное значение.

И мы не учли такие вещи, как обработка исключений, повторные попытки и т.д.

Итак, просто проверка работоспособности, прежде чем планировать публикацию сотен сервисов таким образом, я думаю, нам нужно рассмотреть другие технологические альтернативы:

• Инструментарий BizTalk ESB (особенно если на вашем предприятии существует определенная степень общности и/или вы контролируете потребителя услуг)
• Другие ESB (Mass Transit, NServiceBus, ServiceMix и т. д. или самодельные автобусы, построенные на Camel, Mule, Drools, Rabbit, Windows Service Bus и т. д.), возможно, с настраиваемым фасадом для отображения «конечных точек» веб-сервисов.
• Для массовых «фасадов услуг» Microsoft приступила к созданию прототипа многообещающей технологии под названием Managed Service Engine но, к сожалению, это похоже на лед.