Введение в Microsoft Workflow Foundation

    Хочу предложить вашему вниманию серию статей, посвященных Microsoft Workflow Foundation. Данная технология представляет новый, более высокий, уровень абстракции в программировании под .net. Мы начнем с вводной статьи, описывающей предпосылки возникновения технологии, два основных вида рабочих процессов и средства разработки. В дальнейшем мы более подробно ознакомимся с различными аспектами Microsoft Workflow Foundation.

    Заинтересовались — читайте дальше.

    Введение


    Если оглянуться, то мир вокруг нас — это бесконечная череда сменяющих друг друга процессов. Мы сажаем зерно, оно прорастает, цветет, оставляет потомство, погибает. На его месте вырастает что-то новое. И так день за днем. Люди пытаются описать эти процессы, симулировать их на компьютере, придумывают что-то новое. Для этого создаются различные ментальные модели, которые упрощают описание повседневных процессов. Вводятся уровни абстракции. Например, придумали объектно-ориентированное программирование. С его помощью можно описывать объекты реального мира. Это легко и естественно. Достаточно посмотреть на вещь и в голове уже вырисовывается более или менее точная модель: какими свойствами обладает этот объект, какие действия может совершать.

    Но объекты, которые никак не взаимодействуют между собой, не имеют никакого смысла. Жизнь — это движение, зачастую цикличное. С другой стороны в мире существует человек. Он вносит некоторую сумятицу своей разумностью. Многие вещи, которые он делает — непоследовательны. Мотивы не всегда ясны. Сроки не всегда соответствуют ожиданиям. Человек может о чем-то забыть, что-то сделать не так, как задумывал раньше. И в тоже время он тоже оперирует объектами. Будь то объекты реального мира, такие, как камни, цветы, вода, или виртуального: документы, информация, слова.

    Именно для описания движения и взаимодействия объектов внутри программ создана технология Microsoft Workflow Foundation. Это связующее звено, которое позволяет создавать взаимодействия, связывающие объекты между собой или процессы, протекающие внутри самих объектов. Workflow Foundation (WF) разделяет все процессы на два основных типа: последовательные процессы (sequential) и процессы, основанные на состояниях (state machine).

    Последовательные процессы


    Последовательные процессы, в понимании WF, — это такие процессы, которые обычно происходят без вмешательства извне. Также, они занимают относительно немного времени. Хорошим примером такого процесса может послужить копирование файлов из одной папки в другую: мы задали папки в начале процесса, а потом в него не вмешиваемся до завершения. Т.е. это, по сути, отлаженный конвейер. Да, может что-то сломаться и потребовать каких-то действий, но это исключительные ситуации, которые обрабатываются отдельно.

    Процессы, основанные на состояниях


    Лучший пример процесса, основанного на состояниях, кроется в его переводе. State machine буквально означает государственный аппарат. Это такой процесс, который имеет множество состояний, которые в зависимости от различных событий могут переходить из одного в другое. Все это мы обычно видим в бюрократическом аппарате: государственная страховка, продажа квартиры и т.д. Требуются подписи различных чиновников, которые могут быть в отпуске или на больничном. Такой процесс может длиться очень долго: дни, недели, а то и месяцы. Именно для таких ситуаций создан state-machine workflow.

    Что нам дает WF


    Давайте теперь посмотрим, что нам дает WF. В первую очередь это наглядность. Все мы постоянно рисуем какие-то схемки, наброски. В более сложных случаях мы детально углубляемся в проектирование, например, рисуем временные диаграммы. Теперь мы можем перенести эти эскизы в Microsoft Visual Stuidio 2008 с помощью встроенного редактора. Вот как это выглядит:



    Даже далекий от программирования человек сможет разобраться в том, что происходит на диаграмме.
    Но все эти эскизы оторваны от действующей программы, никак с нею не взаимодействуют. Если нам надо изменить течение процесса, то необходимо открыть исходники, вспомнить места, в которых необходимо сделать изменения согласно новому эскизу. Эти задачи позволяет решить WF. Мы можем просто взять и перенести участок кода на другое место. Тут же его скомпилировать и сравнить с исходным вариантом.

    Также использование WF помогает более наглядно представить работу системы. Выделить процессы, которые могут быть разделены на составляющие или наоборот, объединены. Также поддерживаются транзакционные системы: можно задать компенсирующий процесс для случая, когда что-то пошло не так. Этот процесс вернет систему в состояние, в котором она находилась до наступления ошибки.

    Есть возможность опубликовать процесс в качестве сервиса или веб-сервиса, доступного через интернет. Более того, можно создать так называемый Durable web-service, который сохраняет идентификатор сессии и состояние сервиса в промежутках между вызовами, позволяя выполнять процесс в течение длительного времени, не поддерживая соединение. Вы даже можете остановить процесс, сохранить состояние и запустить его на другом компьютере с того же самого места.

    Средства разработки


    Наиболее удобным средством разработки является визуальный редактор, встроенный в Visual Studio 2008. Он позволяет быстро и гибко создавать и модифицировать процессы. При этом нет необходимости разбираться в том, как это устроено на низком уровне. Также можно создавать процессы, используя язык разметки XAML или при помощи C#.

    Давайте взглянем на основные элементы интерфейса для работы с процессами в студии. Вот как выглядит окно в процессе разработки:



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



    Это основной документ, в котором мы моделируем процесс. Сейчас мы видим приглашение перетащить туда какие-нибудь элементы для создания последовательного процесса.



    Процесс состоит из базовых элементов, называемых Activity. Они находятся в панели Toolbox под номером два. В ней находится множество элементов. Часть из них вполне понятна по их названию. Например, While или IfElse. ConditionedActivityGroup звучит более загадочно.



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



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

    Заключение


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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 100

      –2
      тупо блок-схемы с возможностью прилеплять код? :/
        +1
        Нет, много-много больше.
          +1
          Что именно в WF такого, что делает его больше, чем «блок-схемы с возможностью прилеплять код»?
            +1
            Навскидку:
            — Среда исполнения готовых workflow (WF Runtime), позволяющая беспроблемно запускать WF как виндоус-сервис, веб-сервис, application-сервер, IIS-application и так далее;
            — Различные модели: последовательные процессы и конечные автоматы (состояния);
            — Возможность при необходимости сохранять текущее состояние процесса или объекта в хранилище (базу, файлы и так далее) — persistence services;
            — Интегрированная возможность обращаться «куда-угодно» с помощью WCF;
            — Поддержка мультипоточности с помощью thread pools;
            — Описание большинства бизнес-правил декларативно с помощью XAML;


            Ну, то есть это целый готовый механизм, унифицированный и удобный в ряде случаев (особенно для разработки платформ), у MS самой такие продукты как SharePoint и BizTalk со своими процессами на основе WWF построены.
              0
              Это всё хорошие слова, но какое конкретное применение может быть у всех этих фич? Можно пример приложения (хотя бы воображаемого)?

              З.Ы. Наверное я тупое быдло, потому как для меня слова SharePoint и BizTalk звучат как предложение выложить кучу бабок, за возможность выложить ещё большую кучу бабок в будущем.
                +2
                Оно Вам просто не нужно :). И SharePoint и BizTalk Server — сугубо корпоративные решения, и там WF как раз очень помогает тем, что является заменой скриптовым языкам и соответственно автоматизировать какие-то процессы могут уже не програмисты, а те, кто внедряет и сопровождает эти сервера.
                  0
                  Странно как-то, народ с MS Dynamix без BizTalk Server обходится.
                    0
                    Ну вот хотят в следующем поколении продуктов Dynamics тоже построить все процессы на WWF :)
                    Развивают технологию понемногу.
                      0
                      В таком аспекте технология может даже иметь смысл.
                        0
                        Ну я думаю, что она изначально с таким намерением разрабатывалась.
                        Как и сам .NET во многом. И WWF не столько дает какой-то новый мегафункционал, а дает по сути, «движок процессов», который берет на себя всю рутину, и давая возможность потратить время на реальную прикладную задачу, а не на описание «принципов движения» объектов.
                  0
                  Пример приложения привел бы, вот думаю, как бы лучше все объяснить.
                  Я предлагаю дождаться следующей статьи, с примером, и там все хорошенько разложить по полочкам.

                  Насчет SharePoint и BizTalk не совсем верно. Как конечные решения, они мне самому не нравятся, но эти системы действительно оцениваются с точки зрения работы целого бизнеса, а не отдельного пользователя. Ну, стоят прилично, да. С другой стороны, SharePoint -ширпотребное решение, ибо порталы WebSphere от IBM, к примеру, на порядок дороже.
                    0
                    Жду следующей статьи ;)
                      0
                      Следующий статья будет про последовательные процессы. В ней, наверное, не будет откровений. А вот через одну будет уже либо интеграция в сервисы, либо интеграция в state-workflow, а потом уже интеграция в сервисы. И будет интереснее.

                      Так что следующая часть будет тоже пестрить вопросами о необходимости технологии и заключениями об ее надуманности. :)
                0
                возоможность декларативно задавать правила для этих блок схем
                возможность во время исполнения (ну почти) изменять workflow
              0
              не совсем тупо и не совсем блок-схемы =)
            • UFO just landed and posted this here
                0
                не работал над особо большими проектами, поэтому мне хватало ручки и тетрадки :)
                0
                Супер! Хотелось бы продолжения с каким-нибудь примером.
                  0
                  Первая толковая статья про WF, которую я вижу…
                  Неужели все так просто и удобно?
                    0
                    Да, так и есть :) Единственное, если не знать определенных тонкостей настроек Application Server'ов и App Pool'ов, можно при сложном решении получить не особо желанную по скорости производительность. Однако, разобравшись с технологией и используя все возможные механизмы оптимизации и интеграции с другими сервисами — это очень мощный и достаточно быстрый инструмент.
                      0
                      Можете разъяснить при чем здесь IIS?
                    0
                    Как именно работает привязка к коду?
                    Нельзя ли просто прогнав по сути профайлером создать такую диаграмму?
                      +1
                      Любой код пишется в так называемой code activity, а также можно менять конфигурации уже существующих типовых Activities. Все это запускается в Workflow Runtime, используя последний как Framework, который сам контролирует движение объектов, вызов событий, запуск кода, запуск других workflow, механизмов обработки ошибок, самих ошибок и так далее.

                      Не думаю, что генерация кода с участием профайлера позволила бы делать такое.
                      Многие Workflow могут быть определены вообще декларативно с помощью XAML.
                        +1
                        ясненько :) будем ждать новых статей!
                          +3
                          Да, и с вопросами, если что обращайтесь.

                          P.S. Только осторожно :)) Тут видимо какие-то анти-Microsoft-овские тролли диверсанты, видимо за интерес к их технологиям минусуют топики и карму. На них плевать, но в целом показывает, как люди любят аргументировать свою позицию.
                            0
                            сорри, «коменты и карму», конечно же.
                            0
                            На неделе перейдем к практике. :)
                        +1
                        к сожалению все совсем не просто и не так уж удобно
                        самый большой минус этого зверя — он создает отдельный кэш всех классов и пространств имен имеющихся в проекте, и из-за этого с большими проектами безбожно тормозит его дизайнер
                          +1
                          И с небольшими, к сожалению. Надеюсь, что поправят к следующей версии студии.
                            +1
                            Согласен. Для нас правда это было не очень критично, т.к. у нас мощные девелопмент-машины, но иногда тоже ощутимо заставляло понервничать программеров, пожирая кучу ресурсов.
                          0
                          Пытался пробовать в действии эту технологию, потом забросил.
                          Так и не понял, а нафига вообще нужен такой уровень абстракции?
                          Microsoft еще и дизайнер сразу предоставляет. А какая польза от всего этого?
                          Под конкретную предметную область, для конечного пользователя, такой редактор явно не сгодится. Для разработчика, проще и быстрей написать тот же цикл вручную. Ну а если нужна последовательность действий или событий в рабочем процессе, можно, к примеру, использовать те же очереди.
                          Не сомневаюсь, что эта библиотека хорошо отлажена и стабильна в работе, только вот практического применения я ей лично не нашел.
                          Может кто подскажет, где ее можно применить?
                            –1
                            Как раз-таки нужна там, где, казалось бы «быстрей ручками написать цикл». WF гарантирует правильную работу, вызов определенных событий, управляемый переход состояний и многое другое.

                            Насчет применения — весь «сок» WWF в том, что его Workflow не привязаны к чему бы то ни было. Уровень абстракции позволяет сделать с помощью WF абсолютно любой процесс. Как говорили в интервью сами создатели этого механизма — они поняли, что workflow применимо в любом процессе, «workflows all around us», суть этого в том, что почти любое движение или процесс можно описать с помощью WWF.
                              +1
                              весь «сок» WWF в том, что его Workflow не привязаны к чему бы то ни было.

                              Можете пояснить? Т.е. ближе к конкретике, какой-нибудь надуманный пример хотя бы?
                                +1
                                Да.

                                Например, может стоять задача движения товара с одного склада на другой. Это можно реализовать с помощью WWF. Или же может стоять системная задача, ну скажем, разработки обработчика HTTP-запросов, где передача управления от одного контроллера к другому (паттерн MVC) осуществляется средствами WWF.

                                WWF не содержит никакой специфики «складов» или «передачи управления контроллерам» и при этом может быть использован и в той и в другой задаче.

                                Примеры достаточно абстрактны, но суть, думаю, понятна?
                                  +1
                                  Насколько я понимаю, то же самое делается, например, интерфейсами.
                                  Поэтому упорно не могу понять, чем диаграмма лучше текста. Либо «фишка» вовсе не в этом, но я не увидел более чёткой формулировки, чем «нагляднее», потому что это дело вкуса, а остальное вполне естественно присутствует и в коде.
                                  Может, это просто первая статья, где вы описали лишь «как набросать Hello world», а потом уже раскроете тайны?

                                  П.С. Вижу минус у вас, я его не ставил.
                                    0
                                    Да ничего страшного в минусе, я сроду не гнался за рейтингами. Их ставят (считаю, необъективно), кто предпочитает видеть любые аргументы в пользу технологий MS в минусе.

                                    Насчет статьи — ее писал не я :)

                                    Насчет WWF и интерфейсов — интерфейсы — это инструмент проектирования, вы можете описать его как угодно (в соответствии с тем, как объект класса, реализующего интерфейс будет себя вести), и это не связано с WWF как таковым. WWF — это механизмы для описания того, как процесс будет выполняться или как будет меняться состояние «чего-либо».
                                    То есть, по сути, совершенно верно, вы можете описать с помощью классов и интерфейсов такое же точно поведение. Но WWF просто дает базу, которая в более-менее крупных проектах позволяет унифицировать подобные механизмы. Мы сами сначала считали WWF слишком громоздкой штукой, пока не пришли к тому, что в нескольких, скажем 6-ти, местах в проекте нам требовался некий унифицированный «движок» для запуска процессов.
                                    Это можно сравнить с неким фреймворком, как, например, тот же ASP.NET MVC, где вроде все так же — вызываются HttpHandler'ы, передается управление контроллерам, но в то же время, сам «каркас» — уже готов и можно полностью сосредоточиться на функциональности конкретного продукта/задачи.

                                    К примеру, после того, как описана сама последовательность, мы начинаем испытывать необходимость механизма обработки ошибок, сохранения промежуточных состояний в базу, передачи информации о состоянии процесса на удаленный сервис и так далее, а в WF это уже все есть «out-of-the-box». А писать это самому — сами понимаете, увеличиваются трудозатраты.
                                      0
                                      Хотя я и согласен с некоторыми товарищами насчет того, что хорошо бы иметь некую форму WWF Lite, чтобы не возникали подобные вопросы. Действительно, для небольших задач технология кажется (а зачастую и является) слишком тяжелой в ипользовании.
                                        +1
                                        В вашем случае, вы на ходу работы системы не сможете поменять, выполнение.
                                        WF позволяет это делать безболезненно.
                                      0
                                      Еще, например, запись объекта в базу. С проверкой существования объекта, откатом если что-то пошло не так. Передачей результата в процесс анализа добавленного объекта.

                                      Подождите до статей с примерами. Постараюсь получше раскрыть многообразие возможностей использования.
                                        0
                                        Поддерживаю! Это было бы очень интересно!
                                          0
                                          Да, я как раз об этом и говорил. Там и возможность persistence и сериализации объектов в базу, и все это согласованно средствами WWF. Runtime делает всю работу, не нужно писать ничего самому, чтобы оживить эти «блок-схемы».
                                            0
                                            Насчет примеров, кстати, мне очень понравилась фишка для веба — workflow-driven web-application. Когда, к примеру, для того, чтобы определить какую форму (шаг) wizarda показать, используется проверка состояний с помощью WF.
                                        +4
                                        В вещах, которые помасштабнее чем копирование файлов, можно в чужом коде видеть детали, но не видеть картины в целом. Если взять «жизненный цикл» заказа. Там идет наполнение товаров, ввод кучи данных, подтверждение, проверка этих данных, оплата, подтверждение оплаты, сборка товара на складе, отгрузка клиенту. Это то что сразу в голову пришло, наверняка ещё много чего упустил, резервирование, например :) Вот вы это все легко можете написать просто в коде, и я могу. Но потом третьему разработчику сразу ответить на вопрос «а можно ли отгрузить товар без оплаты?» не представляется возможным. Ему нужно будет пересмотреть от и до весь код, чтобы узнать, если такая возможность. С WWF это становится проще. Мне кажется именно для этих целей реализовано, а не просто как способ «попрограммировать мышкой», как это обозвали выше :)
                                          0
                                          Хмм, а UML на что тогда?
                                          Там же весь процесс описывается.
                                            0
                                            Ну UML — это методология. А WWF — инструмент, рабочий. По сути, процесс, описанный в XAML и/или .NET-коде, может быть сразу исполнен/опробован в WWF Runtime.
                                              0
                                              Ну, то есть, в чем-то он еще более формализован, чем UML. Хотя скорее, не более формализован (из UML же тоже можно генерировать код), а, скажем так, просто более удобная штука для определенных сценариев в проектах. Плюс, интеграция с .NET и VS2008 сразу, без необходимости что-то настраивать. В итоге созданные и изменяемые со временем Workflows являются часть кода проекта (project codebase).
                                            +1
                                            Извиняюсь за глупые, может быть, вопросы, но не плохо не знать, плохо не хотеть узнать.

                                            Вот взять ваш пример.
                                            Если третий разработчик взглянет на ту же функцию в виде блок-схемы, он дар речи может потерять. Или суть в том, что автор функции просто не сможет наваять такую блок-схему, которую он бы кодом в 500 строк оформил без проблем, и потому он сам добровольно разобьёт её на небольшие сущности?

                                            Я просто не понимаю, каким образом появится видение картины в целом, только если автор функции сам не подпишет всех нюансов, не делает же WF это автоматически?

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

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

                                              Недавно даже в жизни был пример. Написал документацию на программу — все расписал до самых винтиков. Ну вроде так, документация как документация, надо её всю перечитать, чтобы понять что как работает. Потом добавил туда диаграммы нарисованные в Visio — все сразу сказали вот это круто, все наглядно, все понятно. Поэтому, так же думаю и с кодом. Ну это мое восприятие такое.

                                              Из схемы в статье можно сразу однозначно сказать, что если файл уже существует в том месте куда копируем, то пишется лог, например. Чтобы ответить на этот же вопрос пришлось бы больше времени потратить в поисках этого куска кода и определения, пишет все же или нет. ИМХО, конечно.
                                                0
                                                Ну если дело вкуса, тогда конечно да. Просто зачастую технология преподносится как чуть ли не дающая ворох преимуществ, но при этом вместо конкретики говорят абстрактно, что не очень понятно. Мне бы кодом, просто и понятно.
                                                А так я сижу и не пойму, чем диаграмма выше лучше данного кода (пример рабочий, если дописать соответствующие недостающие функции, я лишь запостил основную)
                                                  +1
                                                  Как мы потом увидим, пример с переписыванием файлов может стать лишь небольшим кусочком, единичным Activity, в большой системе. И ее будет уже не представить на четверти страницы.

                                                  И вкус играет многое, конечно. Восприятие у всех свое :)
                                                    +1
                                                    Насколько я понимаю, вызов данной функции в обычном ЯП тоже не будет занимать 13 строк.
                                                    Но в общем жду.
                                                      0
                                                      Данной функции — да. Но в больших решениях код будет разрастаться экспоненциально. И поддерживать логику станет уже куда проще визуально в виде Workfows.
                                                    +1
                                                    А разве эта технология не даёт ворох преимуществ? Просто, для начала, с этой технологией, как и с любой другой, следует ознакомиться, а уже потом оценивать её преимущества и недостатки. А то частенько получается так, что о технологии судят даже не выяснив толком, что она из себя представляет, по картинкам в вводной статье. Давайте подождём продолжения, увидим раскрытие темы, описание применимых в ней подходов и т.д. А там уже и будем оценивать, как говориться: «не будем судить о книжке по обложке».
                                                      +1
                                                      Ну я, как вы видите, и пытаюсь разобраться, а не всё уже решил. Не мёдом же людям намазано, значит какие-то преимущества даёт.
                                                        0
                                                        Приятно, когда человек хочет разобраться, а не «льет воду», пытаясь дискредитировать технологию на корню, не имея аргументов.
                                                  0
                                                  Да, вы правы, WWF — это механизм, для использования которого, его надо знать. Про видение картины — согласен, сам по себе «голый» WWF скорее не для описания процессов и аналитиков, а для разработчиков.

                                                  Например, он часто находит применение в платформах, направленных на решение определенных задач. К примеру — Microsoft SharePoint Server — там WWF лежит в основе собственной системы так называемых «Рабочих процессов» (SharePoint workflows) Шарепоинта, которые настраиваются чисто визуально, с указанием условий на «человеческом языке» (в виде бизнес-терминов и условий) с помощью SharePoint Designer или во время развертывания самого MOSS-портала.

                                                  То есть, получается, что вот и применение — не чистого механизма WWF, а использование сервисов, построенных на нем. И строить логику процессов и смены состояний на визуальном уровне в SP Designer, к примеру, намного проще, чем работать с WWF напрямую, однако это уже будут «workflow под SharePoint». И когда встретятся жесткие ограничения, придется лезть в технологию глубже и разбираться с WWF. Только в случае с MOSS это приходится делать нечасто.
                                                  0
                                                  Было бы здорово, что бы это показали на примере, с кодом, в продолжении статьи :)
                                                  0
                                                  Однако, спешу заметить, на практике и правда применимо не везде, где по идее «могло бы быть использовано», хотя применений достаточно.
                                                    0
                                                    а вы же можете этот дизайнер легко подправить и хостить в своем приложении
                                                    +12
                                                    Не могу удержаться, уважаемые, дабы не уронить в этом огороде камень.

                                                    Вся эта сага об изменчивом мире вокруг нас изложена в стиле обучения новичков уникальной концепции, предложенной могучей компанией. Насколько это заметно из комментариев, многие ничего не знали о технологии WF. После прочтения многие остались удивлены, многие недовольны еще одним непонятным нововведением. Одним словом, такое введение не интригует.
                                                    И еще, изложение изобилует недопустимыми неточностями.
                                                    State machine буквально означает государственный аппарат
                                                    — нет, совсем не означает. Это понятие скорее из дискретной математики, нежели из политэкономического словаря иностранных слов и выражений. Есть еще finite state machine — боюсь предположить, как бы вы его перевели.
                                                    Надеюсь, вы отнесетесь к критике конструктивно, статья в целом заслуживает уважения, но содержит огрехи.

                                                    А теперь гораздо больший булыжник ожидает WF. Все не так интересно, как описано в топике.
                                                    Все намного интереснее. Есть такая технология, как BPEL. О ней написано на вики, знают гугл и яндекс — спросите их.

                                                    WF — плод инженерных усилий Microsoft, подогреваемых отделом маркетинга, ну и вообще их политики развития.
                                                    Долгое время Microsoft вместе с BEA Systems, IBM, SAP и Siebel Systems участвовала в подготовке стандартов, строящихся вокруг технологии BPEL, в 2003 и 2004 годах были утверждены стандарты BPEL4WS (WS-BPEL).
                                                    Сейчас этот самый BPEL — неотъемлемая часть инфраструктуры, развитием которой занимаются десятки крупнейших IT-компаний.
                                                    В двух словах, BPEL позволяет нарисовать сложный бизнес-процесс в виде определенной схемки в формате, основанном на xml. Потом эту схемку кладут в сервер приложений, и она может начать работать так же, как и код, написанный заботливыми руками программистов. Зачем это надо — значительно сокращается объем кода, который надо написать вручную. Большая организация требует оперативного отдела IT, который не просто мог бы написать код, но и мог бы в кратчайшие сроки его модифицировать. Сейчас многие компании наверняка внесут коррективы в свои бизнес-процессы, а это неизбежно отразится и на информационных системах, эти процессы поддерживающих.
                                                    Наглядность, стандартные механизмы обработки транзакций, связь разрозненных компонентов системы в единое координированное целое — вот для этого и нужен BPEL. Эта технология плотно связана с такими понятиями, как SOA и веб-сервисы, которые сейчас в моде.

                                                    А Microsoft с этим положением вещей согласиться не захотела. Вместо полной поддержки BPEL в .net мы увидели WF. Если вдуматься — решает те же задачи, устроена примерно так же, но называется по-другому и вообще «уникальный продукт».
                                                    И всё потому, что BPEL предлагает множество компаний, отличные редакторы и среды разработки распространяются бесплатно, решения работают под всеми операционными системами, которые вы не побоитесь установить на своё оборудование.
                                                    А вот WF-решения лучше всего разрабатывать для windows в visual studio. Интересно, а где еще это можно разрабатывать, и где это еще запуститься?!..
                                                      –6
                                                      Видимо Вы ярый противник МС (и/или поклонник open source), но надо мыслить немного объективней. Всем, кто привык к довольно удобной среде visual studio, такое расширение станет только приятным дополнением, и тут уже действительно все-равно, кто когда и что придумал. Главное — идея воплощена и ей можно пользоваться.
                                                        +4
                                                        Основная работа целиком связана с продуктами Microsoft, так что не могу неуважительно к этой конторе относиться :-)

                                                        Некоторое время назад, я действительно мог поспорить о политике, устройстве мира, open-source, Microsoft и т.п. А сейчас, честно говоря, надоело. Меня интересуют лучшие идеи этой отрасли, вне зависимости от производителя.
                                                        Понятное дело, что при прочих равных (или почти равных), лучшим мне кажется решение, которое проще и дешевле внедрить. Решения, затронутые в статье, не рассчитаны на применение в маленьких программках, основная прелесть которых — красивые окошки. Да и вообще круг применения довольно узок — это промышленные нагруженные системы массового обслуживания. В том числе и веб-приложения с тысячами страничек, на которых пользователи что-то смотрят и пишут. Все это дорогостоящие системы, поэтому немного сэкономить бывает совсем не вредно.
                                                        Open-source — что ж, почему так получилось, что множество неплохих серверов приложений действительно открыты, но я в этом не виноват! :-) Сейчас, возможно, открыты самые известные, стабильные и функциональные платформы, так бывает. Хотя это просто другая модель бизнеса больших компаний, которые собирают доход с поддержки клиентов.
                                                        0
                                                        Спасибо, почитаю про BPEL, как раз интересны подобные решения для Tomcat+Java
                                                          0
                                                          Не уверен что это точно что надо, но что то похожее в описании есть

                                                          www.jboss.org/drools/

                                                            0
                                                            Надо сервер приложений JBOSS ставить, а у нас Tomcat
                                                          +2
                                                          State machine — «автомат»
                                                          Finite state machine — «конечный автомат»
                                                          Из теории автоматов.
                                                          Правильно?
                                                            +2
                                                            правильно, правильно))
                                                              +5
                                                              Нет, это конченный государственный аппарат :)
                                                                0
                                                                Ересь!!! Император покарает тебя!!! (с) Вархаммер 40к
                                                                Кроме шуток, вспомнились надмозги и пиратские переводы 90х.
                                                                  0
                                                                  Мне почему-то кроме шуток вспомнилось родное SWITCH-программирование.
                                                                    0
                                                                    Ага :) Такие, как «You have to reboot the system» и «Вы должны переботинок систему».
                                                                0
                                                                Ничего удивительного в том, что MS разработала свою нотацию вместе с реализацией, вместо реализации уже существующих стандартных нотаций. Все-таки, бизнес есть бизнес, мне не всегда понятно желание многих рассматривать все только с точки зрения технологического фокуса (часто нелепое с технической точки зрения решение может быть принято ввиду «давления» со стороны бизнес-факторов). Думаю, с WWF — именно такое дело отчасти, ну и в конце концов для платформы .NET это работающее, и весьма хорошее решение.
                                                                  0
                                                                  Про state machine: просто перевод «государство», на мой взгляд, достаточно точно определяет суть state-machine.

                                                                  Про BEPL иду читать. Спасибо :)
                                                                  0
                                                                  Не могу удержаться, уважаемые, дабы не уронить в этом огороде песчинку.

                                                                  Это в виндовском эксплорере копирование «непрерывней» процесс, а в нормальных прогах есть минимум пауза. Ну а о правильных прогах и говорить ненужно, она там само собой подразумевается (я имею в виду адекватную задаче и окружению функциональность).
                                                                    0
                                                                    Хм. Учту :) Workflow тоже можно поставить на паузу и возобновить.
                                                                    0
                                                                    Вот меня беспокоит то, что в WF все происходит, по сути дела, синхронно, то есть в одном процессе. Конечно, можно запустить несколько workflow параллельно, но мне кажется что вся соль как раз в том, то у тебя есть функция где — в рамках этой функции — происходит какое-то умное многопоточное взаимодействие которое хотелось бы описать с помощью диаграмм. А WF это не позволяет.
                                                                      0
                                                                      Как я понял, начав читать книжку, там threadpool, на котором произвольно запускаются activity.
                                                                      То есть, есть свободный поток и есть работа, загрузим ка этот поток.
                                                                      Только вот после каждого блока кода перелезать на другой поток и сохранять данные в базу, как-то стрёмно под нагрузкой)
                                                                      Может это настраивается, конечно…
                                                                        0
                                                                        Как я понял, начав читать книжку, там threadpool, на котором произвольно запускаются activity.
                                                                        То есть, есть свободный поток и есть работа, загрузим ка этот поток.

                                                                        Хм, я конечно понимаю что они упростить хотят, но как-то это несерьёзно звучит, не зря же в Java такое значение придали именно управлению потоками и их синхронизации.
                                                                          0
                                                                          Как выяснилось, со временем это перенял и дотнет, даже почти не изменив имена классов.
                                                                            0
                                                                            Я не исключаю, что, если две activity работают с одними данными, начинается геморрой, который очень серьёзно решается))
                                                                              0
                                                                              Такие вещи решаются в простом случае семафорами или локами, в трудном — барьерами.
                                                                                +1
                                                                                Ну да, но если microsoft хочет, чтобы ты системе нарисовал блок-схему и она по ней начала работать, и любой человек не очень разбирающийся в программировании, но, допустим, разбирающийся в бизнес-процессах, мог изменить поведение системы, то объяснять этому человеку про потоки и механизмы их синхронизации как-то накладно.
                                                                                  +1
                                                                                  С другой стороны, о возможности нагадить в систему следует всё-таки предупреждать :)
                                                                                    0
                                                                                    В общем я посмотрел. Нашёл два способа разруливать конкурентный доступ:

                                                                                    1. > ...My doubt is: how do i make sure that the same data (in this sample " the helpdesk ticket") does not go to two different operators at the same time…

                                                                                    > ...The listen activity resolves this issue by cancelling the other branch(es) when it receives message for one of the branches…

                                                                                    forums.microsoft.com/msdn/ShowPost.aspx?PostID=2473903&SiteID=1

                                                                                    2. В книжке написано, что можно выполнять куски кода, как транзакции, в принципе это должно обеспечивать потокобезопасность.

                                                                                    В итоге надо либо проектировать модель обмена сообщениями, как мне кажется, это может стать очень запутанно, да и по скорости мне кажется не очень прикольно периодически отменять действия. Либо знать что такое транзакции, что, по-моему, более приятно. Вот такие пироги.
                                                                          0
                                                                          В workflow есть Parallel Activity позволяющая запускать различные последовательности действий параллельно. Она автоматически синхронизирует потоки и переходит к исполнению. Этого вполне достаточно для высокоуровневой параллелизации. Что-серьезное нужно делать в code-activity самому.
                                                                          0
                                                                          Немного не понял, как за всей этой абстрактностью, система поймет, что мне онкретного нужно?

                                                                          Ну вот поставил я там циклы, указал какое-то дейтсвие, названное CopyFiles. Откуда система поймет, что тут надо скопировать файлы?

                                                                          Ну а как я это понял, все равно пишутся классы, методы. А вот эта блок схема строит процесс с использованием моих написанных классов?
                                                                            0
                                                                            Да, вы пишете собственные Activity, те квадратики :) и составляете из них процесс…
                                                                            Activity можете написать какие угодно, и приминительно к вашей модели или бизнеса, использовать их повторно и\или состовлять из них новые процессы.
                                                                            +3
                                                                            Тут все просят хотя бы гипотетический пример, я же приведу конкретный пример, как WF реально используется в проекте, в котором его использование было рекомендовано мною.

                                                                            Проект первый: Институт Логистики Технического Университета Гамбурга разрабатывает софт для оптимизации товарооборота в порту Гамбурга. Ввиду того, что товарооборот зависит от типа товара и от многих других факторов, они разрабатывают систему, которая позволяет проанализировать текущий бизнес-процесс и выдать возможные рекомендации по его оптимизации.
                                                                            Как это происходит, я не знаю, но конкретная задача состояла вот в чём: данные о товаре и его движении сохраняются в базе данных, в зависимости от введенных данных пользователю показываются разные формуляры, которые генерятся базой «на лету»: то есть, например, после ввода данных о прибывшем корабле с грузом появляется формуляр с грузов, если груз подлежит растомаживанию — то формуляр таможенной информации и так далее. Сами формуляры зависят от уровня доступа оператора и его роли (бухгалтеру даются иные формуляры, нежели руководителю смены грузчиков или аудитору) и связаны друг с другом сложнейшей схемой с различными переходами.
                                                                            Так вот, эти схемы, какой формуляр в какой последовательности должен быть показан, реализовываются в виде Workflows, которые разрабатывает логистик в графическом редакторе, потом эти Workflows, сохраненные в XML-формате «подхватываются» .Net-assembly анализируются и преобразуются в Workflow, на основании которого подгружаются отдельные формуляры (или их части, в случае композитных формуляров). Сами формуляры, кстати, написаны в XAML и подгружаются через WPF.
                                                                            Таким образом логистик (причем там их несколько с разными уровнями доступа) имеет полный контроль над бизнес-процессом и может его легко модифицировать в runtime, при этом программист уже не нужен — новый бизнес-процесс автоматически обрабатывается (run) системой.

                                                                              0
                                                                              Гм, и вы думаете, все эти сложные зависимости удобнее рисовать на диаграмме? По моему, написать несколько строчек кода может оказаться и удобнее, и быстрее (хотя конечно если упомянутый логистик не умеет программировать… то да, возможно это и имеет смысл). Вопрос, а насколько понятной будет диаграмма, чем код при довольно-таки сложной системе связей.

                                                                              Кроме того, диаграмма составляется из ограниченного набора блоков. Что делать логистику, если нужного ему блока нет в стандартном комплекте?
                                                                                0
                                                                                Я не знаю, насколько это «удобнее», это было такое требование со стороны логистиков. Для них подобного рода диаграммы, как я понял, обычный способ планировать их процессы.

                                                                                «Написать несколько строчек» — для этого нужен постоянный программист, а у них в НИИ нет такой ставки (только сис. админ). Да и не хотят они «несколько строчек». Тут, насколько я понял, даже не проблема научить логистика программировать, сколько просто поддержка его обычной деятельности (то есть эти диаграммы он делает не только в рамках данной программы). Причем диаграммы, естессно, строились в каком-то UML-дизайнере, не в VS2008.

                                                                                Его «блоки» — это различные поля баз данных, которые представляются пользователю в виде формуляров. Есть библиотека готовых формуляров (с прописаным layout) для того, чтобы использовать их как формуляры или их части. Если готового «формуляра» нет, его можно создать на лету, просто описав те поля базы данных, которые должны актуализироваться в данном формуляре. Таким образом нужные блоки просто создаются путем изменения настроек существующих блоков.
                                                                              +1
                                                                              Статья написана очень мутно и непонятно, в майкрософтомском стиле, очень много лишнего. Без комментариев товарищей alaudo и artvlasov честно говоря что-то понять трудно, так бы и писали с самого начала, что это средство описания бизнес-процессов и разделения труда между логистиком и кем-то там еще. А вы сначала про воду и птичек, а потом про Visual Studio. Такое ощущение что перевод или копипаста с какого-то учебника МС.
                                                                                –1
                                                                                На мой взгляд, примеры alaudo и artvlasov — единичные случаи. Большинство из нас чаще сталкиваются с вещами на порядок проще. В данной статье я хотел донести именно то, что с помощью WF вы можете охватить весь бизнес процесс, что сделать глядя на код сделать невозможно. WF это инструмент, а не панацея для решения каких-то проблем.
                                                                                  0
                                                                                  Естественно, WF применим лишь в ограниченном количестве случаев, те 2 проекта, где мы его применяли, это примерно 5% от общего числа проектов, что были выполнены нашей фирмой за все время существования WF.
                                                                                  Просто workflows используются много где: SharePoint использует их для генерации buisiness logic, BizTalk вообще всецело построен на них, и в ряде случаев использование WF облегчает выполнение проекта, сильно завязанного на какие-то не всегда понятные и четко формализируемые заказчиком процессы.
                                                                                    0
                                                                                    Т.е. с вашей точки зрения использование WF в более простых проектах не имеет смысла? Тех же сайтах или клиентских приложениях? Они вроде хорошо подходят под state-machine, например.
                                                                                      0
                                                                                      Наверное я не совсем точно выразился.
                                                                                      Наверняка найти применение WF можно много где, а учитывая, что WF Runtime может хоститься как IIS, там и Windows Service и вообще любым приложением, позволяет его много куда «запихнуть».
                                                                                      Идея с сайтом, кстати, очень интересная — я здесь соглашусь, было бы интересно, тем более что SharePoint как раз и основан на workflows. Просто я никогда не разрабатывал сложных сайтов.
                                                                                      В целом, наверное, при надлежащем умении, данную технологию можно использовать довольно широко. Только учитывайте, что Майкрософт в версии .Net 4.0 полностью заново напишет этот Framework, обещая увеличение скорости в 100-1000 раз. Демонстрации, что я видел в Берлине на Technical Summit действительно впечатляли.
                                                                                        0
                                                                                        Что меня действительно удивило, так это даже текущая скорость выполнения. Я попробовал создать процесс добавления объектов в базу (информация о судах: скорость, курс и еще два десятка параметров) и время исполнения практически не отличалось от классического императивного подхода. Процесс, конечно, никакой и внедрения не стоит, но такого результата не ожидал.
                                                                                  0
                                                                                  А у меня почему-то сложилось впечатление, что вы просто предвзято ко всему этому относитесь.

                                                                                  В вашем профайле нашел «php, css, mysql, js». Вы много «учебников МС» прочитали? Или тех же статей, которые могли стать источником перевода?
                                                                                  +2
                                                                                  Не успел утром дописать:

                                                                                  Проект второй. Мы делали по заказу фирмы из Гамбурга, что обслуживает корабли, следующий проект: корабли имеют дорогую спутниковую связь, которая работает пакетами, то есть при накоплении некоего критического объема данных (разные заполненные морские документы учета в XML-формате, разные отчёты капитана и прочее) эти данные сжимаются и шифруются, после чего пересылаются по спутниковой связи в виде пакета в центральный офис компании, где этот пакет расшифровывается, расжимается и документы в зависимости от их типа данных, либо копируются во внутренние папки сотрудников (бухгалтеров, менеджеров), либо заливаются в базу данных и прочее.
                                                                                  Технически все это работало как Windows Service, которая с определенным интервалом проверяло определеные пути на центральном сервере корабля и выполняла все действия, если находила там файлы. В центральном офисе другая служба занималась распределением всего контена по папкам и заливкой в базу.
                                                                                  У самой фирмы не было IT-отдела, поэтому проект достался нам, но у них был свой ответственный за техническое обеспечение, с которым процесс отбора файлов, шифрования, сжатия, пересылки и распеделения был обсужден в малейших деталях и который желал иметь полный контроль над всем процессом, при этом не углубляясь в код.
                                                                                  В этом случае как раз идеально подошел уже готовый workflow, который, кстати, был несколько раз переделан для учета отдельных желаний по генерации ключа шифрования и алгоритмов сжатия. При этом весь процесс оставался видимым и понятным, обсуждение велось на уровне алгоритмов, а не исходного кода, что позволило гораздо быстрее найти общий язык и сделать проект.
                                                                                    0
                                                                                    О! Навели еще на одну мысль. Точно, Workflows можно менять «на ходу», не переделывая приложение и в зависимости от тех или иных условий запускать различные процессы. При этом их связь, запуск, параллельное выполнение итд контролируется WF Runtime'ом.

                                                                                  Only users with full accounts can post comments. Log in, please.