Category Archives: Microsoft

Лучший Сервер приложений от Microsoft

Рассмотрим разные типы приложений.

Приложение для последовательной обработки

Приложение этого типа однопотоковое. Приложение получает массивы данных  и обрабатывает их одно за другим. BatchProcessing

 Типичный представитель этого типа – программа для обработки файлов. Программа считывает файл и обрабатывает его, потом считывает следующий файл и т.д. Программа сама инициирует обработку. Она работает с данными последовательно, обработала одну порцию данных — запрашивает следующую порцию.

В качестве сервера приложений этого типа работает сама операционная система. Программа запускается либо пользователем, либо по старту операционной системы. Windows service – это один из типов подобного приложения, для него Windows предоставляет дополнительные возможности, такие, как автоматический рестарт в случае ошибки.

Приложение – сервис

Программа-сервис постоянно ожидает запрос от клиента.  Если одновременно поступает много запросов, они ставятся в очередь на обработку. ShortRunningTransactions

Типичный представитель приложений этого класса – веб-сайт. Сервер приложений этого типа – Internet Information Server (IIS). Для каждого пользовательского запроса запускаеся отдельный процессорный поток, который завершается после выдачи результата пользователю. Если в приложении для последовательной обработки всегда работает только одна копия приложения, то здесь работают сразу несколько копий сервиса, по одной на каждый пользовательский запрос.  Обычно приложение не хранит данные клиента. Если по какой-то причине копия сервиса завершает работу с ошибкой и клиент не получает результат, клиент просто повторяет запрос и запускается другая копия сервиса. Данные хранит клиент, а не сервис. Сравним приложение-сервис с приложением для последовательной обработки. Последнее может обрабатывать только одну порцию данных одновременно. Кроме того обработка в нем не изолирована в отдельных копиях, и ошибка в обработке приведет к краху не одной копии, как в приложении-сервисе, а краху всего приложения. Надежная работа приложения-сервиса возможна тогда, когда приложение выполняет свою работу за короткое время. Если это время составляет часы и дни, то многократно возрастает возможность сбоя сервера приложения, соответственно уменьшается надежность тех копий приложения, которые во время краха находятся в памяти.

Приложение – долгоживущий сервис

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

LongRunningTransactions

Другая проблема долгоживущих сервисов – корреляция запросов.

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

В идеале механизм корреляции тоже обеспечивается сервером приложений.

Другая проблема долгоживущих сервисов – очистка от “умерших” копий сервиса. К примеру, сервис делает запрос к внешнему сервису и не получает ответа в течение определенного времени. Внешний сервис может не работать, либо сеть может быть перегружена, причин задержки может быть много. В другом случае копия сервиса просто подвисает, а не завершается с ошибкой. Один из популярных методов очистки «умерших» копий сервисов — «измерение пульса». Специальный сервис периодически запрашивает все копии сервиса и, если какое-то из них не отвечает, оно считается «умершим» и удаляется из памяти.

При запросе внешних сервисов регулярно возникают ситуации, когда запросы завершаются ошибкой. Причем ошибки обычно носят временных характер. К примеру, сеть прегружена или база данных перегружена или очередь ввода-вывода переполнена или внешний сервис занят обработкой других запросов. В таких случаях запрос надо повторить после небольшой задержки и так несколько раз. Ошибка будет выдана только тогда, когда было безрезультатно сделано заданное количество повторов.

Таким образом для долгоживущих сервисов возникает необходимость в дополнительных функциях сервера приложений:

  • хранилище данных копий сервисов;
  • системе корреляций запросов;
  • системе мониторинга и удаления «умерших» копий сервисов;
  • системе повтора запросов внишним сервисам

Как оказалось в арсенале Microsoft есть сервер приложений с подобными функциями. Это BizTalk Server.

Его база данных под названием Почтовый Ящик обеспечивает надежное хранилище данных. Копии сервисов могут выгружаться в это хранилище и ждать как угодно долго данных от внешних сервисов. Тысячи, десятки тысяч, сотни тысяч копий сервисов могут ожидать своей очереди, при этом производительность всей системы не страдает.

В Почтовый Ящик встроена система корреляции запросов. Пришедшие извне запросы анализируются и либо попадают к копии сервиса, которое ожидает именно этот запрос, либо запрос запускает новую копию сервиса.

Постоянно «измеряется пульс» и производится очистка памяти от «умерших» или завершенных копий сервисов.

Система вывода обеспечивает автоматическое повторение запросов внешним сервисам.

И самое главное качество BizTalk Server в качестве сервера приложений, это его надежность. Запущенные сервисы работают годами без присмотра. Пропадает электричество, «падают» сервера, пропадает сеть, ломаются жесткие диски. Но данные не пропадают. BizTalk автоматически перезапускается, прерванные сотни, тысячи копий сервисов восстанавливаются и продолжают работать как ни в чем ни бывало. Для этого работа в BizTalk Server элементарно распределяется между несколькоими компьютерами, а данные хранятся в SQL кластерах.

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

Filed under BizTalk, Integration Architecture, Microsoft

BizTalk Summit 2012: возрождение

В Microsoft кончились разговоры о плавном перерождении BizTalk Server в Azure. Microsoft восстанавливает инвестирование в BizTalk в полном объеме (?) Ура!

Несколько факторов стали решающими:

  • Влияние проходящего, вяло текущего кризиса
  • Поднимающаяся волна обновлений версий BizTalk Server
  • Давление клиентов и партнеров
  • Microsoft стал зарабатывать на BizTalk

Все это мы узнали на прошедшем в Рэдмонде саммите, посвященном одному продукту Microsoft, BizTalk Server.

Cам факт этого саммита уже говорит о многом. Я не припоминаю подобных мероприятий в последнее время, посвященным отдельным продуктам.
Открывал конференцию большим докладом Scott Guthrie. Ничего конкретного я тут сказать не могу, саммит проходил на условиях NDA, т.е. почти все, что нам рассказывали, было секретом. То, что я здесь рассказываю, является результатом моих умозаключений и не представляет собою официальную точку зрения Microsoft.

Теперь поподробнее об этих самых факторах.

Кризис привел к большому числу банкротств и слияний.  Чем не повод к новым интеграционным проектам.  BizTalk хорошо показывает себя именно в ситуациях с большим числом разнообразных протоколов, программ, форматов, технологий.

Оканчивается срок гарантийной поддержки BizTalk Server 2006, той самой версии с которой и начался бум внедрений BizTalk. Старые версии работают по-прежнему надежно, но вот техника с тех пор прошла не один круг модернизации. Надо ставить новую технику, к которой есть запчасти. Это тянет за собою обновление операционной системы. А это приводит к тому, что надо менять и BizTalk Server, потому что старая версия BizTalk работает только на старой версии операционной системы. Обновили сервера, обновили ОС, обновили и BizTalk.

Microsoft несколько лет назад решило, что эволюционный путь технологий неизбежно приведет к перерождению BizTalk в набор сервисов, которые сейчас значатся под общим маркетинговым именем Azure. Но этого не произошло. И не из-за недостатков Azure, а по более глубоким причинам. Главные из которых, это надежность BizTalk и консерватизм рынка. Рынок у BizTalk – это рынок больших корпораций. Интеграция для них – не метод для бурного роста, для инноваций, совсем нет. Для них это — возможность повысить эффективность основных бизнес-процессов. А эти основные процессы в больших корпорациях очень консервативные. Они и должны быть такими, потому что они должны быть надежными, надежными и еще раз надежными. К примеру,  финансовые транзакции можно пропускать только через систему, которая уже доказала свою надежность многими годами работы. 12 лет BizTalk на этом рынке, и только в последние годы корпорации начали использовать его на жизненно-важных процессах. Пройдет еще лет 5 и они начнут серьезно рассматривать Azure, если она покажет себя  надежно.

BizTalk очень часто – первая серверная система от Microsoft, которая проникает в большую корпорацию. До него там работали только мэйнфреймы, IBM, Oracle, SAP. И BizTalk играет роль тарана, пробивающего брешь в мощной и серьезной обороне. Специалисты этих корпораций убеждаются, что Microsoft, несмотря на “детские” по их масштабам цены, поставляет серверные системы со взрослыми характеристиками. За BizTalk следуют SQL Server, Windows Server. Оброна прорвана. И Microsoft начинает ощущать это с помощью хорошего датчика, своего банковского аккаунта.

Корпорациям не нужны иновации ради иноваций, им важнее гарантии, что купленная система будет стабильно развиваться и будет обеспечена поддержкой на многие годы вперед. Корпорациям не нужны не подтвердившие свою надежность и стабильность Azure, cloud (пока не подтвердившие). Им нужны от Microsoft стабильные инвестиции в BizTalk, SQL, Winsows.

А что надо для счастливой жизни интеграцинной системы, что надо для счастливой жизни BizTalk Server? Нужны умные головы, которые будут работать над системой долгие годы за хорошие деньги. Общее впечатление от саммита как раз в этом, хорошая команда с большими амбициями собрана в Microsoft на дальнейшее развитие BizTalk Server.

Вот такие оптимистичные настроения навеял на меня прошедший BizTalk Summit 2012.

1 комментарий

Filed under BizTalk, Заметки, Microsoft, MVP

BizTalk next

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

Microsoft Virtual Academy

Evaluation Download Center

TechNet Cloud Hub

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

Filed under BizTalk, Certification, Microsoft

BizTalk course: 10 Orchestrations

Theory:

Теории здесь на несколько дней.

Practice:

  1. В Проект №1 (совсеми последующими улучшениями) добавить orch OrderShipping, которое принимает все OrderDetails, адресованные отдельной ShippingCompany. Сделать его, используя шаблон Unified Sequencial Convoy. Первое сообщение OrderDetails будет активировать отдельную orch instance для отдельной ShippingCompany. Последующие сообщения OrderDetails будут обрабатываться этой же instance. Все OrderDetails объединяются в одно сообщение OrderDetailsSummary (cделать схему этого сообщения).  OrderDetailsSummary завершается после объединения 5 сообщений OrderDetails ИЛИ через 10 минут после старта. OrderDetailsSummary выводится в FILE Send port.
  2. Добавить еще один FILE Send port, который будет отлавливать и выводить сообщения FailureReport. Смоделировать ошибки в orch  и убедиться что информация об ошибке доставляется на этот порт.
  3. Добавить SMTP Send port, который будет отлавливать и отправлять по почте информацию об ошибках.
  4. Tracing: во все orch добавить Expression shapes в след.местах: в начале/конце orch; после создания/receive/send всех сообщений; после ветвления в шейпах с несколькими ветвями; после начала каждого нового цикла в Loop. В Expression shapes добавить вывод отладочной информации: содержимое новых сообщений, измененных переменных и т.п. Использовать DebugView, чтобы вывести эту отладочную информацию.
  5. Tracking: включить полный Tracking для всех orch и портов. Отследить: прохожение сообщений; содержимое сообщений во всех возможных точках; контекст сообщений.
  6. to be continued…

Практики по этой части будет еще много.

3 комментария

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 09 Maps

Что учим:

Maps: практика и еще раз практика. Теории здесь мало.

Основные моменты в трансформациях:

  • Изменения в уровнях вложенности.
  • Schema paremeters: MinOccurs and MaxOccurs
  • Преобразования в/из Empty и Null значения.
  • Условные преобразования
  • Коды, их использование, генерация, lookup
  • Script functoids: in-line code; Xslt-code; Xslt-templates
  • Использование pure Xslt.

Задания:

  1. Сделать map схемы Order.xsd в схему ShippingOrder.xsd. Это пример на трансформацию схемы с глубокой иерархией узлов в так называемую «плоскую» схему. [Файлы схем надо сохранить и переименовать, удалив .doc в конце.]
  2. Сделать обратное преобразование: map схемы ShippingOrder в Order.
  3. Условные преобразования: При преобразовании из п.1 использовать такую логику: TotalAmount = Quantity * Price * (100%+Tax). Tax определяется по полю CompanyOriginator.Address.StateProvince: если WA, то Tax = 10%, если CA, то Tax = 8.5%, если BC, то Tax = 12%. Могут быть только три вышеперечисленных значения.
    1. при преобразовании использовать только обычные фанктоиды. Script functoid не испльзовать.
    2. использовать Script functoid: Inline C#
    3. использовать Script functoid: Inline Xslt
    4. использовать Script functoid: Inline Xslt call template
  4. В Order_to_ShippingOrder map для nodes OrderDetail.item и company name добавить дополнительную логику: если node is Null, то в ShippingOrder должно получиться не Null, а Empty string, т.е.пустая строка («»). Соответсвенно изменить схему Order, чтобы эти nodes могли быть null. Использовать те же четыре метода из предыдущего пункта.
  5. В Order_to_ShippingOrder map для nodes Order. добавить дополнительную логику: если StateProvince в полном виде (к примеру Washington), то сделать преобразование в кодWA. Если уже WA, то использовать то, что есть. Если ошибка в StateProvince, то использовать то, что есть. Только для тех StateProvince, которые перечислены в п.3.
  6. Повторить п.5, но для преобразования сделать и использовать  дополнительный C# проект …Helper , класс MapHelper.

В качестве образца с удовольствием рекомендую проект Андрея Кошелева.

5 комментариев

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 07 Проект №1

Проект №1

User Requirements:

  • Система обработки заказов
  • Xml документы  Order приходят от разных заказчиков в файловый фолдер.
  • Order состоит из шапки и из нескольких Order Detail строк. Каждая строка – это описание заказа для отдельного продукта.
  • Есть три типа продуктов. Продукт каждого типа поставляет отдельная Shipping компания.
  • Xml документы Shipping доставляются в виде файлов в файловые фолдеры. Есть три фолдера, каждый для отдельной Shipping компании.

Implementation requirements

  • Из каждого документа Order делается несколько документов Shipping. Один Shipping на каждую Order Detail строку.
  • Для преобразования  Order в Shipping-s обычно используется два метода:
    • Disassemble в pipeline, используя envelope cхему (google with “BizTalk disassembler”)
    • Disassemble в orchestration, преобразовывая сообщение в объект XmlDocument , далее в string, потом выделяя Order Detail помощью XPath выражения. Т.е.манипуляцией strings. (google with “BizTalk debatching”)
  • Используйте любой из методов, на свое усмотрение. Как это делать, найдите в интернете. Можете использовать код в BizTalk SDK и код из многочисленных блогов.
  • Прочитайте теорию в http://msdn.microsoft.com/en-us/library/aa577393(v=BTS.70).aspx . Не забудьте прочитать все статьи включающие в себя вышеназванную статью.
  • Схемы для Order, Order Detail,  Shipping делайте на свое усмотрение. Maps – тоже.
  • Проект считается готовым, когда тестовые файлы пройдут от входного фолдера  к выходным фолдерам.
  • Мне пришлите файлы проекта в zip файле.  Кроме того пришлите мне сэкспортированные отдельные файлы deployed application: msi и bindings.
  • Время на весь проект: для опытного BizTalk developer – 1 час, для entry level — >5 часов.

Дополнение: Вначале я задал требование по созданию Canonical Order. Это требование отменяется.

4 комментария

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 06

1. Virtual Lab http://www.microsoft.com/biztalk/en/us/virtual-labs.aspx
BizTalk Server 2009: Integration with  POP3 and SharePoint and Routing Failed Messages

2. Отвечаем на вопросы:

  • Как можно принять сообщения в BizTalk используя email?
  • Как можно отправить сообщения из BizTalk используя email?
  • Почему для принятия и отправки сообщений email используются разные адаптеры?
  • Как можно принять/отправить Xml сообщение, используя email?
  • Приведите 3 сценария, когда нам нужно использовать именно email и ничто другое.
  • Чем email адаптеры отличаются от FILE адаптера?

6 комментариев

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 05

Всем привет.

Начинаем выходить из виртуального мира и работать на своем компьютере, хотя и в виртуальной машине 🙂

1. 2-4 часа
 Tutorial 1: Enterprise Application Integration. Это практически повторение Virtual labs, но уже на своем компьютере.

2. Отвечаем на вопросы:

  • Чем EAI (Enterprise Application Integration) отличается от B2B (Business To Business)? [будет хорошо, если сходите в Wikipedia за определениями]
  • Чем BizTalk adapters отличаются от bindings in WCF?
  • Какого максимального размер могут быть сообщения, пересылаемые через BizTalk?

3. Если есть время и желание, то Virtual labs можно пройти в ускоренном режиме. Я буду на следующих занятиях по-прежнему задавать  лабы. Но если вы их уже пройдете к тому времени, то шлите мне запросы, чтобы получить персональные задания.
Итак, ниже список лабораторных по указанной в п.1 ссылке:

  • Step  Importance   BizTalk Server 2009 Virtual Labs
    ========================================================================
    1  1  BizTalk Server 2009: Building your first BizTalk Solution
  • —   4  BizTalk Server 2009: What Is New In BizTalk Server 2009
  • 2.1  1  BizTalk Server 2009: Working with Schemas
  • 2.2  1  BizTalk Server 2009: Working with Maps
  • 2.5  3  BizTalk Server 2009: Working with Pipelines
  • 2.6  2  BizTalk Server 2009: Processing Flat Files
  • 3  2-3 BizTalk Server 2009: Integration with ( 3) POP3 and (3)
    SharePoint and (2) Routing Failed Messages
  • 2.3 1  BizTalk Server 2009: Creating BizTalk Server Orchestrations
  • 3  2  BizTalk Server 2009: Integrating Business Rules
  • 2.4  1  BizTalk Server 2009: Deployment and Management
  • 2.7  1  BizTalk Server 2009: Using the WCF Adapters in BizTalk Server 2009
  • 3  1-4   BizTalk Server 2009: Building a WCF Adapter using the WCF LOB
    Adapter SDK [(1) for SQL Adapter]

11 комментариев

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 04

Сегодня занимаемся BizTalk Orchestrations.

1. Делаем лабораторную работу

BizTalk Server 2009: Creating BizTalk Server Orchestrations

http://www.microsoft.com/biztalk/en/us/virtual-labs.aspx

2. Отвечаем на вопросы:

  • Для чего нужны Orchestrations?
  • Какой основной объект, с которым работает Orchestration?
  • Какие операции выполняются над этим объектом?
  • Перечислите параметры Orchestration.
  • Как мы можем отлаживать Orchestrations?
  • Как можно trace содержимого message?
  • Что такое message content и что такое message context?
  • Где хранится Orchestrations во время работы (в run-time)?
  • Какие операции можно выполять с Orchestrations в run-time? Что они означают?
  • Orchestration — это publisher или subscriber?
  • Как взаимодействуют Порты и Orchestrations?

3. На следующее занятие у всех должна быть установлена VM с BizTalk.

4. В присланном мне отчете должна быть ссылка на вопрос, который вы задавали в MSDN BizTalk Server General Forum

5 комментариев

Filed under BizTalk, BizTalk course, Microsoft

BizTalk course: 03

1. Virtual Lab:
BizTalk Server 2009: Working with Maps

2.
Вопросы:
* для чего нужны maps?
* какие сайты вы нашли с простым и понятным описанием Xslt?
* для чего нужен Xslt?
* можно ли в BizTalk сделать map, у которой есть >1 source schemas and
1 target schema?
*** перечислите, чем, на ваш взгляд, отличается язык Xslt от С.
*** можно ли использовать xslt в коде на .NET? какие классы при этом
используются?
(вопросы *** — для тех, кто имел дело с Xslt или подобными языками)

3. Продолжаем установку VM с BizTalk Server. Желательно к следующему занятию завершить установку.

1 комментарий

Filed under BizTalk, BizTalk course, Работа, Microsoft