Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

 Разметка. Выбирайте этот вариант, если предполагается более частое изменение

рабочего процесса в будущем; если ассоциированные с рабочим процессом

бизнес-правила можно без труда выразить средствами языков разметки; если нет

необходимости создавать новые типы рабочих процессов; если необходимо

обеспечить гибкость для обновления модели рабочего процесса без повторной

сборки используемого моделью программного кода, реализующего рабочий

процесс.

Шаг 3 – Определение стратегии обработки правил

На данный момент уже сделан выбор относительно стиля рабочего процесса и способа

разработки рабочих процессов. Следующий шаг – принятие решение о том, как рабочий

процесс будет обрабатывать бизнес-правила. Доступные варианты определяются сложностью,

стабильностью бизнес-правил и требованиями к управлению, с ними связанными. При выборе

стратегии обработки бизнес-правил в компонентах рабочего процесса следует учитывать

следующие факторы:

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

или разделение кода. Правила могут реализовываться и инкапсулироваться в

компонентах бизнес-слоя с возможностью координирования их выполнения

рабочим процессом.

 Если правила подвержены изменениям, т.е. простые или управляемые данными,

для них следует применять разметку. Однако если правила управляются внешней

системой, такой как обработчик бизнес-правил, применяйте только код или

разработку с разделением кода.

 Если правила будут контролироваться бизнес-пользователями,

администраторами или аналитиками, выбирайте решение с использованием

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

редактирования правил, или решение, поддерживающее предметно-

ориентированный язык программирования (Domain Specific Language, DSL). Однако

если правила управляются внешней системой, такой как подсистема управления

бизнес-правилами, применяйте разработку с разделением кода.

Шаг 4 – Выбор решения для рабочего процесса

Выбрав стиль рабочего процесса, способ разработки и требования по обработке правил,

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

возможностей, обеспечиваемых каждым решением. На платформе Microsoft доступны

следующие технологии:

 Windows Workflow Foundation (WF). WF обеспечивает ориентированное на

разработчика решение для создания последовательного рабочего процесса,

конечного автомата или управляемого данными рабочего процесса. WF

поддерживает разработку с помощью только кода, с разделением кода и с

использованием языков разметки. Поддержка дизайнера доступна в Visual Studio

2005 через расширения и непосредственно в Visual Studio 2008 и последующих

версиях. WF включает дополнительные средства для безопасного, надежного,

транзакционного обмена данными, отслеживания действий, широкий выбор

средств передачи и кодирования передаваемых данных, а также обеспечивает

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

выключениями и повторными запусками системы.

 Workflow Services. Workflow Services (Сервисы рабочего процесса) обеспечивают

интеграцию Windows Communication Foundation (WCF) и Windows Workflow

Foundation (WF) для обеспечения рабочих процессов WCF-возможностями. Начиная

с Microsoft .NET Framework 3.5, WCF расширена для обеспечения поддержки

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

из рабочих процессов. Кроме того, Microsoft Visual Studio 2008 включает новые

шаблоны и инструментальные средства, поддерживающие сервисы рабочего

процесса.

 Microsoft Office SharePoint Services (MOSS). MOSS

– платформа для управления

информацией и координации совместной деятельности, обеспечивающая

поддержку рабочих процессов на основе технологий WF. MOSS обеспечивает

решение для рабочего процесса, управляемого оператором, и совместной

деятельности в контексте сервера Microsoft Office SharePoint® Server. Используя

Веб-интерфейс, можно определять рабочие процессы для визирования

документов, связанных с элементами списка SharePoint; использование дизайнера

SharePoint или Windows Workflow Designer (Дизайнер Windows рабочих процессов)

в Visual Studio позволяет определять условные и управляемые данными рабочие

процессы. Для настройки рабочих процессов может использоваться объектная

модель WF в Visual Studio. Однако MOSS подходит, только если бизнес-слой

взаимодействует лишь с одним сайтом SharePoint и не требует доступа к данным

других сайтов.

 BizTalk Server. Сервер BizTalk поддерживает последовательные рабочие процессы,

конечные автоматы и управляемые данными рабочие процессы, а также

разработку с разделением кода и применением языков разметки. Он обеспечивает

возможность обмена электронными документами между компаниями с

использованием форматов Electronic Data Interchange (EDI)

и/или XML и включает

мощные возможности оркестровки для проектирования и выполнения длительных,

тесно связанных бизнес-процессов и рабочих процессов с возможностями

надежного хранения и пересылки сообщений. BizTalk интегрируется с

гетерогенными приложениями и системами через адаптеры и обеспечивает

обработчик бизнес-правил и мониторинг деловой активности (Business Activity

Monitoring). Если требуется взаимодействовать с системами не-Microsoft,

Сервисы Microsoft Office SharePoint (прим. переводчика).

Электронный обмен данными (прим. переводчика).

выполнять EDI-операции или реализовывать шаблоны Enterprise Service Bus (ESB),

используйте комплект инструментов ESB Toolkit для BizTalk Server.

Шаг 5 – Проектирование компонентов бизнес-слоя для

поддержки рабочего процесса

Общей рекомендацией является создание рабочих процессов, состоящих из многошаговых

или длительных процессов, реализованных в отдельных компонентах, и обеспечить обработку

всех сбоев рабочих процессов через предоставление соответствующих исключений. При

проектировании бизнес-процессов необходимо учесть вызовы методов, не требующие ответа

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

этапов последовательно и синхронно, используйте конвейерный шаблон. Если этапы могут

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

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

применением технологий, предлагаемых платформой Microsoft.

Windows Workflow Foundation

Для Windows Workflow Foundation (WF) можно разрабатывать следующие бизнес-компоненты:

собственные рабочие процессы, действия и объекты состояний, а также собственные сервисы.

То, какие компоненты понадобятся, зависит от стиля рабочего процесса и способа разработки.

Далее описывается процесс создания трех основных типов рабочих процессов, собственных

сервисов и разметки рабочего процесса с использованием WF:

 При проектировании последовательных рабочих процессов описываются или

используются существующие классы Activity (Действие) (только код или разделение

кода), определяются классы рабочего процесса (только код) и определяются

компоненты бизнес-процесса, взаимодействующие с компонентами рабочего

процесса (только код).

 При проектировании конечных автоматов описываются классы состояний,

используемые для представления разных состояний процесса (только код или

разделение кода), описываются или используются существующие события,

запускающие изменения состояний (только код или разделение кода), описываются

или используются существующие классы Activity, управляющие переходами

состояний (только код или разделение кода), описываются классы рабочего

процесса (только код) и определяются компоненты бизнес-процесса,

взаимодействующие с компонентами рабочего процесса (только код).

 При проектировании управляемых данными рабочих процессов описываются или

используются существующие классы Activity (только код или разделение кода),

описываются или используются существующие классы Condition (Условие) для

взаимодействия с поставщиками данных (только код или разделение кода),

описываются специальные классы рабочего процесса (только код) и определяются

компоненты бизнес-процесса, взаимодействующие с компонентами рабочего

процесса (только код).

 При проектировании собственных сервисов описываются или используются

существующие классы Activity для взаимодействия с сервисом, определяется

интерфейс сервиса, поддерживающий необходимые операции, на базе

проверенных практик проектируется сервис и выбирается соответствующий хост

для сервиса (IIS, Workflow Appliance Software (WAS)

или WorkflowServiceHost (Хост

сервиса рабочего процесса)).

 При проектировании разметки рабочего процесса может использоваться дизайнер

Visual Studio (доступный как расширение Visual Studio 2005 и входящий в состав

Visual Studio 2008 и последующих версий) или дизайнер SharePoint Designer для

построения рабочих процессов на базе списков SharePoint. В качестве альтернативы

разметка, связанная с продуктом стороннего производителя, может создаваться в

дизайнере стороннего производителя, или можно вручную написать код разметки,

используя соответствующий синтаксис XAML.

Сервер BizTalk

BizTalk может поддерживать разработку и с разделением кода, и с применением языков

разметки. При использовании BizTalk может понадобиться спроектировать компоненты

рабочего процесса, используемые в оркестровке BizTalk. Примерами таких компонентов

рабочего процесса являются адаптеры и коннекторы. Также может понадобиться создать

сервисы, обеспечивающие операции, необходимые рабочему процессу, или спроектировать

бизнес-компоненты, обрабатывающие запросы для рабочих процессов BizTalk.

BizTalk может использоваться и без написания специальных компонентов, т.е. позволяет

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

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

преобразования сообщений и описания функций. Далее описывается процесс создания

рабочих процессов с использованием BizTalk:

 При проектировании компонентов рабочего процесса для BizTalk определяется

класс, реализующий соответствующий интерфейс, и затем этот класс регистрируется

в COM.

 При проектировании компонентов бизнес-слоя для BizTalk определяются классы,

поддерживающие необходимые операции. В случае необходимости, в компонентах

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

Бизнес-слой должен проектироваться с использованием проверенных практик для

обеспечения поддержки необходимых операций.

 При проектировании специальных сервисов описываются или используются

существующие классы BizTalk для взаимодействия с сервисом, определяется

интерфейс сервиса, поддерживающий необходимые операции; при

проектировании сервиса используются проверенные практики и выбирается

соответствующий хост для его размещения (IIS или WAS).

ПО, содержащее рабочий процесс (прим. переводчика).

На рис. 1 представлена совместная работа всех этих компонентов для обеспечения поддержки

рабочего процесса BizTalk.

Рис. 13

Совместная работа компонентов для поддержки рабочего процесса BizTalk.

BizTalk с ESB

Комплект инструментов Microsoft Enterprise Service Bus (ESB) Toolkit расширяет BizTalk

возможностями для создания подключенных сервисно-ориентированных корпоративных

приложений. Комплект инструментов ESB Toolkit включает компоненты, поддерживающие и

реализующие среду обмена сообщениями, упрощая тем самым построение основанных на

сообщениях корпоративных приложений. Комплект инструментов предоставляет следующие

компоненты:

 Веб-сервисы ESB. Обеспечивают основные возможности Microsoft ESB Toolkit.

Предоставляются следующие сервисы:

◦ Маршрутизирующие Веб-сервисы (Itinerary on-ramp Web services),

принимающие внешние сообщения и отсылающие их для дальнейшей

обработки обработки.

◦ Веб-сервис преобразования адресов (Resolver Web service), позволяющий

внешним приложениям вызывать инфраструктуру преобразования адресов

(Resolver Framework) для поиска конечных точек ESB на основании

механизмов разрешения, поддерживаемых инфраструктурой

преобразования адресов, таких как политики бизнес-правил, регистрации

UDDI, статический вызов, интерфейс WS-MetadataExchange (Обмен

метаданными) и на основании содержимого сообщения.

◦ Веб-сервис преобразования (Transformation Web service) обеспечивает

функции для преобразования содержимого сообщения и выполнения

бизнес-требований. Преобразованиям может подвергаться

непосредственно входящее сообщение или сообщения, извлекаемые из

базы данных MessageBox (Хранилище сообщений) BizTalk.

◦ Веб-сервис обработки исключений (Exception Handling Web service)

принимает сообщения об исключениях из внешних источников и публикует

их в Инфраструктуре управления исключениями ESB (ESB Exception

Management Framework). Оттуда конвейер обработки сбоев будет

нормализовать, отслеживать и публиковать сообщение об исключении в

Портале управления ESB (ESB Management Portal).

◦ Веб-сервис UDDI позволяет приложениям и пользователям выполнять поиск

конечных точек по имени сервиса, поставщику услуг или категории деловой

активности; также с его помощью приложения и пользователи могут

управлять поставщиками услуг, сервисами и категориями, хранящимися в

хранилище UDDI.

◦ Веб-сервис обслуживания BizTalk предоставляет сведения о хостах BizTalk,

оркестровке, приложениях и состоянии.

 Портал управления ESB. Обеспечивает такие возможности как отслеживание

исключений и сбоев, повторная передача сообщений, предупреждения и

уведомления, интеграция с UDDI, составление отчетов и аналитика, возможности

настройки.

 Компоненты конвейера взаимодействий ESB. К ним относятся Сервис обмена

сообщениями Java (Java Messaging Service, JMS) и компоненты пространств имен

для использования в конвейерах BizTalk.

 Инфраструктура управления исключениями. Может перехватывать исключения от

подсистем обмена сообщениями и оркестровки BizTalk и формировать сообщения о

сбоях.

 Инфраструктура поставщика преобразования адресов и адаптера ESB. Реализует

подключаемую и настраиваемую архитектуру для динамически разрешаемых

конечных точек и трансформаций, а также для маршрутизации сообщений.

 Обработка маршрутов. Этот механизм обеспечивает возможность упрощенного

динамического описания, передачи и выполнения множества вызовов сервисов

или маршрутизации/преобразования запросов.

 Примеры приложений ESB. Демонстрируют применение комплекта инструментов

Microsoft ESB Toolkit, показывая пути использования предоставляемых им

возможностей в собственных приложениях SOA и ESB.

Совместное использование Windows Workflow Foundation и BizTalk

Во многих ситуациях Windows Workflow Foundation (WF) или BizTalk по отдельности не могут

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

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

процессов. Сочетайте WF и BizTalk:

 если хотите реализовать с помощью только кода рабочий процесс бизнес-правил с

использованием компонентов WF, взаимодействующий с подсистемой управления

бизнес-правилами BizTalk;

 если имеются существующие рабочие процессы WF, которые должны вызываться

из системы оркестровки BizTalk;

 при создании рабочего процесса SharePoint, который должен выполнять

оркестровку BizTalk;

 если рабочий процесс WF должен интегрироваться с гетерогенными или

устаревшими системами.

Дополнительные источники

Электронная версия списка используемых источников по технологиям проектирования

рабочих процессов доступна по адресу http://www.microsoft.com/architectureguide.

 «Introduction to Programming Windows Workflow Foundation» (Введение в

программирование Windows Workflow Foundation) по адресу

http://msdn.microsoft.com/en-us/library/ms734696.aspx

 «Microsoft BizTalk ESB Toolkit» (Комплект инструментов Microsoft BizTalk ESB) по

адресу http://msdn.microsoft.com/en-us/library/dd897973.aspx

Проектирование компонентов

слоя доступа к данным

Обзор

Компонентами слоя доступа к данным являются компоненты, обеспечивающие

функциональность доступа к данным, размещаемым в системе, и компоненты агентов

сервисов, обеспечивающие функциональность доступа к данным, которые предоставляются

другими серверными системами через Веб-сервисы. Кроме того, слой доступа к данным также

может включать компоненты, обеспечивающие вспомогательные функции и утилиты.

Эта глава описывает основные этапы проектирования компонентов данных. Первый шаг –

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

поможет выбрать соответствующую технологию доступа к данным. Следующий шаг – выбор

стратегии сопоставления и затем определение подхода к реализации доступа к данным, куда

входит определение используемых бизнес-сущностей и их формата. После этого можно

принять решение о том, как будет выполняться подключение компонентов доступа к данным и

источнику данных. Наконец, вырабатывается стратегия обработки ошибок для управления

исключениями источника данных.

Шаг 1 – Выбор технологии доступа к данным

При выборе технологии доступа к данным необходимо учесть тип данных, с которыми

предполагается работать, и то, как эти данные будут обрабатываться в приложении. Для

каждого конкретного сценария есть наиболее подходящие технологии. Чтобы правильно

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

приложения, руководствуйтесь следующими рекомендациями:

 ADO.NET Entity Framework

. Используйте ADO.NET Entity Framework (EF), если хотите

создать модель данных и соотнести ее с реляционной базой данных; соотнести

один класс с множеством таблиц, используя наследование; или выполнять запросы

к реляционным хранилищам, не входящим в семейство продуктов Microsoft SQL

Server. EF подойдет, если имеется объектная модель, которую необходимо

Инфраструктура сущностей ADO.NET (прим. переводчика).

соотнести с реляционной моделью, используя гибкую схему, и необходима

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

объектной модели. При использовании EF также рассмотрите возможность

применения:

◦ LINQ to Entities. Используйте LINQ to Entities, если необходимо выполнять

запросы через строго типизированные сущности или запрашивать реляционные

данные, используя синтаксис LINQ.

 ADO.NET Data Services Framework

. ADO.NET Data Services построена на базе EF и

позволяет предоставлять части модели сущностей (Entity Model) через REST-

интерфейс. Используйте ADO.NET Data Services Framework, если разрабатываете RIA

или n-уровневое насыщенное клиентское приложение и хотите выполнять доступ к

данным через ресурсно-ориентированный интерфейс сервиса.

 ADO.NET Core

. Используйте ADO.NET Core, если для обеспечения полного

управления доступом к данным в приложении необходим низкоуровневый API;

если хотите использовать уже сделанные инвестиции в ADO.NET-решения; если

используете традиционную логику доступа к данным. ADO.NET Core подойдет, если

нет необходимости в дополнительной функциональности, предлагаемой другими

технологиями доступа к данным, или если разрабатываемое приложение должно

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

 ADO.NET Sync Services

. Используйте ADO.NET Sync Services при проектировании

приложения, которое должно поддерживать сценарии без постоянного

подключения или требует синхронизации баз данных.

 LINQ to XML. Используйте LINQ to XML, если приложение работает с XML-данными,

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

Более подробно технологии доступа к данным, предлагаемые платформой Microsoft,

рассматриваются в приложении C, «Матрица технологий слоя доступа к данным».

Шаг 2 – Принятие решения о методе извлечения и хранения

бизнес-объектов источника данных

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

заполнения бизнес-объектов или бизнес-сущностей данными из хранилища данных и

сохранения данных бизнес-объектов или бизнес-сущностей в хранилище данных. Обычно

интерфейсы объектно-ориентированной модели данных и реляционного хранилища данных

не согласованы, что порой усложняет передачу данных между ними. Существует ряд подходов

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

структурой, технологиями обеспечения транзакций и способами обработки данных. Самые

Инфраструктура сервисов данных ADO.NET (прим. переводчика).

Базовый ADO.NET (прим. переводчика).

Сервисы синхронизации ADO.NET (прим. переводчика).

распространенные подходы используют инструменты и инфраструктуры объектно-

реляционного сопоставления (Object/Relational Mapping, O/RM). Используемый в приложении

тип сущности является основным фактором при принятии решения о способе сопоставления

сущностей со структурами источника данных. Следующие рекомендации помогут выбрать

технику извлечения и сохранения бизнес-объектов в хранилище данных:

 Используйте инфраструктуру O/RM, обеспечивающую преобразования между

сущностями предметной области и базы данных. При работе в среде «greenfield»,

когда вы имеете полный контроль над схемой базы данных, инструмент O/RM

может обеспечить формирование схемы для поддержки объектной модели и

сопоставления сущностей базы данных и предметной области. При работе в среде

«brownfield», где вам приходится использовать предлагаемую схему базы данных,

инструмент O/RM поможет сопоставить модель предметной области и

реляционную модель.

 В объектно-ориентированном проектировании обычно используется модель

предметной области, шаблон, основанный на моделировании сущностей

соответственно объектам предметной области. Методики проектирования на

основе предметной области подробно рассматриваются в главе 13,

«Проектирование бизнес-сущностей».

 Правильно сгруппируйте сущности, чтобы достичь высокого уровня связности. Для

этого может понадобиться ввести в модель предметной области дополнительные

объекты и сгруппировать взаимосвязанные сущности в сводные корни.

 При работе с Веб-приложениями или сервисами группируйте сущности и

обеспечивайте опции для частичной загрузки сущностей предметной области

только необходимыми данными. Это сократит использование ресурсов за счет того,

что не придется удерживать в памяти инициализированные модели предметной

области для каждого пользователя, и позволит приложениям справляться с более

высокой нагрузкой пользователей.

Шаг 3 – Выбор способа подключения к источнику данных

Зная, как компоненты доступа к данным сопоставляются с источником данных, можно принять

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

защита пользовательских учетных данных и выполняться транзакции. Рекомендации в

следующих разделах помогут правильно выбрать подход:

 Подключения

 Пул подключений

 Транзакции и параллелизм