Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 100
тупо блок-схемы с возможностью прилеплять код? :/
Нет, много-много больше.
Что именно в WF такого, что делает его больше, чем «блок-схемы с возможностью прилеплять код»?
Навскидку:
— Среда исполнения готовых workflow (WF Runtime), позволяющая беспроблемно запускать WF как виндоус-сервис, веб-сервис, application-сервер, IIS-application и так далее;
— Различные модели: последовательные процессы и конечные автоматы (состояния);
— Возможность при необходимости сохранять текущее состояние процесса или объекта в хранилище (базу, файлы и так далее) — persistence services;
— Интегрированная возможность обращаться «куда-угодно» с помощью WCF;
— Поддержка мультипоточности с помощью thread pools;
— Описание большинства бизнес-правил декларативно с помощью XAML;
…
Ну, то есть это целый готовый механизм, унифицированный и удобный в ряде случаев (особенно для разработки платформ), у MS самой такие продукты как SharePoint и BizTalk со своими процессами на основе WWF построены.
— Среда исполнения готовых workflow (WF Runtime), позволяющая беспроблемно запускать WF как виндоус-сервис, веб-сервис, application-сервер, IIS-application и так далее;
— Различные модели: последовательные процессы и конечные автоматы (состояния);
— Возможность при необходимости сохранять текущее состояние процесса или объекта в хранилище (базу, файлы и так далее) — persistence services;
— Интегрированная возможность обращаться «куда-угодно» с помощью WCF;
— Поддержка мультипоточности с помощью thread pools;
— Описание большинства бизнес-правил декларативно с помощью XAML;
…
Ну, то есть это целый готовый механизм, унифицированный и удобный в ряде случаев (особенно для разработки платформ), у MS самой такие продукты как SharePoint и BizTalk со своими процессами на основе WWF построены.
Это всё хорошие слова, но какое конкретное применение может быть у всех этих фич? Можно пример приложения (хотя бы воображаемого)?
З.Ы. Наверное я тупое быдло, потому как для меня слова SharePoint и BizTalk звучат как предложение выложить кучу бабок, за возможность выложить ещё большую кучу бабок в будущем.
З.Ы. Наверное я тупое быдло, потому как для меня слова SharePoint и BizTalk звучат как предложение выложить кучу бабок, за возможность выложить ещё большую кучу бабок в будущем.
Странно как-то, народ с MS Dynamix без BizTalk Server обходится.
Ну вот хотят в следующем поколении продуктов Dynamics тоже построить все процессы на WWF :)
Развивают технологию понемногу.
Развивают технологию понемногу.
В таком аспекте технология может даже иметь смысл.
Ну я думаю, что она изначально с таким намерением разрабатывалась.
Как и сам .NET во многом. И WWF не столько дает какой-то новый мегафункционал, а дает по сути, «движок процессов», который берет на себя всю рутину, и давая возможность потратить время на реальную прикладную задачу, а не на описание «принципов движения» объектов.
Как и сам .NET во многом. И WWF не столько дает какой-то новый мегафункционал, а дает по сути, «движок процессов», который берет на себя всю рутину, и давая возможность потратить время на реальную прикладную задачу, а не на описание «принципов движения» объектов.
Пример приложения привел бы, вот думаю, как бы лучше все объяснить.
Я предлагаю дождаться следующей статьи, с примером, и там все хорошенько разложить по полочкам.
Насчет SharePoint и BizTalk не совсем верно. Как конечные решения, они мне самому не нравятся, но эти системы действительно оцениваются с точки зрения работы целого бизнеса, а не отдельного пользователя. Ну, стоят прилично, да. С другой стороны, SharePoint -ширпотребное решение, ибо порталы WebSphere от IBM, к примеру, на порядок дороже.
Я предлагаю дождаться следующей статьи, с примером, и там все хорошенько разложить по полочкам.
Насчет SharePoint и BizTalk не совсем верно. Как конечные решения, они мне самому не нравятся, но эти системы действительно оцениваются с точки зрения работы целого бизнеса, а не отдельного пользователя. Ну, стоят прилично, да. С другой стороны, SharePoint -ширпотребное решение, ибо порталы WebSphere от IBM, к примеру, на порядок дороже.
Жду следующей статьи ;)
Следующий статья будет про последовательные процессы. В ней, наверное, не будет откровений. А вот через одну будет уже либо интеграция в сервисы, либо интеграция в state-workflow, а потом уже интеграция в сервисы. И будет интереснее.
Так что следующая часть будет тоже пестрить вопросами о необходимости технологии и заключениями об ее надуманности. :)
Так что следующая часть будет тоже пестрить вопросами о необходимости технологии и заключениями об ее надуманности. :)
возоможность декларативно задавать правила для этих блок схем
возможность во время исполнения (ну почти) изменять workflow
возможность во время исполнения (ну почти) изменять workflow
не совсем тупо и не совсем блок-схемы =)
Супер! Хотелось бы продолжения с каким-нибудь примером.
Первая толковая статья про WF, которую я вижу…
Неужели все так просто и удобно?
Неужели все так просто и удобно?
Да, так и есть :) Единственное, если не знать определенных тонкостей настроек Application Server'ов и App Pool'ов, можно при сложном решении получить не особо желанную по скорости производительность. Однако, разобравшись с технологией и используя все возможные механизмы оптимизации и интеграции с другими сервисами — это очень мощный и достаточно быстрый инструмент.
Можете разъяснить при чем здесь IIS?
Конечно.
IIS может хостить Workflow Runtime, исполняемую среду WWF.
Однако, как говорится, it depends, поскольку случаи бывают разные, а у разных случаев, как я уже говорил, свои нюансы.
IIS может хостить Workflow Runtime, исполняемую среду WWF.
Однако, как говорится, it depends, поскольку случаи бывают разные, а у разных случаев, как я уже говорил, свои нюансы.
Как именно работает привязка к коду?
Нельзя ли просто прогнав по сути профайлером создать такую диаграмму?
Нельзя ли просто прогнав по сути профайлером создать такую диаграмму?
Любой код пишется в так называемой code activity, а также можно менять конфигурации уже существующих типовых Activities. Все это запускается в Workflow Runtime, используя последний как Framework, который сам контролирует движение объектов, вызов событий, запуск кода, запуск других workflow, механизмов обработки ошибок, самих ошибок и так далее.
Не думаю, что генерация кода с участием профайлера позволила бы делать такое.
Многие Workflow могут быть определены вообще декларативно с помощью XAML.
Не думаю, что генерация кода с участием профайлера позволила бы делать такое.
Многие Workflow могут быть определены вообще декларативно с помощью XAML.
ясненько :) будем ждать новых статей!
Да, и с вопросами, если что обращайтесь.
P.S. Только осторожно :)) Тут видимо какие-то анти-Microsoft-овские тролли диверсанты, видимо за интерес к их технологиям минусуют топики и карму. На них плевать, но в целом показывает, как люди любят аргументировать свою позицию.
P.S. Только осторожно :)) Тут видимо какие-то анти-Microsoft-овские тролли диверсанты, видимо за интерес к их технологиям минусуют топики и карму. На них плевать, но в целом показывает, как люди любят аргументировать свою позицию.
На неделе перейдем к практике. :)
к сожалению все совсем не просто и не так уж удобно
самый большой минус этого зверя — он создает отдельный кэш всех классов и пространств имен имеющихся в проекте, и из-за этого с большими проектами безбожно тормозит его дизайнер
самый большой минус этого зверя — он создает отдельный кэш всех классов и пространств имен имеющихся в проекте, и из-за этого с большими проектами безбожно тормозит его дизайнер
Пытался пробовать в действии эту технологию, потом забросил.
Так и не понял, а нафига вообще нужен такой уровень абстракции?
Microsoft еще и дизайнер сразу предоставляет. А какая польза от всего этого?
Под конкретную предметную область, для конечного пользователя, такой редактор явно не сгодится. Для разработчика, проще и быстрей написать тот же цикл вручную. Ну а если нужна последовательность действий или событий в рабочем процессе, можно, к примеру, использовать те же очереди.
Не сомневаюсь, что эта библиотека хорошо отлажена и стабильна в работе, только вот практического применения я ей лично не нашел.
Может кто подскажет, где ее можно применить?
Так и не понял, а нафига вообще нужен такой уровень абстракции?
Microsoft еще и дизайнер сразу предоставляет. А какая польза от всего этого?
Под конкретную предметную область, для конечного пользователя, такой редактор явно не сгодится. Для разработчика, проще и быстрей написать тот же цикл вручную. Ну а если нужна последовательность действий или событий в рабочем процессе, можно, к примеру, использовать те же очереди.
Не сомневаюсь, что эта библиотека хорошо отлажена и стабильна в работе, только вот практического применения я ей лично не нашел.
Может кто подскажет, где ее можно применить?
Как раз-таки нужна там, где, казалось бы «быстрей ручками написать цикл». WF гарантирует правильную работу, вызов определенных событий, управляемый переход состояний и многое другое.
Насчет применения — весь «сок» WWF в том, что его Workflow не привязаны к чему бы то ни было. Уровень абстракции позволяет сделать с помощью WF абсолютно любой процесс. Как говорили в интервью сами создатели этого механизма — они поняли, что workflow применимо в любом процессе, «workflows all around us», суть этого в том, что почти любое движение или процесс можно описать с помощью WWF.
Насчет применения — весь «сок» WWF в том, что его Workflow не привязаны к чему бы то ни было. Уровень абстракции позволяет сделать с помощью WF абсолютно любой процесс. Как говорили в интервью сами создатели этого механизма — они поняли, что workflow применимо в любом процессе, «workflows all around us», суть этого в том, что почти любое движение или процесс можно описать с помощью WWF.
весь «сок» WWF в том, что его Workflow не привязаны к чему бы то ни было.
Можете пояснить? Т.е. ближе к конкретике, какой-нибудь надуманный пример хотя бы?
Да.
Например, может стоять задача движения товара с одного склада на другой. Это можно реализовать с помощью WWF. Или же может стоять системная задача, ну скажем, разработки обработчика HTTP-запросов, где передача управления от одного контроллера к другому (паттерн MVC) осуществляется средствами WWF.
WWF не содержит никакой специфики «складов» или «передачи управления контроллерам» и при этом может быть использован и в той и в другой задаче.
Примеры достаточно абстрактны, но суть, думаю, понятна?
Например, может стоять задача движения товара с одного склада на другой. Это можно реализовать с помощью WWF. Или же может стоять системная задача, ну скажем, разработки обработчика HTTP-запросов, где передача управления от одного контроллера к другому (паттерн MVC) осуществляется средствами WWF.
WWF не содержит никакой специфики «складов» или «передачи управления контроллерам» и при этом может быть использован и в той и в другой задаче.
Примеры достаточно абстрактны, но суть, думаю, понятна?
Насколько я понимаю, то же самое делается, например, интерфейсами.
Поэтому упорно не могу понять, чем диаграмма лучше текста. Либо «фишка» вовсе не в этом, но я не увидел более чёткой формулировки, чем «нагляднее», потому что это дело вкуса, а остальное вполне естественно присутствует и в коде.
Может, это просто первая статья, где вы описали лишь «как набросать Hello world», а потом уже раскроете тайны?
П.С. Вижу минус у вас, я его не ставил.
Поэтому упорно не могу понять, чем диаграмма лучше текста. Либо «фишка» вовсе не в этом, но я не увидел более чёткой формулировки, чем «нагляднее», потому что это дело вкуса, а остальное вполне естественно присутствует и в коде.
Может, это просто первая статья, где вы описали лишь «как набросать Hello world», а потом уже раскроете тайны?
П.С. Вижу минус у вас, я его не ставил.
Да ничего страшного в минусе, я сроду не гнался за рейтингами. Их ставят (считаю, необъективно), кто предпочитает видеть любые аргументы в пользу технологий MS в минусе.
Насчет статьи — ее писал не я :)
Насчет WWF и интерфейсов — интерфейсы — это инструмент проектирования, вы можете описать его как угодно (в соответствии с тем, как объект класса, реализующего интерфейс будет себя вести), и это не связано с WWF как таковым. WWF — это механизмы для описания того, как процесс будет выполняться или как будет меняться состояние «чего-либо».
То есть, по сути, совершенно верно, вы можете описать с помощью классов и интерфейсов такое же точно поведение. Но WWF просто дает базу, которая в более-менее крупных проектах позволяет унифицировать подобные механизмы. Мы сами сначала считали WWF слишком громоздкой штукой, пока не пришли к тому, что в нескольких, скажем 6-ти, местах в проекте нам требовался некий унифицированный «движок» для запуска процессов.
Это можно сравнить с неким фреймворком, как, например, тот же ASP.NET MVC, где вроде все так же — вызываются HttpHandler'ы, передается управление контроллерам, но в то же время, сам «каркас» — уже готов и можно полностью сосредоточиться на функциональности конкретного продукта/задачи.
К примеру, после того, как описана сама последовательность, мы начинаем испытывать необходимость механизма обработки ошибок, сохранения промежуточных состояний в базу, передачи информации о состоянии процесса на удаленный сервис и так далее, а в WF это уже все есть «out-of-the-box». А писать это самому — сами понимаете, увеличиваются трудозатраты.
Насчет статьи — ее писал не я :)
Насчет WWF и интерфейсов — интерфейсы — это инструмент проектирования, вы можете описать его как угодно (в соответствии с тем, как объект класса, реализующего интерфейс будет себя вести), и это не связано с WWF как таковым. WWF — это механизмы для описания того, как процесс будет выполняться или как будет меняться состояние «чего-либо».
То есть, по сути, совершенно верно, вы можете описать с помощью классов и интерфейсов такое же точно поведение. Но WWF просто дает базу, которая в более-менее крупных проектах позволяет унифицировать подобные механизмы. Мы сами сначала считали WWF слишком громоздкой штукой, пока не пришли к тому, что в нескольких, скажем 6-ти, местах в проекте нам требовался некий унифицированный «движок» для запуска процессов.
Это можно сравнить с неким фреймворком, как, например, тот же ASP.NET MVC, где вроде все так же — вызываются HttpHandler'ы, передается управление контроллерам, но в то же время, сам «каркас» — уже готов и можно полностью сосредоточиться на функциональности конкретного продукта/задачи.
К примеру, после того, как описана сама последовательность, мы начинаем испытывать необходимость механизма обработки ошибок, сохранения промежуточных состояний в базу, передачи информации о состоянии процесса на удаленный сервис и так далее, а в WF это уже все есть «out-of-the-box». А писать это самому — сами понимаете, увеличиваются трудозатраты.
Хотя я и согласен с некоторыми товарищами насчет того, что хорошо бы иметь некую форму WWF Lite, чтобы не возникали подобные вопросы. Действительно, для небольших задач технология кажется (а зачастую и является) слишком тяжелой в ипользовании.
В вашем случае, вы на ходу работы системы не сможете поменять, выполнение.
WF позволяет это делать безболезненно.
WF позволяет это делать безболезненно.
Еще, например, запись объекта в базу. С проверкой существования объекта, откатом если что-то пошло не так. Передачей результата в процесс анализа добавленного объекта.
Подождите до статей с примерами. Постараюсь получше раскрыть многообразие возможностей использования.
Подождите до статей с примерами. Постараюсь получше раскрыть многообразие возможностей использования.
Поддерживаю! Это было бы очень интересно!
Да, я как раз об этом и говорил. Там и возможность persistence и сериализации объектов в базу, и все это согласованно средствами WWF. Runtime делает всю работу, не нужно писать ничего самому, чтобы оживить эти «блок-схемы».
Насчет примеров, кстати, мне очень понравилась фишка для веба — workflow-driven web-application. Когда, к примеру, для того, чтобы определить какую форму (шаг) wizarda показать, используется проверка состояний с помощью WF.
В вещах, которые помасштабнее чем копирование файлов, можно в чужом коде видеть детали, но не видеть картины в целом. Если взять «жизненный цикл» заказа. Там идет наполнение товаров, ввод кучи данных, подтверждение, проверка этих данных, оплата, подтверждение оплаты, сборка товара на складе, отгрузка клиенту. Это то что сразу в голову пришло, наверняка ещё много чего упустил, резервирование, например :) Вот вы это все легко можете написать просто в коде, и я могу. Но потом третьему разработчику сразу ответить на вопрос «а можно ли отгрузить товар без оплаты?» не представляется возможным. Ему нужно будет пересмотреть от и до весь код, чтобы узнать, если такая возможность. С WWF это становится проще. Мне кажется именно для этих целей реализовано, а не просто как способ «попрограммировать мышкой», как это обозвали выше :)
Хмм, а UML на что тогда?
Там же весь процесс описывается.
Там же весь процесс описывается.
Ну UML — это методология. А WWF — инструмент, рабочий. По сути, процесс, описанный в XAML и/или .NET-коде, может быть сразу исполнен/опробован в WWF Runtime.
Ну, то есть, в чем-то он еще более формализован, чем UML. Хотя скорее, не более формализован (из UML же тоже можно генерировать код), а, скажем так, просто более удобная штука для определенных сценариев в проектах. Плюс, интеграция с .NET и VS2008 сразу, без необходимости что-то настраивать. В итоге созданные и изменяемые со временем Workflows являются часть кода проекта (project codebase).
Извиняюсь за глупые, может быть, вопросы, но не плохо не знать, плохо не хотеть узнать.
Вот взять ваш пример.
Если третий разработчик взглянет на ту же функцию в виде блок-схемы, он дар речи может потерять. Или суть в том, что автор функции просто не сможет наваять такую блок-схему, которую он бы кодом в 500 строк оформил без проблем, и потому он сам добровольно разобьёт её на небольшие сущности?
Я просто не понимаю, каким образом появится видение картины в целом, только если автор функции сам не подпишет всех нюансов, не делает же WF это автоматически?
Я например не вижу картины в целом на блок-схеме в статье. Я вижу там некое выполнение, назначение которого я понял, прокрутив в своей голове.
Вот взять ваш пример.
Если третий разработчик взглянет на ту же функцию в виде блок-схемы, он дар речи может потерять. Или суть в том, что автор функции просто не сможет наваять такую блок-схему, которую он бы кодом в 500 строк оформил без проблем, и потому он сам добровольно разобьёт её на небольшие сущности?
Я просто не понимаю, каким образом появится видение картины в целом, только если автор функции сам не подпишет всех нюансов, не делает же WF это автоматически?
Я например не вижу картины в целом на блок-схеме в статье. Я вижу там некое выполнение, назначение которого я понял, прокрутив в своей голове.
Я не буду доказывать, тут в конце концов дело вкуса кому как лучше информация впитывается.
Перед решением задачи я все время что-то рисую на бумаге. У меня визуализированная задача решается намного быстрее, чем та, которую нужно держать в голове. Соответственно чужие мысли тоже проще понимаю со схем.
Недавно даже в жизни был пример. Написал документацию на программу — все расписал до самых винтиков. Ну вроде так, документация как документация, надо её всю перечитать, чтобы понять что как работает. Потом добавил туда диаграммы нарисованные в Visio — все сразу сказали вот это круто, все наглядно, все понятно. Поэтому, так же думаю и с кодом. Ну это мое восприятие такое.
Из схемы в статье можно сразу однозначно сказать, что если файл уже существует в том месте куда копируем, то пишется лог, например. Чтобы ответить на этот же вопрос пришлось бы больше времени потратить в поисках этого куска кода и определения, пишет все же или нет. ИМХО, конечно.
Перед решением задачи я все время что-то рисую на бумаге. У меня визуализированная задача решается намного быстрее, чем та, которую нужно держать в голове. Соответственно чужие мысли тоже проще понимаю со схем.
Недавно даже в жизни был пример. Написал документацию на программу — все расписал до самых винтиков. Ну вроде так, документация как документация, надо её всю перечитать, чтобы понять что как работает. Потом добавил туда диаграммы нарисованные в Visio — все сразу сказали вот это круто, все наглядно, все понятно. Поэтому, так же думаю и с кодом. Ну это мое восприятие такое.
Из схемы в статье можно сразу однозначно сказать, что если файл уже существует в том месте куда копируем, то пишется лог, например. Чтобы ответить на этот же вопрос пришлось бы больше времени потратить в поисках этого куска кода и определения, пишет все же или нет. ИМХО, конечно.
Ну если дело вкуса, тогда конечно да. Просто зачастую технология преподносится как чуть ли не дающая ворох преимуществ, но при этом вместо конкретики говорят абстрактно, что не очень понятно. Мне бы кодом, просто и понятно.
А так я сижу и не пойму, чем диаграмма выше лучше данного кода (пример рабочий, если дописать соответствующие недостающие функции, я лишь запостил основную)
А так я сижу и не пойму, чем диаграмма выше лучше данного кода (пример рабочий, если дописать соответствующие недостающие функции, я лишь запостил основную)
Как мы потом увидим, пример с переписыванием файлов может стать лишь небольшим кусочком, единичным Activity, в большой системе. И ее будет уже не представить на четверти страницы.
И вкус играет многое, конечно. Восприятие у всех свое :)
И вкус играет многое, конечно. Восприятие у всех свое :)
А разве эта технология не даёт ворох преимуществ? Просто, для начала, с этой технологией, как и с любой другой, следует ознакомиться, а уже потом оценивать её преимущества и недостатки. А то частенько получается так, что о технологии судят даже не выяснив толком, что она из себя представляет, по картинкам в вводной статье. Давайте подождём продолжения, увидим раскрытие темы, описание применимых в ней подходов и т.д. А там уже и будем оценивать, как говориться: «не будем судить о книжке по обложке».
Да, вы правы, WWF — это механизм, для использования которого, его надо знать. Про видение картины — согласен, сам по себе «голый» WWF скорее не для описания процессов и аналитиков, а для разработчиков.
Например, он часто находит применение в платформах, направленных на решение определенных задач. К примеру — Microsoft SharePoint Server — там WWF лежит в основе собственной системы так называемых «Рабочих процессов» (SharePoint workflows) Шарепоинта, которые настраиваются чисто визуально, с указанием условий на «человеческом языке» (в виде бизнес-терминов и условий) с помощью SharePoint Designer или во время развертывания самого MOSS-портала.
То есть, получается, что вот и применение — не чистого механизма WWF, а использование сервисов, построенных на нем. И строить логику процессов и смены состояний на визуальном уровне в SP Designer, к примеру, намного проще, чем работать с WWF напрямую, однако это уже будут «workflow под SharePoint». И когда встретятся жесткие ограничения, придется лезть в технологию глубже и разбираться с WWF. Только в случае с MOSS это приходится делать нечасто.
Например, он часто находит применение в платформах, направленных на решение определенных задач. К примеру — Microsoft SharePoint Server — там WWF лежит в основе собственной системы так называемых «Рабочих процессов» (SharePoint workflows) Шарепоинта, которые настраиваются чисто визуально, с указанием условий на «человеческом языке» (в виде бизнес-терминов и условий) с помощью SharePoint Designer или во время развертывания самого MOSS-портала.
То есть, получается, что вот и применение — не чистого механизма WWF, а использование сервисов, построенных на нем. И строить логику процессов и смены состояний на визуальном уровне в SP Designer, к примеру, намного проще, чем работать с WWF напрямую, однако это уже будут «workflow под SharePoint». И когда встретятся жесткие ограничения, придется лезть в технологию глубже и разбираться с WWF. Только в случае с MOSS это приходится делать нечасто.
Было бы здорово, что бы это показали на примере, с кодом, в продолжении статьи :)
Однако, спешу заметить, на практике и правда применимо не везде, где по идее «могло бы быть использовано», хотя применений достаточно.
а вы же можете этот дизайнер легко подправить и хостить в своем приложении
Не могу удержаться, уважаемые, дабы не уронить в этом огороде камень.
Вся эта сага об изменчивом мире вокруг нас изложена в стиле обучения новичков уникальной концепции, предложенной могучей компанией. Насколько это заметно из комментариев, многие ничего не знали о технологии WF. После прочтения многие остались удивлены, многие недовольны еще одним непонятным нововведением. Одним словом, такое введение не интригует.
И еще, изложение изобилует недопустимыми неточностями.
Надеюсь, вы отнесетесь к критике конструктивно, статья в целом заслуживает уважения, но содержит огрехи.
А теперь гораздо больший булыжник ожидает 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. Интересно, а где еще это можно разрабатывать, и где это еще запуститься?!..
Вся эта сага об изменчивом мире вокруг нас изложена в стиле обучения новичков уникальной концепции, предложенной могучей компанией. Насколько это заметно из комментариев, многие ничего не знали о технологии 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. Интересно, а где еще это можно разрабатывать, и где это еще запуститься?!..
Видимо Вы ярый противник МС (и/или поклонник open source), но надо мыслить немного объективней. Всем, кто привык к довольно удобной среде visual studio, такое расширение станет только приятным дополнением, и тут уже действительно все-равно, кто когда и что придумал. Главное — идея воплощена и ей можно пользоваться.
Основная работа целиком связана с продуктами Microsoft, так что не могу неуважительно к этой конторе относиться :-)
Некоторое время назад, я действительно мог поспорить о политике, устройстве мира, open-source, Microsoft и т.п. А сейчас, честно говоря, надоело. Меня интересуют лучшие идеи этой отрасли, вне зависимости от производителя.
Понятное дело, что при прочих равных (или почти равных), лучшим мне кажется решение, которое проще и дешевле внедрить. Решения, затронутые в статье, не рассчитаны на применение в маленьких программках, основная прелесть которых — красивые окошки. Да и вообще круг применения довольно узок — это промышленные нагруженные системы массового обслуживания. В том числе и веб-приложения с тысячами страничек, на которых пользователи что-то смотрят и пишут. Все это дорогостоящие системы, поэтому немного сэкономить бывает совсем не вредно.
Open-source — что ж, почему так получилось, что множество неплохих серверов приложений действительно открыты, но я в этом не виноват! :-) Сейчас, возможно, открыты самые известные, стабильные и функциональные платформы, так бывает. Хотя это просто другая модель бизнеса больших компаний, которые собирают доход с поддержки клиентов.
Некоторое время назад, я действительно мог поспорить о политике, устройстве мира, open-source, Microsoft и т.п. А сейчас, честно говоря, надоело. Меня интересуют лучшие идеи этой отрасли, вне зависимости от производителя.
Понятное дело, что при прочих равных (или почти равных), лучшим мне кажется решение, которое проще и дешевле внедрить. Решения, затронутые в статье, не рассчитаны на применение в маленьких программках, основная прелесть которых — красивые окошки. Да и вообще круг применения довольно узок — это промышленные нагруженные системы массового обслуживания. В том числе и веб-приложения с тысячами страничек, на которых пользователи что-то смотрят и пишут. Все это дорогостоящие системы, поэтому немного сэкономить бывает совсем не вредно.
Open-source — что ж, почему так получилось, что множество неплохих серверов приложений действительно открыты, но я в этом не виноват! :-) Сейчас, возможно, открыты самые известные, стабильные и функциональные платформы, так бывает. Хотя это просто другая модель бизнеса больших компаний, которые собирают доход с поддержки клиентов.
Спасибо, почитаю про BPEL, как раз интересны подобные решения для Tomcat+Java
State machine — «автомат»
Finite state machine — «конечный автомат»
Из теории автоматов.
Правильно?
Finite state machine — «конечный автомат»
Из теории автоматов.
Правильно?
Ничего удивительного в том, что MS разработала свою нотацию вместе с реализацией, вместо реализации уже существующих стандартных нотаций. Все-таки, бизнес есть бизнес, мне не всегда понятно желание многих рассматривать все только с точки зрения технологического фокуса (часто нелепое с технической точки зрения решение может быть принято ввиду «давления» со стороны бизнес-факторов). Думаю, с WWF — именно такое дело отчасти, ну и в конце концов для платформы .NET это работающее, и весьма хорошее решение.
Про state machine: просто перевод «государство», на мой взгляд, достаточно точно определяет суть state-machine.
Про BEPL иду читать. Спасибо :)
Про BEPL иду читать. Спасибо :)
Не могу удержаться, уважаемые, дабы не уронить в этом огороде песчинку.
Это в виндовском эксплорере копирование «непрерывней» процесс, а в нормальных прогах есть минимум пауза. Ну а о правильных прогах и говорить ненужно, она там само собой подразумевается (я имею в виду адекватную задаче и окружению функциональность).
Это в виндовском эксплорере копирование «непрерывней» процесс, а в нормальных прогах есть минимум пауза. Ну а о правильных прогах и говорить ненужно, она там само собой подразумевается (я имею в виду адекватную задаче и окружению функциональность).
Вот меня беспокоит то, что в WF все происходит, по сути дела, синхронно, то есть в одном процессе. Конечно, можно запустить несколько workflow параллельно, но мне кажется что вся соль как раз в том, то у тебя есть функция где — в рамках этой функции — происходит какое-то умное многопоточное взаимодействие которое хотелось бы описать с помощью диаграмм. А WF это не позволяет.
Как я понял, начав читать книжку, там threadpool, на котором произвольно запускаются activity.
То есть, есть свободный поток и есть работа, загрузим ка этот поток.
Только вот после каждого блока кода перелезать на другой поток и сохранять данные в базу, как-то стрёмно под нагрузкой)
Может это настраивается, конечно…
То есть, есть свободный поток и есть работа, загрузим ка этот поток.
Только вот после каждого блока кода перелезать на другой поток и сохранять данные в базу, как-то стрёмно под нагрузкой)
Может это настраивается, конечно…
Как я понял, начав читать книжку, там threadpool, на котором произвольно запускаются activity.
То есть, есть свободный поток и есть работа, загрузим ка этот поток.
Хм, я конечно понимаю что они упростить хотят, но как-то это несерьёзно звучит, не зря же в Java такое значение придали именно управлению потоками и их синхронизации.
Как выяснилось, со временем это перенял и дотнет, даже почти не изменив имена классов.
Я не исключаю, что, если две activity работают с одними данными, начинается геморрой, который очень серьёзно решается))
Такие вещи решаются в простом случае семафорами или локами, в трудном — барьерами.
Ну да, но если microsoft хочет, чтобы ты системе нарисовал блок-схему и она по ней начала работать, и любой человек не очень разбирающийся в программировании, но, допустим, разбирающийся в бизнес-процессах, мог изменить поведение системы, то объяснять этому человеку про потоки и механизмы их синхронизации как-то накладно.
С другой стороны, о возможности нагадить в систему следует всё-таки предупреждать :)
В общем я посмотрел. Нашёл два способа разруливать конкурентный доступ:
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. В книжке написано, что можно выполнять куски кода, как транзакции, в принципе это должно обеспечивать потокобезопасность.
В итоге надо либо проектировать модель обмена сообщениями, как мне кажется, это может стать очень запутанно, да и по скорости мне кажется не очень прикольно периодически отменять действия. Либо знать что такое транзакции, что, по-моему, более приятно. Вот такие пироги.
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. В книжке написано, что можно выполнять куски кода, как транзакции, в принципе это должно обеспечивать потокобезопасность.
В итоге надо либо проектировать модель обмена сообщениями, как мне кажется, это может стать очень запутанно, да и по скорости мне кажется не очень прикольно периодически отменять действия. Либо знать что такое транзакции, что, по-моему, более приятно. Вот такие пироги.
В workflow есть Parallel Activity позволяющая запускать различные последовательности действий параллельно. Она автоматически синхронизирует потоки и переходит к исполнению. Этого вполне достаточно для высокоуровневой параллелизации. Что-серьезное нужно делать в code-activity самому.
Немного не понял, как за всей этой абстрактностью, система поймет, что мне онкретного нужно?
Ну вот поставил я там циклы, указал какое-то дейтсвие, названное CopyFiles. Откуда система поймет, что тут надо скопировать файлы?
Ну а как я это понял, все равно пишутся классы, методы. А вот эта блок схема строит процесс с использованием моих написанных классов?
Ну вот поставил я там циклы, указал какое-то дейтсвие, названное CopyFiles. Откуда система поймет, что тут надо скопировать файлы?
Ну а как я это понял, все равно пишутся классы, методы. А вот эта блок схема строит процесс с использованием моих написанных классов?
Тут все просят хотя бы гипотетический пример, я же приведу конкретный пример, как WF реально используется в проекте, в котором его использование было рекомендовано мною.
Проект первый: Институт Логистики Технического Университета Гамбурга разрабатывает софт для оптимизации товарооборота в порту Гамбурга. Ввиду того, что товарооборот зависит от типа товара и от многих других факторов, они разрабатывают систему, которая позволяет проанализировать текущий бизнес-процесс и выдать возможные рекомендации по его оптимизации.
Как это происходит, я не знаю, но конкретная задача состояла вот в чём: данные о товаре и его движении сохраняются в базе данных, в зависимости от введенных данных пользователю показываются разные формуляры, которые генерятся базой «на лету»: то есть, например, после ввода данных о прибывшем корабле с грузом появляется формуляр с грузов, если груз подлежит растомаживанию — то формуляр таможенной информации и так далее. Сами формуляры зависят от уровня доступа оператора и его роли (бухгалтеру даются иные формуляры, нежели руководителю смены грузчиков или аудитору) и связаны друг с другом сложнейшей схемой с различными переходами.
Так вот, эти схемы, какой формуляр в какой последовательности должен быть показан, реализовываются в виде Workflows, которые разрабатывает логистик в графическом редакторе, потом эти Workflows, сохраненные в XML-формате «подхватываются» .Net-assembly анализируются и преобразуются в Workflow, на основании которого подгружаются отдельные формуляры (или их части, в случае композитных формуляров). Сами формуляры, кстати, написаны в XAML и подгружаются через WPF.
Таким образом логистик (причем там их несколько с разными уровнями доступа) имеет полный контроль над бизнес-процессом и может его легко модифицировать в runtime, при этом программист уже не нужен — новый бизнес-процесс автоматически обрабатывается (run) системой.
Проект первый: Институт Логистики Технического Университета Гамбурга разрабатывает софт для оптимизации товарооборота в порту Гамбурга. Ввиду того, что товарооборот зависит от типа товара и от многих других факторов, они разрабатывают систему, которая позволяет проанализировать текущий бизнес-процесс и выдать возможные рекомендации по его оптимизации.
Как это происходит, я не знаю, но конкретная задача состояла вот в чём: данные о товаре и его движении сохраняются в базе данных, в зависимости от введенных данных пользователю показываются разные формуляры, которые генерятся базой «на лету»: то есть, например, после ввода данных о прибывшем корабле с грузом появляется формуляр с грузов, если груз подлежит растомаживанию — то формуляр таможенной информации и так далее. Сами формуляры зависят от уровня доступа оператора и его роли (бухгалтеру даются иные формуляры, нежели руководителю смены грузчиков или аудитору) и связаны друг с другом сложнейшей схемой с различными переходами.
Так вот, эти схемы, какой формуляр в какой последовательности должен быть показан, реализовываются в виде Workflows, которые разрабатывает логистик в графическом редакторе, потом эти Workflows, сохраненные в XML-формате «подхватываются» .Net-assembly анализируются и преобразуются в Workflow, на основании которого подгружаются отдельные формуляры (или их части, в случае композитных формуляров). Сами формуляры, кстати, написаны в XAML и подгружаются через WPF.
Таким образом логистик (причем там их несколько с разными уровнями доступа) имеет полный контроль над бизнес-процессом и может его легко модифицировать в runtime, при этом программист уже не нужен — новый бизнес-процесс автоматически обрабатывается (run) системой.
Гм, и вы думаете, все эти сложные зависимости удобнее рисовать на диаграмме? По моему, написать несколько строчек кода может оказаться и удобнее, и быстрее (хотя конечно если упомянутый логистик не умеет программировать… то да, возможно это и имеет смысл). Вопрос, а насколько понятной будет диаграмма, чем код при довольно-таки сложной системе связей.
Кроме того, диаграмма составляется из ограниченного набора блоков. Что делать логистику, если нужного ему блока нет в стандартном комплекте?
Кроме того, диаграмма составляется из ограниченного набора блоков. Что делать логистику, если нужного ему блока нет в стандартном комплекте?
Я не знаю, насколько это «удобнее», это было такое требование со стороны логистиков. Для них подобного рода диаграммы, как я понял, обычный способ планировать их процессы.
«Написать несколько строчек» — для этого нужен постоянный программист, а у них в НИИ нет такой ставки (только сис. админ). Да и не хотят они «несколько строчек». Тут, насколько я понял, даже не проблема научить логистика программировать, сколько просто поддержка его обычной деятельности (то есть эти диаграммы он делает не только в рамках данной программы). Причем диаграммы, естессно, строились в каком-то UML-дизайнере, не в VS2008.
Его «блоки» — это различные поля баз данных, которые представляются пользователю в виде формуляров. Есть библиотека готовых формуляров (с прописаным layout) для того, чтобы использовать их как формуляры или их части. Если готового «формуляра» нет, его можно создать на лету, просто описав те поля базы данных, которые должны актуализироваться в данном формуляре. Таким образом нужные блоки просто создаются путем изменения настроек существующих блоков.
«Написать несколько строчек» — для этого нужен постоянный программист, а у них в НИИ нет такой ставки (только сис. админ). Да и не хотят они «несколько строчек». Тут, насколько я понял, даже не проблема научить логистика программировать, сколько просто поддержка его обычной деятельности (то есть эти диаграммы он делает не только в рамках данной программы). Причем диаграммы, естессно, строились в каком-то UML-дизайнере, не в VS2008.
Его «блоки» — это различные поля баз данных, которые представляются пользователю в виде формуляров. Есть библиотека готовых формуляров (с прописаным layout) для того, чтобы использовать их как формуляры или их части. Если готового «формуляра» нет, его можно создать на лету, просто описав те поля базы данных, которые должны актуализироваться в данном формуляре. Таким образом нужные блоки просто создаются путем изменения настроек существующих блоков.
Статья написана очень мутно и непонятно, в майкрософтомском стиле, очень много лишнего. Без комментариев товарищей alaudo и artvlasov честно говоря что-то понять трудно, так бы и писали с самого начала, что это средство описания бизнес-процессов и разделения труда между логистиком и кем-то там еще. А вы сначала про воду и птичек, а потом про Visual Studio. Такое ощущение что перевод или копипаста с какого-то учебника МС.
На мой взгляд, примеры alaudo и artvlasov — единичные случаи. Большинство из нас чаще сталкиваются с вещами на порядок проще. В данной статье я хотел донести именно то, что с помощью WF вы можете охватить весь бизнес процесс, что сделать глядя на код сделать невозможно. WF это инструмент, а не панацея для решения каких-то проблем.
Естественно, WF применим лишь в ограниченном количестве случаев, те 2 проекта, где мы его применяли, это примерно 5% от общего числа проектов, что были выполнены нашей фирмой за все время существования WF.
Просто workflows используются много где: SharePoint использует их для генерации buisiness logic, BizTalk вообще всецело построен на них, и в ряде случаев использование WF облегчает выполнение проекта, сильно завязанного на какие-то не всегда понятные и четко формализируемые заказчиком процессы.
Просто workflows используются много где: SharePoint использует их для генерации buisiness logic, BizTalk вообще всецело построен на них, и в ряде случаев использование WF облегчает выполнение проекта, сильно завязанного на какие-то не всегда понятные и четко формализируемые заказчиком процессы.
Т.е. с вашей точки зрения использование WF в более простых проектах не имеет смысла? Тех же сайтах или клиентских приложениях? Они вроде хорошо подходят под state-machine, например.
Наверное я не совсем точно выразился.
Наверняка найти применение WF можно много где, а учитывая, что WF Runtime может хоститься как IIS, там и Windows Service и вообще любым приложением, позволяет его много куда «запихнуть».
Идея с сайтом, кстати, очень интересная — я здесь соглашусь, было бы интересно, тем более что SharePoint как раз и основан на workflows. Просто я никогда не разрабатывал сложных сайтов.
В целом, наверное, при надлежащем умении, данную технологию можно использовать довольно широко. Только учитывайте, что Майкрософт в версии .Net 4.0 полностью заново напишет этот Framework, обещая увеличение скорости в 100-1000 раз. Демонстрации, что я видел в Берлине на Technical Summit действительно впечатляли.
Наверняка найти применение WF можно много где, а учитывая, что WF Runtime может хоститься как IIS, там и Windows Service и вообще любым приложением, позволяет его много куда «запихнуть».
Идея с сайтом, кстати, очень интересная — я здесь соглашусь, было бы интересно, тем более что SharePoint как раз и основан на workflows. Просто я никогда не разрабатывал сложных сайтов.
В целом, наверное, при надлежащем умении, данную технологию можно использовать довольно широко. Только учитывайте, что Майкрософт в версии .Net 4.0 полностью заново напишет этот Framework, обещая увеличение скорости в 100-1000 раз. Демонстрации, что я видел в Берлине на Technical Summit действительно впечатляли.
Что меня действительно удивило, так это даже текущая скорость выполнения. Я попробовал создать процесс добавления объектов в базу (информация о судах: скорость, курс и еще два десятка параметров) и время исполнения практически не отличалось от классического императивного подхода. Процесс, конечно, никакой и внедрения не стоит, но такого результата не ожидал.
А у меня почему-то сложилось впечатление, что вы просто предвзято ко всему этому относитесь.
В вашем профайле нашел «php, css, mysql, js». Вы много «учебников МС» прочитали? Или тех же статей, которые могли стать источником перевода?
В вашем профайле нашел «php, css, mysql, js». Вы много «учебников МС» прочитали? Или тех же статей, которые могли стать источником перевода?
Не успел утром дописать:
Проект второй. Мы делали по заказу фирмы из Гамбурга, что обслуживает корабли, следующий проект: корабли имеют дорогую спутниковую связь, которая работает пакетами, то есть при накоплении некоего критического объема данных (разные заполненные морские документы учета в XML-формате, разные отчёты капитана и прочее) эти данные сжимаются и шифруются, после чего пересылаются по спутниковой связи в виде пакета в центральный офис компании, где этот пакет расшифровывается, расжимается и документы в зависимости от их типа данных, либо копируются во внутренние папки сотрудников (бухгалтеров, менеджеров), либо заливаются в базу данных и прочее.
Технически все это работало как Windows Service, которая с определенным интервалом проверяло определеные пути на центральном сервере корабля и выполняла все действия, если находила там файлы. В центральном офисе другая служба занималась распределением всего контена по папкам и заливкой в базу.
У самой фирмы не было IT-отдела, поэтому проект достался нам, но у них был свой ответственный за техническое обеспечение, с которым процесс отбора файлов, шифрования, сжатия, пересылки и распеделения был обсужден в малейших деталях и который желал иметь полный контроль над всем процессом, при этом не углубляясь в код.
В этом случае как раз идеально подошел уже готовый workflow, который, кстати, был несколько раз переделан для учета отдельных желаний по генерации ключа шифрования и алгоритмов сжатия. При этом весь процесс оставался видимым и понятным, обсуждение велось на уровне алгоритмов, а не исходного кода, что позволило гораздо быстрее найти общий язык и сделать проект.
Проект второй. Мы делали по заказу фирмы из Гамбурга, что обслуживает корабли, следующий проект: корабли имеют дорогую спутниковую связь, которая работает пакетами, то есть при накоплении некоего критического объема данных (разные заполненные морские документы учета в XML-формате, разные отчёты капитана и прочее) эти данные сжимаются и шифруются, после чего пересылаются по спутниковой связи в виде пакета в центральный офис компании, где этот пакет расшифровывается, расжимается и документы в зависимости от их типа данных, либо копируются во внутренние папки сотрудников (бухгалтеров, менеджеров), либо заливаются в базу данных и прочее.
Технически все это работало как Windows Service, которая с определенным интервалом проверяло определеные пути на центральном сервере корабля и выполняла все действия, если находила там файлы. В центральном офисе другая служба занималась распределением всего контена по папкам и заливкой в базу.
У самой фирмы не было IT-отдела, поэтому проект достался нам, но у них был свой ответственный за техническое обеспечение, с которым процесс отбора файлов, шифрования, сжатия, пересылки и распеделения был обсужден в малейших деталях и который желал иметь полный контроль над всем процессом, при этом не углубляясь в код.
В этом случае как раз идеально подошел уже готовый workflow, который, кстати, был несколько раз переделан для учета отдельных желаний по генерации ключа шифрования и алгоритмов сжатия. При этом весь процесс оставался видимым и понятным, обсуждение велось на уровне алгоритмов, а не исходного кода, что позволило гораздо быстрее найти общий язык и сделать проект.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Microsoft Workflow Foundation