Service Oriented Architecture

     Service Oriented Architecture (SOA) - технология разработки распределенных систем, функциональность которых обеспечивается с помощью сервисов (служб). Службы взаимодействуют между собой посредством сообщений и реализуют бизнес-функции и правила, описанные их контрактом (интерфейсом). W3C определяет SOA как 
 
Набор компонент, которые могут быть вызваны, и чье описание может быть опубликовано и найдено 
 
Службы предоставляют доступ к данным, бизнес-процессам и другим информационным системам. Вызов служб может быть как синхронным, так и асинхронным. SOA-системы обычно разрабатываются на основе web-служб и, поэтому, могут быть использованы в гетерогенных системам, состоящих из большого числа приложений, работающих на различных платформах и созданных с помощью разных языков программирования. Однако для реализации SOA web-службы не обязательны, как и любая система, построенная на основе web-служб, не обязательно соответствует SOA. SOA система может быть построена и на применении COM/DCOM, EJB, CORBA. Преимуществом web-служб является то, что они основаны на открытых стандартах технологий (XML, SOAP, UDDI, WS-*), которые реализованы на многих платформах.

     Кроме технологического аспекта SOA содержит стратегии, методы и платформы приложений, с помощью которых создаются, работают и вызываются службы. Примером такой платформы приложений может служить .NET Framework компании Microsoft. Web-службы в .NET Framework являются частью платформы для разработки web-приложений ASP.NET.

     Основными выгодами от использования SOA являются:

• уменьшение стоимости и времени разработки
• улучшение связь между бизнесом и информационными системами из-за схожести структур бизнес-подразделений предприятия и взаимодействий между ними и архитектуры SOA системы, построенной для этого предприятия
• уменьшение стоимости интеграции приложений
• снижение рисков разработки
• гибкость и низкая связанность компонент системы
• повторное использование служб в различных системах
• разработка приложений, объединяющих всю инфраструктуру предприятия

     Все компоненты SOA-приложений могут быть условно разделены на 3 группы: службы, клиенты служб и брокеры служб, предоставляющие услуги по публикации информации о службах и по поиску служб.

     Сами  службы состоят из интерфейса и реализации этого интерфейса. Интерфейс предоставляет метаданные о службе, данные для идентификации службы и описание входных/выходных параметров методов службы. Реализация интерфейса для клиента службы представляет собой "черный ящик".

     Клиентом  службы может быть настольное приложение, работающее на компьютере пользователя, серверное приложение, другое web-приложение или служба.

     Брокером  в случае использования web-служб  может быть UDDI-сервер, содержащий регистр служб, или собственное решение, использующее расширения WSE.

     В случае использования web-служб доступ к службам происходит через сеть по стандартным протоколам. Сами службы описываются на стандартном языке (контракт службы) и публикуют эту информацию при помощи брокера. Службы разделяют свой интерфейс и его реализацию. Для вызова службы клиентскому приложению нужно только описание интерфейса службы - информация же о реализации службы не нужна клиентам. Реализация службы может меняться, не затрагивая клиентов и без необходимости предоставлять клиентам новую версию описания службы - в этом и проявляется низкая связанность частей системы (loose coupling). Другим преимуществом разделения интерфейса и реализации является возможность выбора клиентом службы из нескольких служб с одинаковым интерфейсом путем простого указания адреса нужной службы. В этом скрыта возможность для расширения и масштабирования системы после ее создания. В систему можно добавлять новые службы или новых клиентов служб, не нарушая уже существующую функциональность. Причем для добавления новой функциональности к системе не нужно иметь доступ к ее исходному коду.

     Службы  можно условно поделить на пять типов:

• службы доступа к данным, предоставляющие чтение и изменение данных. Они скрывают реализацию доступа к реальным источникам данных и предоставляют единый унифицированный интерфейс для доступа к данным вне зависимости от колыичества и вида используемых источников данных. Для обмена данными могут использоваться специально созданные сущностные объекты, XML данные или же объекты, инкапсулирующие таблицы БД (например, объекты DataSet платформы .NET). Этот вид служб SOA самый легкий в реализации и чаще всего используется в приложениях
• бизнес службы содержат функциональность, используемую для выполнения различных бизнес-операций (например, оформление заявки на слад или формирование отчета по уровню продаж). В ходе выполнения бизнес-операций обычно вызываются методы других служб (к примеру, служб доступа к данным для получения списка проданных товаров за последнюю неделю)
• компоненты внешних приложений, вызываемые через их собственные интерфейсы (например, COM или DCOM). Примером такого приложения может быть CRM система, хранящая данные о покупателях и предоставляющая доступ к этим данным через COM
• низкоуровневые вспомогательные службы отвечают за аутентификацию и авторизацию, мониторинг, поиск служб, регистрацию ошибок, вспомогательные функции, используемые в других службах. Часто их называют общие службы (common services) или службы инфраструктуры предприятия (interprise infrastructure services)
• составные службы, делегирующие работу остальным типам служб и координирующие их действия. Они интегрируют остальные службы системы и выполняют контроль за транзакциями и преобразование потока данных от одних служб к другим путем конвертации в нужные форматы.

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

     BPM (Business Process Management) - одна из современных управленческих методик включающая в себя совокупность идеологии и программного обеспечения управления бизнес-процессами.

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

     С точки зрения философии управления, BPM призывает отойти от функционального  осмысления деятельности организации  к её видению как совокупности бизнес-процессов пересекающих функциональные границы. Здесь, в отличие от реинжиниринга, ориентация происходит на непрерывный процесс усовершенствования бизнес-процессов компании. Кроме того, концепция BPM предполагает фокус на взаимодействии как между людьми, так и системами и аппаратными средствами.

     Однако  сам подход BPM прочно связан с BPMS - Business Process Management System/Solution, технологической составляющей BPM. (Следует заметить, что в настоящее время термины BPM и BPMS применяются равнозначно для общего названия подхода). С этой стороны BPM представляет собой интегрированный набор инструментов, позволяющий моделировать процессы, автоматически их исполнять и контролировать эффективность.

     Для реализации этих трех аспектов процессного  управления BPMS состоит из трех глобальных элементов:

1. средство моделирования
2. средство исполнения («движок»)
3. средство мониторинга

     Средство  моделирования: Для описания и моделирования бизнес-процессов BPM не использует такие общепринятые в реинжиниринге нотации как IDEF, и другие. Моделирование бизнес-процессов больше похоже на средства инструментов класса Workflow, достаточно упрощенное для возможности моделирования бизнес-процессов непрофессионалами. Однако разработчики BPMS так же пошли по пути стандартизации, и в настоящий момент существует нотация BPMN и стандарт BPEL.

     Средство  исполнения: Исполнение начинается со схемы бизнес-процесса, которая загружается в «движок», где происходит запуск процесса. Исполнение подразумевает автоматическое прохождение шагов процесса, а так же реализацию контроля. При этом каждый исполнитель, задействованный в функционировании бизнес-процесса, видит требуемое от него задание. Реализация исполнения бизнес-процессов так же связана со стандартом BPEL.

     Средство  мониторинга: Мониторинг подразумевает возможность оперативно, в реальном времени, отслеживать прохождение процесса по этапам и исполнителям, а также позволяет формировать отчетность и оценивать результативность и показатели процесса.

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

     В общем виде можно представить, что BPM впитала в себя наработки следующих  подходов и методик:

• Процессный подход
• Workflow и системы электронного документооборота
• Моделирование и реинжиниринг бизнес-процессов
• Система сбалансированных показателей и KPI
• Интеграция приложений (SOA)

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

     Нотация моделирования бизнес процессов (Business Process Modeling Notation, BPMN) — графическая нотация для моделирования бизнес процессов.

     Спецификация BPMN описывает графическую нотацию для отображения бизнес-процессов в виде диаграмм бизнес процессов (ДБП). BPMN ориентирована как на технических специалистов, так и на бизнес пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN определяет как диаграммы, описывающие бизнес процесс, могут быть трансформированы в исполняемые модели на языке BPEL.

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

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

     Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических  элементов. Это помогает пользователям  быстро понимать логику процесса. Выделяют четыре основные категории элементов:

• Объекты потока управления: события, действия и логические операторы
• Соединяющие объекты: поток управления, поток сообщений и ассоциации
• Роли: пулы и дорожки
• Артефакты: данные, группы и текстовые аннотации.

     Элементы  этих четырёх категорий позволяют  строить простейшие диаграммы бизнес процессов (ДБП). Для повышения выразительности  модели спецификация разрешает создавать  новые типы объектов потока управления и артефактов.