Знакомство с
Службы WCF и WF в .NET Framework 4.0 и “Dublin”
Аарон Сконнард (Aaron Skonnard)
Эта статья основана на предварительной версии .NET Framework 4.0 и "Dublin". В любую содержащуюся в ней информацию могут быть внесены изменения.
В данной статье рассматриваются следующие вопросы.
|
В данной статье используются следующие технологии: .NET Framework 4.0, “Dublin” |
Содержание
Продвигаясь к .NET Framework 4.0
Библиотека базовых действий WF
Модель программирования действий WF
Дополнительные новые функции WCF в .NET Framework 4.0
Потребность в "Dublin"
Руководство по "Dublin"
Создание службы рабочих процессов WCF для "Dublin"
Развертывание приложений с помощью "Dublin"
Управление работающими приложениями
Обновление работающих приложений
Наблюдение за работающими приложениями
От "Dublin" к "Oslo"?
Как насчет BizTalk Server?
На конференции профессиональных разработчиков (PDC) в октябре 2008 года корпорация Майкрософт представила сведения о многочисленных улучшениях, которые будут поставлены в Microsoft .NET Framework 4.0, в частности в областях Windows Communication Foundation (WCF) и Windows Workflow Foundation (WF). Майкрософт также продемонстрировала некоторые расширения к Windows Server (под кодовым названием "Dublin"), которые представят улучшенное размещение и управление для приложений WCF и WF.
Интеграция WF и WCF в .NET Framework 4.0 сделает более простой разработку ориентированных на службы приложений. Пользователи будут иметь возможность создавать сохраняющие состояние службы рабочего процесса, используя полностью декларативную модель, предлагающую большую гибкость и деловую динамичность.
Новые расширения размещения и управления, представленные "Dublin", дополняют эти усовершенствования инфраструктуры. Сочетание усовершенствований в самой инфраструктуре и в рабочих средствах, поддерживающих ее, означает, что возможности сервера приложений в Windows Server сделают значительный шаг вперед.
В этой статье я рассмотрю некоторые из ключевых новых функций WCF и WF в .NET Framework 4.0, а также новые возможности сервера приложений, предоставляемые расширениями "Dublin".
Продвигаясь к .NET Framework 4.0:
WCF и WF – взаимодополняющие технологии. Для тех, кто с ними не знаком, проще всего представить себе эту пару следующим образом: WCF снаружи, WF внутри. WCF используется для предоставления внешнего интерфейса службы приложения, а WF используется для описания внутреннего потока, состояний и переходов приложения.
.NET Framework 3.5 представила некоторые заманчивые формы интеграции между ними, а именно действия отправки и получения WF. С помощью этих действий WF можно применить для упрощения процесса координации взаимодействий нескольких служб для выполнения комплексных, долговременных рабочих процессов. Можно также использовать эти действия для повышения досягаемости рабочих процессов WF, путем включения их с помощью конечных точек WCF (см. рис. 1). Это, по сути, позволяет применять WF как реализацию служб WCF, которые я буду называть службами рабочих процессов WCF в оставшейся части статьи.
Рис. 1. Службы рабочих процессов WCF
Хотя службы рабочего процесса WCF и можно применять в .NET Framework 3.5, это непросто. Для начала, уровень интеграции между WCF и WF оставляет желать лучшего. В .NET Framework 3.5, артефакты WCF нужно определять и настраивать с использованием модели программирования и конфигурации WCF, тогда как рабочий процесс определяется с использованием иной модели. В конечном итоге, может получиться несколько артефактов, требующих отдельного развертывания, настройки и управления.
Другая причина сложности заключается в том, что текущая библиотека базовых действий концентрируется на контроле над процессом и логических действий, предоставляя довольно мало в области рабочих действий. Так что перед применением реальных служб рабочего процесса с помощью WF необходимо написать библиотеку собственных действий. Учитывая сложность этой работы, некоторые разработчики сдались, прежде чем сумели воспользоваться преимуществами WF.
Вдобавок к этим проблемам у текущего WF также отсутствуют средства, поддерживающие рабочие процессы, использующие только язык eXtensible Application Markup Language (XAML), которые также именуются декларативными рабочим процессами, поскольку они полностью описываются в файле XML, безо всяких фоновых файлов. Эксклюзивное использование XAML дает некоторые заманчивые возможности в плане размещения и развертывания. Возможности декларативного рабочего процесса заключены в том, что это просто данные, которые можно хранить где угодно и исполнять внутри среды выполнения WF, знающей об используемых действиях.
Декларативный рабочий процесс может быть развернут в среде выполнения в «облаке» или на рабочей станции под столом пользователя (предполагая, что действия были развернуты в среду исполнения). Декларативные рабочие процессы также проще разбивать на версии и их можно использовать в сценариях частичного доверия (вспоминаем «облако»). Также, на основе модели, полностью работающей на XAML, проще создавать средства, поскольку средства просто работают с файлами XML.
В целом, такая модель всегда была идеальной концепцией для WF как технологии, что очевидно из ранних статей ее архитекторов. Однако существующий набор средств WF не вполне реализует эту концепцию. Хотя создавать рабочие процессы, использующие только XAML, с помощью .NET Framework 3.5, возможно, для этого необходимо обходить существующие шаблоны Visual Studio и жертвовать важными функциями, такими как отладка.
Основной целью WCF и WF в .NET Framework 4.0 является упрощение задач разработчика в области декларативных процессов и служб, посредством полного принятия модели эксклюзивного использования XAML. Кроме того, целью корпорации Майкрософт было продвинуться на шаг дальше, сделав возможным определение служб декларативного рабочего процесса. А это значит – служб WCF, полностью определенных в терминах XAML, включая определения контрактов служб, конфигурации конечных точек и собственно реализацию служб (в форме рабочего процесса на основе XAML).
Чтобы добиться этого, корпорация Майкрософт внесла многочисленные улучшения в .NET Framework 4.0, включая расширенную библиотеку действий базовых классов, упрощенную модель программирования для пользовательских действий, новый тип рабочего процесса схемы и многочисленные улучшения, относящиеся конкретно к WCF.
Библиотека базовых действий WF
.NET Framework 4.0 поставляется с усовершенствованной библиотекой базовых действий, содержащей несколько новых действий (см. рис. 2). Корпорация Майкрософт также планирует начать предоставление дополнительных действий WF через CodePlex между крупными выпусками .NET Framework. Кроме того, в будущих выпусках (или в CodePlex) будет больше рабочих действий, с тем, чтобы уменьшить тем самым необходимость в разработке собственных действий. А поскольку корпорация Майкрософт использует CodePlex, пользователям предоставляется хорошая возможность довести до нее свое мнение о том, какие дополнительные действия они хотят видеть.
.NET Framework 4.0 представляет несколько основных действий, дающих больше возможностей по контролю процесса, включая действия FlowChart, ForEach, DoWhile и Break. Новое действие FlowChart («Блок-схема») является одной из наиболее интересных добавок, поскольку оно предлагает интересный промежуточный вариант между моделями контроля процесса Sequential («Последовательная») и StateMachine («Механизм состояния»). FlowChart позволяет использовать поэтапный подход, усовершенствованный посредством простых решений и переключателей, но также позволяет возвращаться к предыдущим действиям в рабочем процессе. Блок-схемы в целом кажутся более интуитивными большинству пользователей. Рис. 3 показывает, на что похож конструктор FlowChart в новом конструкторе рабочих процессов Visual Studio 2010 (дополнительные сведения смотри на боковой панели «Новый конструктор рабочих процессов»).
Рис. 3. Новый конструктор действий FlowChart
.NET Framework 4.0 также предоставляет некоторые новые действия рабочей среды для вызова методов CLR (MethodInvoke), для выделения значений переменным рабочего процесса (Assign) и для прямого сохранения работающего экземпляра рабочего процесса (Persist).
Наконец, .NET Framework 4.0 поставляется с новым набором действий на основе WCF, упрощающим процесс предоставления рабочих процессов как служб или употребления служб изнутри рабочих процессов. .NET Framework 3.5 предоставляла два действия (Send и Receive) для, соответственно, отправки и получения сообщений через WCF. В версии 4.0 можно найти действия SendMessage и ReceiveMessage (предназначенные для отправки и получения односторонних сообщений, подобно Send и Receive в версии 3.5), а также абстракции более высокого уровня для операций запроса/ответа через действия ClientOperation и ServiceOperation. Рабочему процессу, от которого требуется предоставление операции службы, следует использовать действие ServiceOperation. Рабочему же процессу, от которого требуется потребление внешней службы, следует использовать действие ClientOperation.
В дополнение к этим основным действиям WCF, .NET Framework 4.0 также предоставляет поддержку корреляции между различными односторонними операциями, чтобы обеспечить возвращение определенного сообщения к нужному экземпляру рабочего процесса. В нее входят действия для определения новой области корреляции (CorrelationScope) и для инициализации значений корреляции (InitializeCorrelation) перед отправкой исходящего сообщения через WCF.
Новый конструктор рабочих процессов
Новый конструктор рабочих процессов, добавленный к Visual Studio 2010, предоставляет привлекательное графическое обслуживание пользователя для многих ключевых компонентов WCF и WF, упомянутых в этой статье. Он предоставляет такие функции, как улучшенные переходы по рабочим процессам (углубление в оставленные действия), с последовательностями для возвращения к прежней области, редактирование действий на месте (что уменьшает потребность в окне свойств), возможности масштабирования и обзорные переходы. Кроме того, новый конструктор предоставляет улучшенную модель индивидуализации и повторного размещения. Visual Studio 2010 также предложит набор новых или улучшенных шаблонов проектов, позволяющим легко приступить к работе с блок-схемами и рабочими процессами на основе чистого XAML и предоставить полную поддержку для отладки на основе XAML при работе с декларативными рабочими процессами и службами.
Модель программирования действий WF
Даже с этими улучшениями порой может возникнуть потребность в написании собственных действий. Чтобы упростить это, корпорация Майкрософт переработала базовые классы под пользовательские действия. Новый базовый класс для пользовательских действий именуется WorkflowElement, и существует другой, производный от него, класс, именуемый Activity. Класс Activity делает несложным создание новых действий из существующих действий, почти, если не вообще без написания кода.
Рис. 4, например, показывает, как определить новое собственное действие, именуемое CopyFile, производя его от Activity и переопределяя CreateBody. Эта реализация создает индивидуализированный экземпляр PowerShellCommand, настроенный на использование встроенной команды копирования элемента. Собственные действия, подобные этому, можно также без труда создавать, используя новый конструктор рабочих процессов в Visual Studio 2010, через графический конструктор действий, если есть желание вообще обойтись без кода этого типа.
Рис. 4. Пользовательское действие CopyFile
class CopyFile : Activity
{
public InArgument<string> Source { get; set; }
public InArgument<string> Destination { get; set; }
protected override WorkflowElement CreateBody()
{
return new PowerShellCommand
{
CommandText = "copy-item",
Parameters =
{
{ "path", new InArgument<string>(Source) },
{ "destination", new InArgument<string>(Destination) } ,
{ "recurse", new InArgument<bool>(false) }
},
};
}
}
Когда необходимо определить собственное действие с нуля (нечто не основанное на существующих действиях), необходимо создать производное от WorkflowElement и переопределить метод Execute. Этот подход требует немного больше кода и подобен тому, как создание производных от Activity работает сейчас. Однако корпорация Майкрософт дополнительно упростила то, что касается написания этих пользовательских действий.
К числу вещей, делающих сложным написание собственных действий, принадлежит управление потоком данных в действие и из него. Например, сегодня невозможно определить набор типизированных аргументов, передаваемых в действие и из него. Обычно разработчики пишут собственные классы, сериализирующие и десереализирующие аргументы из очереди рабочего процесса (больше об этом можно прочесть в статье Майкла Кеннеди (Michael Kennedy), «Веб-приложения, поддерживающие длительно выполняемые рабочие процессы»). Написание этого коммуникационного кода несложно, но отвлекает от реальной задачи моделирования потока приложений. .NET Framework 4.0 расширяет модель программирования действий с помощью трех новых концепций потока данных, обещающих существенно упростить дело: аргументов, переменных и выражений.
Аргументы используется для определения способа, которым данные вводятся в действие и выводятся из него. У каждого аргумента имеется указанное направление привязки, такое как ввод, вывод или ввод/вывод. Следующие пример показывает, как создать простое действие Audit с помощью простого аргумента ввода, именуемого "AuditMessage":
public class Audit: WorkflowElement {
public InArgument<string> AuditMessage{ get; set; }
protected override void Execute(ActivityExecutionContext context) {
WriteToEventLog(AuditMessage.Get(context));
}
}
Переменные предоставляют способ объявления именованных хранилищ для данных. Переменные можно определять в коде, точно также как в рабочих процессах на основе XAML. Переменные также можно определять в различных областях внутри рабочего процесса (внутри вложенных элементов рабочего процесса) и они являются частью определения программы рабочего процесса во время разработки, тогда как значения сохраняются в экземпляре рабочего процесса во время выполнения.
Нижеследующий пример показывает, как написать рабочий процесс XAML, определяющий переменную «сообщение», назначающий ей значение (используя новое действие Assign) и передающей значение переменной ранее определенному пользовательскому действию Audit:
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<Assign x:TypeArguments="p:String" To="[message]"
Value="Audit message: something bad happened" />
<s:Audit Text="[message]" />
</Sequence>
Выражение – это конструкция, принимающая один или несколько аргументов ввода, выполняющая на этих аргументах какие-либо операции или поведение и затем возвращающая значение. Выражения определяются путем создания класса, производного ValueExpression, который сам является производным от WorkflowElement, так что выражения можно использовать везде, где можно использовать действие. Выражения также можно использовать как привязку к аргументу другого действия. Данный пример определяет простое выражение Format:
public class Format : ValueExpression<string> {
public InArgument<string> FormatString { get; set; }
public InArgument<string> Arg { get; set; }
protected override void Execute(ActivityExecutionContext context) {
context.SetValue(Result,
String.Format(FormatString.Get(context), Arg.Get(context)));
}
}
Это выражение можно включать в рабочие процессы XAML подобно любому другому действию. Например, следующий рабочий процесс иллюстрирует, как передавать результат выражения Format действию Audit, для записи результатов в журнал событий (это предполагает, что содержимое Audit соответствует аргументу сообщения):
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<s:Audit>
<s:Format FormatString="Audit message: {0}" Arg="[message]"/>
</s:Audit>
</Sequence>
Также следует отметить, что в корневых действиях нет ничего особенного. Все, что производится от WorkflowElement, может быть использовано как корень в любой точке рабочего процесса. Это позволяет произвольно составлять различные стили рабочих процессов, один внутри другого (например, механизм состояния внутри блок-схемы, внутри последовательности.
Основная часть этих изменений в программной модели позволяет сделать декларативные рабочие процессы полноправные компоненты, поскольку для определения свойств потока данных более не требуется файлов процедурного фонового кода – теперь все можно делать декларативно в XAML. Но поскольку это довольно фундаментальные изменения, они потребовали некоторых существенных изменений в среде выполнения WF, которые, в конечном итоге, устраняют совместимость с действиями .NET Framework 3.x (дополнительные сведения см. на боковой панели по переносу рабочих процессов). Но, несмотря на это, корпорация Майкрософт верит, что упрощение программной модели WF принесет разработчикам WF большие блага с течением времени.
Перенос рабочих процессов в .NET 4.0
Новая модель программирования действий .NET Framework 4.0 потребовала некоторых существенных изменений в ядре среды выполнения WF. Как следствие, пользовательские действия, разработанные для .NET Framework 3.0 и 3.5, не смогут работать внутри среды размещения рабочего процесса .NET Framework 4.0 без приложения специальных усилий.
Чтобы поспособствовать взаимодействию, .NET Framework 4.0 поставляется со специальным действием Interop, которое позволяет легко заключить действие .NET 3.x внутрь среды .NET 4.0. Этот подход работает не для всех действий .NET 3.x – он однозначно не работает для корневых действий. В силу этого, при переходе на Visual Studio 2010, необходимо переработать рабочие процессы, используя новый конструктор рабочих процессов (поскольку в него также были внесены широкие изменения), после чего пользовательские действия .NET 3.x можно будет размещать внутрь новых определений рабочих процессов, используя новое действие Interop.
Дополнительные новые функции WCF в .NET Framework 4.0
Легко увидеть, как можно реализовать службу WCF с помощью рабочего процесса, но, чтобы действительно создать декларативную службу рабочих процессов, также необходим способ определения контрактов службы и настройки определений конечных точек с помощью декларативной модели эксклюзивного использования XAML. Именно это и предлагает WCF в .NET Framework 4.0. Предположим, что у нас есть определение контракта службы WCF:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int Op1, int Op2);
[OperationContract]
int Subtract(int Op1, int Op2);
};
В .NET Framework 4.0 тот же контракт можно определить декларативно, используя следующее определение XAML:
<ServiceContract Name="ICalculator">
<OperationContract Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res1" Type="p:Int32" />
</OperationContract>
<OperationContract Name="Subtract">
<OperationArgument Name="Op3" Type="p:Int32" />
<OperationArgument Name="Op4" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res2" Type="p:Int32" />
</OperationContract>
</ServiceContract>
Теперь, когда у нас есть контракт службы, определенный XAML, следующим этапом является определение того, как его можно спроецировать на среду передачи. .NET Framework 4.0 представляет концепцию проекции контрактов, для разделения логического определения контракта от представления отправляемых и получаемых сообщений. Это позволяет определить контракт одной службы, который можно проецировать различными способами для поддержки различных стилей обмена сообщениями.
Например, может иметься одна проекция контракта для обмена сообщениями на основе SOAP и ругая проекция для обмена сообщениями REST/POX, но обе они основаны на одном и том же логическом контракте службы. Вот как можно определить проекцию контракта SOAP для только что определенного контракта службы:
<Service.KnownProjections>
<SoapContractProjection Name="ICalculatorSoapProjection">
<!-- service contract definition goes here -->
</SoapContractProjection>
</Service.KnownProjections>
При наличии этого определения и проекции контракта, имеется возможность реализовать логику службы в XAML. Корневым элементом для определения службы XAML является Service («Служба»). Элемент Service содержит контракт и определения проекций в дочернем элементе Service.KnownProjections. Применение службы происходит в элементе Service.Implementation (являющемся декларативным рабочим процессом). И, наконец, конфигурация конечной точки службы идет в элементе Service.Endpoints. Рис. 5 показывает полное декларативное определение службы в XAML.
Рис. 5. Декларативная служба WCF
<Service xmlns="clr-namespace:System.ServiceModel;assembly=System.WorkflowServiceModel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:ss="clr-namespace:System.ServiceModel;assembly=System.ServiceModel"
xmlns:sw="clr-namespace:System.WorkflowServiceModel;assembly=System.WorkfowServiceModel"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:x2="https://schemas.microsoft.com/netfx/2008/xaml">
<Service.KnownProjections>
<SoapContractProjection x:Name="ICalculatorSoapProjection">
<ServiceContract x:Name="ICalculatorContract"
<OperationContract Name="Add" x:Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="Result"
Type="p:Int32" />
</OperationContract>
</ServiceContract>
</SoapContractProjection>
</Service.KnownProjections>
<Service.Implementation>
<sw:WorkflowServiceImplementation>
<!-- place service implementation here -->
</sw:WorkflowServiceImplementation>
</Service.Implementation>
<Service.Endpoints>
<Endpoint Uri="http://localhost:8080/calc"
ContractProjection="{x2:Reference ICalculatorSoapProjection}">
<Endpoint.Binding>
<ss:BasicHttpBinding />
</Endpoint.Binding>
</Endpoint>
</Service.Endpoints>
</Service>
Один из недостатков на этой ранней стадии заключается в отсутствии визуального конструктора для помощи в декларативном конструировании служб. Я надеюсь, что по мере появления предварительных версий (CTP), Майкрософт предоставит более удобные для разработчика способы работы с определением XAML.
Вдобавок к поддержке декларативных служб и вышеупомянутым действиям на основе WCF, .NET Framework 4.0 поставляется с несколькими другими низкоуровневыми улучшениями WCF. Некоторые из этих функций делают возможным управление службами рабочих процессов с помощью новых расширений "Dublin". Эти функции включают улучшенную конфигурацию, корреляцию сообщений, устойчивую дуплексную связь, устойчивые таймеры и интеграцию трассировки событий для Windows (ETW). Другими возможностями, увеличивающими их ценность при размещении служб в управляемой среде, являются стандартные конечные точки управления и автозапуск. В последующие месяцы читатели смогу услышать больше об этих функциях.
Потребность в "Dublin"
В реальном мире еще одним сложным аспектом работы с WCF и WF является обдумывание того, где разместить службы и рабочие процессы в серверной среде. Для WCF ответ обычно довольно прост – самыми распространенными вариантами являются IIS и служба активации процессов Windows Process Activation Service (WAS) в Windows Server 2008.
Сейчас комбинация IIS и WAS предоставляет ряд ключевых функций, включая активацию процессов в ответ на входящие сообщения, наблюдение за процессами, управление их работоспособностью и их повторное использование, интеграцию CLR AppDomain, встроенные возможности безопасности и некоторые базовые возможности управления, сделанные доступными через IIS Manager и командлеты Windows PowerShell. Сочетание этих функций обычно делает IIS/WAS верным выбором для размещения служб WCF в серверной среде, поскольку большинство людей не желают создавать нечто подобное самостоятельно.
Хотя сочетание IIS/WAS предоставляет основание для размещения приложений WCF, оно неадекватно в нескольких важных областях. Его крупнейший недостаток лежит в области управляемости служб. На деле IIS/WAS не предоставляет специфические возможности управления службами WCF, такие, как трассировка служб, наблюдение за работающими экземплярами служб и их диагностика. Например, в настоящий момент администратор не может перечислить все службы WCF, настроенные в IIS – запросить состояние всех размещенных служб невозможно. IIS/WAS также не предоставляет встроенной поддержки для упрощения развертываний расширения или обычных задач настройки WCF, что оказывается больным местом для WCF.
Проблемы размещения еще хуже для приложений WF в серверных средах благодаря тому, что модель, требуемая для поддержки длительно выполняемых рабочих процессов на нескольких фермах серверов, по природе своей сохраняет состояние. Из-за этих сложностей корпорация Майкрософт не поставляла узел сервера WF в .NET Framework 3.0 – разработчикам приходилось писать его самим. Лишь в .NET Framework 3.5, с появлением класса WorkflowServiceHost, изначальная конфигурация начала позволять размещение рабочих процессов WF как служб WCF, тем самым делая возможным и размещение рабочих процессов WF внутри IIS/WAS.
WorkflowServiceHost был хорошим началом, но у него не было средств для поддержки управления рабочими процессами с сохранением состояния по всей ферме веб-серверов, равно как и средств для наблюдения за работающими экземплярами процесса во время выполнения и управления ими.
В плане функций управления службами и рабочими процессами, большинство разработчиков ожидает нечто подобное тому, что предоставляется BizTalk Server, но проще. Большинство организаций желают управления в стиле BizTalk, но им не нужны возможности интеграции или семантика надежности (и связанное с ними потребление ресурсов), неотъемлемые от BizTalk Server MessageBox. Более адекватна относительно легкая модель, специально разработанная для приложений WCF и WF.
Руководство по "Dublin"
Корпорация Майкрософт уже некоторое время работала над набором расширения к Windows Server (под кодовым названием "Dublin"), который представит ценные функции размещения и управления для приложений WCF и WF. "Dublin", по сути, является набором расширений управления службами, построенным на основе IIS/WAS, который будет поставляться как часть Windows Server. При использовании расширений "Dublin", службы и рабочие процессы по-прежнему будут размещаться в IIS/WAS, но приложения смогут воспользоваться дополнительными возможностями и средствами управления, специально для WCF и WF, которых сейчас нет в IIS/WAS.
Различные расширения "Dublin" будут поставляться в будущей версии Windows Server, как часть роли сервера приложений Windows Server. Поэтому данный набор компонентов часто именуется сервером приложений Windows, хотя это и не официальное название, одобренной Майкрософт. В оставшейся части статьи я буду называть эти новые расширения сервера приложений Windows Server просто "Dublin".
Ключевые возможности, предоставляемые расширениями "Dublin", включают поддержку управления для надежных и устойчивых служб, а также длительно выполняемые рабочие процессы. "Dublin" делает возможным развертывание приложений на отдельных серверах внутри фермы и предоставляет средства, необходимые для выполнения конкретных задач управления службами. Я расскажу об этих возможностях подробнее в следующих разделах, но сперва давайте взглянем на общую архитектуру, проиллюстрированную на рис. 6.
Рис. 6. Архитектура “Dublin”
Как можно увидеть, "Dublin" предоставляет несколько баз данных времени выполнения, закладывающих основание для сохранения служб и наблюдения за ними. Существует слой компонентов и служб времени выполнения, предоставляемый .NET Framework, ведущий работу на основе этих баз данных. "Dublin" дополнительно расширяет эти среды выполнения, для предоставления интегрированных возможностей размещения, сохранения, наблюдения и обмена сообщениями. Этот слой, в сочетании с лежащими в основе базами данных времени выполнения и составляет то, что именуется "Dublin".
Верхние два слоя в архитектуре – это то, что делает "Dublin" пригодным к использованию людьми. Имеется слой API управления, делающий различные возможности вносимыми в сценарии, через командлеты Windows PowerShell. Поверх всего этого находится обслуживание IIS Manager, которое должно казаться знакомым нынешним администраторам IIS, поскольку оно, на деле, является надстройкой над командлетами Windows PowerShell. Так что все, что можно сделать в IIS Manager, также можно сделать в Windows PowerShell.
Корпорация Майкрософт добавила к IIS Manager многочисленные расширения интерфейса пользователя, для выполнения различных задач размещения и управления, описанных в этом разделе. В их числе имеются расширения для развертывания и настройки приложений, управления приложениями и наблюдения за приложениями. Эти расширения также предоставляют модель мониторинга среды выполнения системы, показывающую такие вещи, как работающие, приостановленные и сохраненные экземпляры рабочих процессов.
Создание службы рабочих процессов WCF для "Dublin"
Visual Studio 2010 делает очень простым создание служб, нацеленных на расширения "Dublin", посредством нового шаблона проекта (см. рис. 7). Этот шаблон проекта дает web.config, заранее настроенный на предоставляемого "Dublin" поставщика сохранения и устойчивую службу таймеров.
Рис. 7. Создание новой библиотеки служб “Dublin”
После того, как рабочий процесс создан, можно сконцентрироваться на реализации службы рабочего процесса WCF, с использованием различных методик, описанных выше в данной статье. Способ работы нового конструктора рабочих процессов делает возможным реализацию всей службы с использованием подхода графической разработки рабочих процессов. После того, как создание законченной службы рабочего процесса завершено, можно развернуть службу на Windows Server, снабженный расширениями "Dublin".
Службы можно развертывать на IIS/WAS, используя ту же методику, что обычно используется для веб-приложений (ее можно развернуть напрямую из Visual Studio, если среда позволяет это). Для автоматизации этих задач можно также использовать командлеты Windows PowerShell. (Эти командлеты позволяет создавать автоматизированные сценарии развертывания для сред WCF и WF. Если нужно использовать любой из этих командлетов, просто откройте Windows PowerShell на сервере приложений Windows и введите "help <command>", чтобы узнать, как приступить к работе с этой конкретной командой. После развертывания, можно начать использовать IIS Manager для доступа к различным расширениям "Dublin", выделенным на рис. 8.
Рис. 8. Расширения “Dublin” в IIS Manager
Развертывание приложений с помощью "Dublin"
Многие среды не позволяют разработчикам развертывать службы напрямую на их управляемые серверы, по соображениям безопасности и изоляции. "Dublin" предоставляет альтернативное решение для развертывания служб через его функции экспорта/импорта компонентов.
Приложения WCF и WF можно заключать в пакеты для развертывания на других серверах, выбирая функцию экспорта приложений в IIS Manager. Это выведет диалог, запрашивающий выбор определенного приложения для экспорта. После указания местоположения, нажатие кнопки экспорта создаст файловый пакет с расширением ZIP, содержащий весь код WCF и WF, а также метаданные и параметры настройки для одного приложения. Затем этот пакет можно перемещать и импортировать на другой сервер через расширения "Dublin". Теперь можно просто отправить файл ZIP ИТ-специалисту, управляющему серверами и позволить ему разобраться с ним.
Командлет Export-Application в Windows PowerShell выполняет ту же функцию. Возможность экспорта приложений также приходится очень кстати для системных тестов и в средах проверки.
Импортировать приложение WCF и WF можно, выбрав функцию импорта приложений, или используя командлет Import-Application (можно также просмотреть содержимое пакета, используя командлет Get-PackageManifest). Функция импорта напомнит выбрать пакет (ZIP), который нужно импортировать.
В ходе процесса, можно указать имя приложения, пул приложений и, если хочется, физический путь для приложения. А поскольку "Dublin" предоставляет централизованную конфигурацию сохранения при развертывании служб рабочих процессов на другом сервере, нет нужды волноваться об изменении конфигурации сохранения на уровне приложений. Он просто использует новую базу данных сохранения состояния, связанную с новым сервером. Эти функции делают процесс развертывания приложений WCF и WF в серверной среде весьма доступным для системного администратора, отвечающего за эти задачи.
После успешного развертывания приложения, можно приступить к настройке служб через другие расширения, предоставляемые "Dublin." Например, в некоторых ситуациях от системного администратора может потребоваться ручная перенастройка конфигурации среды выполнения для баз данных сохранения состояния и отслеживания. С помощью расширений "Dublin", это довольно просто. Просто выберите Services («Службы») из представления по умолчанию, после чего можно будет увидеть список всех управляемых служб, вместе с правой панелью, предоставляющей различные варианты настройки служб (см. рис. 9). Эти параметры позволяют легко изменять параметры сохранения состояния, отслеживания и другие параметры WCF, связанные с безопасностью и ограничением скорости. А файла конфигурации WCF не нужно даже касаться.
Рис. 9. Просмотр и настройка служб с помощью расширений “Dublin”
Существует несколько командлетов Windows PowerShell для выполнения этих задач, включая Get-ServicePersistence, Set-ServicePersistence, Enable-ServiceTracking и Get-TrackingParticipant. Это означает значительное упрощение автоматизации установки и настройки среды сервера приложений.
Управление работающими приложениями
В течение жизненного цикла приложения, разработчикам и системным администраторам необходима возможность наблюдать за работоспособностью приложения, определять и просматривать проблемные экземпляра рабочих процессов и прерывать их, по мере необходимости. "Dublin" предоставляет многочисленные расширения, нацеленные на эти обычные потребности управления.
В случае выбора варианта сохраненных экземпляров в IIS Manager (см. рис. 8), пользователь будет перенесен в представление панели мониторинга, предоставляющее обзор работающих экземпляров рабочего процесса, которые были сохранены и, потенциально, приостановлены (см. рис. 10). Поле обзора отображает общее число приложений и служб, развернутых на сервере, веб-сайте или приложении (в зависимости от выбранной области).
Рис. 10. Просмотр сохраненных результатов рабочего процесса
Поле сохраненных экземпляров отображает сводку работающих и сохраненных рабочих процессов, вызывая те, что могут быть заблокированы или приостановлены (это значит, что они закончились ошибкой). Поскольку приостановленные экземпляры – это, как правило, те, с которыми персоналу придется иметь дело напрямую, они предоставляют несколько других полей, делающих несложным выделение конкретных приостановленных экземпляров на основе виртуального пути, имени службы или типа исключения.
Можно щелкнуть на любую из ссылок (показанных в синем цвете), чтобы отобразить список сохраненных экземпляров и просмотреть сведения о них. На этом этапе можно приостанавливать, прерывать или отменять экземпляры службы вручную, выбирая из действий показанных на правой панели (см. рис. 11). Приостановка экземпляра службы останавливает исполнение экземпляра и не дает ему получать новые сообщения. Приостановленные экземпляры можно позднее возобновить – на этом этапе они начнут получать сообщения снова. Прерывание экземпляра службы останавливает исполнение экземпляра и удаляет его из постоянного хранилища, а это значит, что его исполнение нельзя возобновить. Наконец, отмена экземпляра службы очищает состояние памяти, относящееся к данному экземпляру и возвращается к последней точке сохранения (находящейся в постоянном хранилище).
Рис. 11. Просмотр индивидуальных сохраненных экземпляров
Такие командлеты Windows PowerShell, как Get-ServiceInstance и Stop-ServiceInstance предлагают эквивалентные возможности из командной строки; они предоставляют многочисленные параметры командной строки для определения конкретных экземпляров служб.
Обновление работающих приложений
Одним из особенно проблемных аспектов работы с реальными системами, является необходимость периодически обновлять их. Это может быть непросто сделать верно для комплексных распределенных приложений, когда необходимые изменения требуют обновлений в базе данных бизнес логике и коде служб одновременно. Как правило, невозможно применить существенные управления по кусочкам, пока приложение работает.
Одним из подходов к проблеме является отключение приложения на время выполнения обновления. Однако, если задуматься об этом, становится ясно, что простого способа вывода приложения IIS/WAS в автономный режим, с одновременным выполнением обновления на веб-сайте, не существует. Это еще одна область, в которой расширения "Dublin" добавляют ценные возможности через простой автономный компонент.
Можно выбрать приложение в IIS Manager и затем выбрать команду отключения протоколов в правой панели, показанной на рис. 8 (важно отметить, что она, вероятно, будет переименована в будущем выпуске). Это заставит все экземпляры служб приложения завершиться в блокированном состоянии или завершить свое исполнение естественно, не допуская обработку в это время новых входящих запросов.
На этом этапе, по сути, остановлен поток сообщений для данного приложения, а это значит, что клиенты больше не смогу отправлять сообщения службам не получая ошибок (они не будут устанавливаться в очередь, как это происходит в BizTalk Server в иных случаях). Внутренний механизм этого довольно прост: расширение "Dublin" просто удаляет все обработчики протоколов для этого конкретного приложения и сохраняет их, чтобы их можно было без труда восстановить после завершения обновления.
После того, как приложение переведено в автономный режим, можно выполнить требуемые обновления. Когда обновления закончены и все готово для возвращения приложения в интерактивный режим, можно выбрать команду восстановления протокола. Для выполнения тех же задач из командной строки можно использовать и такие командлеты Windows PowerShell, как Disable-ApplicationMessageFlow и Enable-ApplicationMessageFlow.
Наблюдение за работающими приложениями
Бизнесу также необходима способность наблюдать за работающим приложениями, чтобы видеть, как идет работа и какие изменения могут быть необходимы. Среды выполнения WCF и WF уже снабжены встроенной инфраструктурой отслеживания, дополняемой расширениями "Dublin", что делает несложным включение наблюдения внутри приложений WCF и WF.
Рис. 12. Настройка базового отслеживания
В инфраструктуре отслеживания .NET Framework 4.0 имеются два основных игрока: профили отслеживания и участники отслеживания. Разработчики определяют профили отслеживания, говорящие среде выполнения, какие события отслеживать и затем участники среды выполнения могут подписываться на эти события.
"Dublin" поставляется со встроенными профилями отслеживания, которые делают несложным отслеживание общего набора полезных событий. Отслеживание для приложения легко включить, перейдя к определенной службе в IIS Manager и выбрав Tracking («Отслеживание») в право панели.
После этого можно будет увидеть диалог, показанный на рис. 12, который позволяет настраивать некоторые базовые возможности отслеживания для рабочих процессов и служб. После его настройки, в конфигурацию будут внесены соответствующие обновления и в дело включится инфраструктура отслеживания WCF/WF.
При желании, можно также просматривать данные отслеживания через расширения "Dublin". Просмотр данных отслеживания можно выбрать при проверке сохраненных экземпляров служб (см. рис. 11), что произведет запрос SQL по хранилищу мониторинга, чтобы создать список событий отслеживания для просмотра пользователем (см. рис. 13). Когда необходимо отслеживать пользовательские события, можно определить собственные профили отслеживания и настроить их через параметр профилей отслеживания в основном представлении IIS Manager.
Рис. 13. Просмотр данных отслеживания
Объема статьи недостаточно, чтобы осветить все функции "Dublin" – существует несколько других заманчивых функций, заслуживающих дальнейшего обсуждения (подробнее см. в боковой панели «Дополнительные функции Dublin») – но я надеюсь, что читатели смогут яснее понять роль "Dublin" и некоторых из ключевых функций, предоставляемых им.
От "Dublin" к "Oslo"?
Те, кто слышал о платформе под кодовым называнием "Oslo", вероятно задают сейчас себе вопрос, как "Dublin" относится к этой инициативе. Во первых, "Oslo" – это новая платформа моделирования, разработанная Майкрософт для упрощения способов разработки, сборки и управления распределенных приложений. Эта платформа состоит из трех основных компонентов: языка моделирования "Oslo" (также известного как"M"), хранилища "Oslo" и средства моделирования "Oslo" (также известного как "Quadrant"). "Oslo" на деле является платформой, на основе которой могут надстраиваться другие приложения и технологии, для упрощения взаимодействия с пользователями через управляемый моделями подход.
Дополнительные функции “Dublin”
"Dublin" снабжен несколькими другими функциями, на подробное рассмотрение которых в этой с статье не хватило места. Но одну из них стоит выделить – это поддержка для развертываний расширения между фермами серверов, которые интегрируются с существующими решениями балансировки нагрузки, такими как решения для управления сохраненными экземплярами служб в ферме через централизованную базу данных сохранения. Встроенная логика обработки ошибок позволяет сохраненным экземплярам исполняться на любом узле в ферме, предотвращая условие конкуренции, когда несколько узлов конкурируют за один и тот же экземпляр.
Другим важным компонентом является служба перенаправления. Эта служба делает возможным перехват всех входящих сообщений, с целью выполнения централизованной маршрутизации, основанной на содержании сообщений. В частности, это решение предоставляет удобное основание для создания замысловатых решений управления версиями служб.
"Dublin" также снабжен несколькими ключевыми службами для управления жизненным циклом экземпляров служб, включая сервер устойчивого таймера и службу перезапуска экземпляра. "Dublin" также может пользоваться конечными точками управления экземплярами, предоставляемыми .NET Framework 4.0 и новой функцией авто-запуска IIS/WAS, которая позволяет запускать службы при запуске компьютера, не ожидая первого сообщения. Дополнительные статьи об этих функциях буду появляться в течении следующих нескольких месяцев.
"Dublin" будет одной из первых технологий, использующих платформу моделирования "Oslo". Приложения "Oslo" будет легко экспортировать из хранилища и разворачивать их в "Dublin", где они смогут пользоваться преимуществами различных функций размещения и управления, о которых говорится в данной статье. Использование моделей для описания и автоматизации развертывания приложений производит впечатление выигрышного решения для сложных ИТ-сред.
По мере того, как и "Dublin" и "Oslo" идут к зрелости, интеграция между ними, скорее всего, продолжит расти. Корпорация Майкрософт заявила о своем намерении сделать их весьма взаимодополняющими.
Как насчет BizTalk Server?
Другой частый вопрос состоит в том, как "Dublin" относится к BizTalk Server. Во многом, BizTalk Server был источников вдохновения для многих из нынешних функций "Dublin". Хотя обе технологии предоставляют похожие возможности управления, между ними имеется большое различие в плане направленности. "Dublin" добавляет к Windows Server расширения размещения и управления, разработанные специально для приложений WCF и WF, тогда как BizTalk Server нацелен на интеграцию приложений с системами не от Майкрософт, при помощи различных форматов сообщений, видов транспорта и методик сопоставления.
Основной целью BizTalk Server всегда была и будет интеграция с системами не от Майкрософт (бизнес-приложения, устаревшие системы, устройства RFID и протоколы бизнес-бизнес). BizTalk Server останется сфокусированным на этих основных сильных сторонах в предстоящие годы. В целом, BizTalk Server имеет смысл продолжать использовать когда основное внимание приходится уделять этим типам сценариев интеграции приложений предприятия (EAI).
Однако, поскольку многим приложениям WCF и WF не нужны возможности интеграции такого рода, BizTalk Server часто может показаться избыточным. Именно здесь и лежит ниша "Dublin" – более простая альтернатива, предоставляющая похожие возможности управления. В конечном счете, "Dublin" будет более экономичен в подобных сценариях, чем BizTalk Server, поскольку расширения "Dublin" будут поставляться как ключевая часть Windows Server. Весьма вероятно, что будущая версия BizTalk Server будет создавать надстройки на основе расширений "Dublin", чтобы воспользоваться вложениями в ядро управления, вносимыми в Windows Server.
Автор хочет выразить особую благодарность Эйлин Рамвелл (Eileen Rumwell), Марку Берману (Mark Berman), Дино Чиезе (Dino Chiesa), Марку Фьюсселу (Mark Fussell), Форду Маккинстри (Ford McKinstry), Маржану Калантару (Marjan Kalantar), Клиффу Симпкинсу (Cliff Simpkins), Кенту Брауну (Kent Brown), Крису Хорроксу (Kris Horrocks) и Кенни Вольфу (Kenny Wolf) за их помощь и поддержку в написании этой статьи.
Аарон Сконнард (Aaron Skonnard) – один из основателей компании Pluralsight, основного поставщика образовательных услуг по Microsoft .NET, предлагающего как курсы обучения под руководством инструктора, так и сетевые курсы. Аарон – автор многочисленных книг, технических статей и документов, а также обучающих курсов Pluralsight по REST, Windows Communication Foundation и BizTalk Server. С ним можно связаться по адресу pluralsight.com/aaron.