Модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений

Оглавление

Введение

. Концепция сервисно-ориентированной архитектуры

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

. Анализ практического применения SOA в ИТ компании

.1 Описание деятельности компании «ЗАО Крок Инкорпорейтед»

.2 Моделирование процесса, протекающего в смежных системах

.2.1 Описание инициации процесса и его шагов

.2.2 Описание фрагмента интеграционной схемы

.3 Анализ одной точки интеграции

Заключение

Источники

Приложения

Введение

В условиях современной рыночной конкуренции компании остро нуждаются в новом поколении информационных систем и сервисов, которые способны предоставить расширенный, по сравнению с предыдущими системами, функционал, а также обеспечивать доступ к различным сервисам по требованию. Кроме того, бизнес нуждается в гибкости и динамичности таких сервисов, которые смогут иметь доступ к общим хранилищам данных, обмениваться данными между собой и обеспечивать различные виды взаимодействия, например, межсистемный или «бизнес для бизнеса» (B2B). Такие системы и сервисы должны грамотно интегрироваться, поскольку именно это позволит им быстро перестраиваться под меняющиеся бизнес-потребности, реагировать на изменения бизнес-правил, предоставлять возможность без потерь заменять устаревшие информационные компоненты, внедрять новые программные продукты в общую ИТ-инфраструктуру или переходить на новые платформы. Совокупность сервисов и систем, эксплуатируемых в компании, составляет общую ИТ-архитектуру, грамотное построение которой представляет сложность для большинства компаний.

Вышеперечисленные бизнес-потребности послужили причиной растущей популярности нового подхода к организации и интеграции сервисов, называемого сервисно-ориентированной архитектурой, или SOA (также сервис-ориентированная архитектура). Для современных компаний SOA является достаточно привлекательной моделью ИТ-архитектуры, которая позволяет лучшим образом выровнять потребности бизнеса по отношению к имеющимся информационным ресурсам и использовать весь информационный потенциал компании по максимуму. Тема данной дипломной работы - «Анализ эффективности сервисно-ориентированной архитектуры в ИТ компании», и в данной работе будут рассмотрены основные особенности этого архитектурного подхода и приведены доказательства его эффективности.

SOA - это новый стиль архитектуры информационных систем, который позволяет разрабатывать и интегрировать бизнес-приложения. Эта архитектурная модель объединяет в себе техническую и организационную составляющие, которые позволяют компании иметь общую платформу для выполнения независимых бизнес-функций и сервисов, при этом по минимуму пресекаться в функциональности и избегать дублирования сервисов, приложений и данных. Поскольку сейчас большинство компаний инвестируют большие средства в крупномасштабные системы, такие как ERP (enterprise resource planning), CRM (customer relationship management), HRMS (human resource management systems), а подобные решения чаще всего «коробочные», у бизнеса возникает потребность выносить часть функционала в отдельные сервисы и интегрировать их на одной общей платформе. Следовательно, компании занимаются поиском оптимального соотношения сервисов и приложений и разделения между ними функциональности так, чтобы она не дублировалась, а также поиском наиболее эффективного инструмента интеграции для обеспечения взаимодействия между этими системами. Проблема современного бизнеса заключается в чрезмерном инвестировании во внутренние ИТ-проекты и во временных затратах на выполнение бизнес-функций, которые являются следствием выбора неэффективного системного решения.

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

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

Главной целью данной дипломной работы является доказательство целесообразности применения концепции SOA в компании. Критерием целесообразности будет выступать оценка общей эффективности применения SOA в целом и в отдельно взятом российском ИТ-интеграторе. В свою очередь, оценка эффективности будет сформирована на основе уже проведенных исследований в данной области и на основе некоторых количественных показателей, таких как время передачи датаграммы в смежные системы и время получения ответного сообщения. Также, целью является набор сформулированных рекомендаций для успешного внедрения SOA и комментариев, касательно того, когда это внедрение имеет смысл. Для достижения поставленной цели будут выполнены следующие задачи:

описание концепции работы SOA;

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

моделирование одного бизнес-процесса, требующего для своей реализации интеграции систем;

анализ интеграционного взаимодействия (точки интеграции) с замерами определенных показателей взаимодействия;

предложение набора рекомендаций для успешного перехода на SOA.

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

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

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

1. Концепция сервисно-ориентированной архитектуры

Сервисно-ориентированная архитектура, как результат эволюции ИТ-инфраструктуры, оформилась примерно в 1990-е годы. Переход к такой системной модели происходил постепенно. Еще в 1980-е годы организационные структуры компаний представляли собой вертикальные, изолированные подразделения, которые затем сменились горизонтальными, процессно-ориентированными структурами. Архитектура систем также трансформировалась вместе с бизнесом, и потребность в распределенных системах росла с ростом процессно-ориентированных организаций. Первыми были монолитные системы, в которых логика обработки данных и функциональная логика приходились на одну систему, размещенную на одной машине. Позднее логика была разделена на клиентскую и серверную части, из которых еще позже сервисы обработки данных были вынесены на отдельный сервер, образовав таким образом трехзвеньевую архитектуру. Такая архитектура затем эволюционировала в многозвеньевую, когда логически однородные функции, ранее хранившиеся на одном сервере, стали размещать на разных машинах для распределения нагрузки на сервера. Затем появились децентрализованные системы с распределенными объектами - компьютерные сети, основанные на равноправии участников. В таких сетях, как правило, отсутствуют выделенные серверы, а каждый узел является как клиентом, так и сервером [1-2]. Самой недавней архитектурой стала SOA - парадигма использования распределенных информационных ресурсов (приложений и данных), находящихся в сфере ответственности разных владельцев. Схема развития архитектурных решений представлена на Рисунке 1.1.

Рисунок 1.1. Эволюция архитектурных решений

Для сервисно-ориентированной архитектуры особое значение имеют слабая связь компонентов, независимость от географии расположения этих компонентов и независимость от протоколов (способов связи). Сервис в этой модели определяется как «исполнимая единица кода, которая предоставляет собой «черный ящик»: инкапсуляцию определенных функций. Он может быть вызван другими сервисами или системами с помощью стандартизированного потока сообщений»[3]. На Рисунке 1.2 представлена схема SOA с описанием основных понятий.

Рисунок 1.2. Основные понятия SOA

         Сервисы: логические сущности, которые определяются публикующим их интерфейсом;

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

         Потребитель сервиса: системная сущность, которая вызывает провайдера сервиса. Является синонимом понятия «клиент», может быть пользовательским приложением или другим сервисом;

         Локатор сервиса: особый вид сервиса, выступающий в качестве реестра остальных сервисов и позволяющий осуществлять поиск нужных сервисов;

         Брокер: особый вид провайдера сервиса, который может передавать запросы к сервису другим сервис-провайдерам.

Взаимодействие между потребителем и провайдером сервиса задается с помощью интерфейса, который определяется набором сигнатур методов [4].

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

Рисунок 1.3. Стек технологий веб-сервисов

Стек технологий веб-сервисов условно делится на 2 составляющие: технологии для обеспечения функциональности и технологии для обеспечения качества сервисов. Эти составляющие, в свою очередь, можно разделить на слои.

Транспортный слой: механизмы, используемые для обмена данными между веб-сервисами (HTTP, JMS);

Коммуникационный слой: формализация механизмов использования транспортных протоколов веб-сервисами (SOAP);

Слой описания сервисов: формализация интерфейсов веб-сервисов для обеспечения их независимости от аппаратно-программной платформы (XML, WSDL);

- Сервисный слой: доступные к использованию единицы функциональности, вызываемые с помощью WSDL;

- Бизнес-процесс: описание организации веб-сервисов для выполнения потока работ и процессов;

Слой реестров сервисов: хранилище сервисов и их организация в иерархические структуры.

Технологии качества сервиса, в свою очередь, характеризуется следующими составляющими:

Политики: описание правил, по которым веб-сервисы могут быть вызваны;

Слой безопасности: возможности обеспечения безопасного доступа к сервисам (разделение доступа, ролевые модели, авторизация, аутентификация);

Транзакционный слой: описание свойств транзакционности распределенных систем;

Управленческий слой: возможности управления веб-сервисами и их масштабируемостью[5-6].

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

2. Обзор публикаций. Определение глубины исследования проблемы

Феномен сервисно-ориентированной архитектуры относительно молод; хотя проблема интеграции информационных ресурсов появилась намного ранее. Как было отмечено во введении, в 90-е годы предприниматели и владельцы бизнеса стали интересоваться и активно использовать в бизнесе крупные комплектные решения, такие как ERP или CRM системы. При этом потребности и масштаб автоматизации бизнеса заметно возросли, и реализация всего функционала на стороне одной системы стала невозможна. В это время большинство ИТ-инфраструктур компаний двинулось в сторону композитных систем. веб интерфейс провайдер

Одним из исследователей, стоящих в истоках истории SOA, стоит выдающийся разработчик программного обеспечения Стив Бурбек. Профессиональная биография Бурбека включает в себя работу в исследовательском биомедицинском институте (1980-е), позицию менеджера по продукции в Apple Computer, пост вице-президента Knowledge Systems Corp. (1990-1994), работу ведущим IT-консультантом в IBM (1995-2005). В связи с ростом популярности глобальной сети Бурбек озвучил идею, что для эффективной организации услуг между бизнесами можно построить особую архитектуру, которую он назвал Service-Oriented Architecture (SOA).

Кроме самого термина Бурбек предложил модель, элементами которой являются поставщик услуг, получатель услуг и брокер-посредник (Рисунок 2.1):

поставщик регистрирует данные о предоставляемых услугах;

брокер классифицирует и осуществляет их поставку;

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

Рисунок 2.1. Модель, предложенная С. Бурбеком

Кроме модели, основные идеи сервисно-ориентированной архитектуры Бурбек опубликовал в своем труде, над которым он работал с 2004 по 2007 годы, «Сложность и эволюция компьютерных систем, биологические принципы для управления эволюционирующими системами» [7]. В своей работе он проводит аналогию архитектуры информационных приложений с работой многоклеточного организма. «Одноклеточные организмы эволюционировали в многоклеточные организмы давным-давно. Сегодня мы наблюдаем похожие изменения в компьютерах. 20 лет назад мало компьютеров взаимодействовали напрямую между собой. Сейчас сотни миллионов компьютеров обмениваются информацией на скорости Интернета. Цифровой мир неумолимо становится комплексным. Все большие группы компьютеров взаимодействуют все более сложными и менее очевидными способами. При этом они сталкиваются с проблемой, распространенной во всех сложных системах, - проблемой, на которую эволюция уже имеет ответ», - пишет во вступлении к своей работе Бурбек. Он говорит о том, что хранение и обработка информации в клетке гораздо более эффективна, чем в электронно-цифровых компьютерах и с точки зрения плотности информации, и с точки зрения потребления энергии. Однако, как клетки являются начальной единицей организма, так и компьютеры являются начальными единицами вычислительного процесса, поэтому многие механизмы взаимодействия и передачи информации можно позаимствовать у клеток и спроецировать их на компьютерные сети.

Главным образом в своей работе Бурбек пытается найти ответ на вопрос «Чем противостоять возрастающей сложности информационных систем, и какие использовать методы для эффективного взаимодействия системных компонентов?». Автор пытается дать определение понятия системной сложности: «Мы привыкли думать о сложности, как о путанице, которую мы не в состоянии постичь. Это объясняет только один вид сложности, называемый детальной, или структурной сложностью. Другой вид сложности, обычно называемый динамической сложностью, накапливается самими системами и не имеет ничего общего с нашим пониманием. Этот второй вид сложности возникает естественно в системах, которые эволюционируют со временем, и заключаются в их функционировании: метеорологические, космологические, биологические, экологические, геологические, социальные, экономические и компьютерные системы. Оба вида сложности сбивают с толку в компьютерных системах. Мы сталкиваемся со структурной сложностью в исходном коде программы или в схеме базы данных, которые определяют структурные взаимоотношения между действующими элементами. Эти структурные описания обычно становятся настолько сложными, что они превосходят наши когнитивные способности к пониманию. Динамическая сложность качественно отличается; она заключается в том, что происходит в момент выполнения приложения, т.е. показывает, как разворачивается сценарий компьютерной программы в момент взаимодействия ее элементов».

Утверждая, что вычислительные системы повторяют идею эволюции от одноклеточного к многоклеточных организмам, Бурбек предлагает воспользоваться 4 стратегиями для успешного управления многосервисными системами, которые также можно наблюдать в живых организмах. Аналогии представлены в Таблице 2.1.

Таблица 2.1. Аналогии многоклеточных организмов и компьютерных сетей

В современном сервисно-ориентированном подходе эти 4 стратегии нашли отражение. Идея специализации заключается в распределении функциональности между веб-сервисами таким образом, чтобы функционал не дублировался, а веб-сервисы вызывались из любой «точки» распределенной архитектура по мере необходимости и выполняли свое действие. Веб-сервисы в парадигме SOA должны обладать полиморфизмом, т.е. иметь свойство быть использованными в разных формах (в данном случае - при вызове разными смежными системами). Взаимодействие с помощью полиморфных сообщений в современной реализации SOA реализовано в передаче структурированных сообщений по протоколам (напр. HTTP, SOAP), в форме XML-датаграмм через промежуточное программное обеспечение - корпоративную сервисную шину. Важно отметить, что подобный обмен данными действительно диктуется принимающей стороной: система-приемник может не принимать определенные файлы, а также задавать формат входных датаграмм. Стратегия замены «отмирающих» элементов для общего благополучий системы и синергии также применяется и заключается в замене устаревших модулей и внедрении новых приложений на одной платформе.

В заключении к своему научному труду Бурбек приходит к выводу, что если бизнес готов к переходу на такую «многоклеточную» информационную архитектуру, то, ориентируясь на эти 4 стратегии можно построить самодостаточную, хорошо управляемую архитектуру.

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

В статье «Integration of Distributed Enterprise Applications: A Survey», опубликованной в журнале «IEEE Transactions on Industrial Informatics» авторы дают немного иное определение распределенной информационной системе и более конкретно исследуют интеграцию приложений в распределенной системе. В этой статье авторы отмечают причины стремительного перехода компаний на SOA: «За последние 3 десятилетия многие компании вложили большие средства, чтобы интегрировать распределенные корпоративные приложения из-за постоянных слияний и поглощений, совместных проектов, аутсорсинга, реструктуризации компаний, изменений в инфраструктуре, использовании мобильных устройств, умных встроенных приложений и беспроводных сенсоров. Компании, способные интегрировать свои множественные приложения, имеют существенное конкурентное преимущество, такое как стратегическое использование данных и технологий компании для большей эффективности и выгоды» [8]. Кроме растущих потребностей бизнеса, расширяющихся связей между бизнес-партнерами и, как следствие, распределенных программных сервисов, авторы также выделяют технологические предпосылки растущей популярности SOA: увеличивающаяся производительность персональных компьютеров, позволившая перенести часть логики на локальные машины, растущие объемы данных и потребность в организации данных в структуры, доступные приложениям.

Если в своей работе Бурбек больше проецировал «многоклеточность» живых организмов на отдельные компьютеры, которые составляют вычислительную сеть, то авторы данной статьи рассматривают к качестве звеньев сети веб-сервисы. Такой исследовательский подход более близок к современно модели SOA. В современной парадигме SOA именно веб-сервисы являются ключевыми элементами и исполнителями функций. Авторы так описывают работы веб-сервисов: «В связи с широким распространением веб-приложений, архитектура развернулась в веб-центричную архитектуру за счет добавления веб-клиентов и веб-серверов. В веб-центричной архитектуре веб-клиент отправляет HTTP-запросы к веб-серверу с целью получить контент. Веб-сервер либо возвращает контент напрямую, либо передает его на определенный сервер приложения. Сервер приложения взаимодействует с серверной базой данных и отправляет ответ обратно клиенту».

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

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

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

)        Интеграция бизнес-логики: чтобы сделать интеграцию проще на бизнес-уровне, системные аналитики концентрируются на промежуточном программном обеспечении (англ. middleware). Благодаря абстракции, которую дает промежуточное программное обеспечение, становится возможным изолировать приложения от постоянно меняющихся аппаратных платформ, операционных систем, сетей и протоколов, которые составляют корпоративную информационную сеть. Как очень важная информационная технология, промежуточное программное обеспечение часто используется компаниями для интеграции новых приложений и устаревших приложений. Это позволяет сохранить целостность бизнеса и не проводить реинжениринг бизнес-процессов только для того, чтобы архитектура была в состоянии его реализовывать.

Последний уровень интеграции - интеграция бизнес-логики - наиболее важен в крупных и многофункциональных компаниях, в которых бизнес-процессы тесно переплетаются. Именно поэтому роль промежуточного программного обеспечения в сервисно-ориентированном подходе является особым предметом изучения и совершенствования в ИТ-среде. Различные виды такого ПО подвергаются анализу и критике со стороны исследователей, которые стремятся обеспечить наилучший интеграционный подход в компании. Например, в статье «Service-oriented middleware: A survey», написанной для Journal of Network and Computer Applications и посвященной рассмотрению промежуточного программного обеспечения, авторы определяют промежуточное программное обеспечение (middlewarе) как «совокупность программных продуктов, которые могут быть использованы, чтобы облегчить разработку, эксплуатацию и управление сервисно-ориентированными приложениями. Сервисно-ориентированное промежуточное программное обеспечение основывается на многоуровневой архитектуре, где оно располагается между поставщиком услуг, разработчиком услуг и потребителем услуг» [9]. Авторы также приводят список требований к промежуточному программному обеспечению, среди которых выделяют:

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

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

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

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

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

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

поддерживать стандарты безопасности.

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

В упомянутых научных работах авторы проанализировали сильные стороны SOA и аргументировали целесообразность внедрения этой архитектурой потенциальными выгодами. Таким образом, они доказали актуальность исследования парадигмы SOA. Однако, необходимость исследования этого ИТ-феномена также должно быть обусловлено желанием выявить недостатки этого подхода, чтобы знать о возможных проблемах при внедрении и успешно их обойти. В публикации «The Promise and Limitations of Service -Oriented Architecture», сделанной в журнале International Journal of Computers в 2007 году, выявлены положительные стороны SOA, но также довольно четко сформулированы ее основные проблемы и ограничения [10]. Авторы статьи считают, что переход на SOA обусловлен желанием разработать архитектуру с простым интеграционным механизмом, однако, все интеграционные решения, как правило, вендорные, что осложняет встраивание новых приложений в общую архитектуру. К прочим проблемам распределенной архитектуры отнесены:

«ловушки вендора»: связь приложений осуществляется по протоколам, разработанным самим вендором;

сильная связь компонентов: некоторые сервисы связаны напрямую, без промежуточного ПО;

сложность взаимодействия компонентов;

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

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

Таким образом, авторы очередной статьи согласны с тем, что SOA предлагает новый способ внедрения и развития приложений в компании, однако, ее неграмотное внедрение может быть тяжело для ИТ-слоя компании. Для этого требуется определить функциональность сервисов для поддержки бизнес-решений, и, хотя выгоды от успешного внедрения могут быть колоссальными, этот также требует изменения корпоративного менталитета, обучения персонала, инвестиций, введения новых стандартов [11-12]. Поэтому проблема эффективности сервисно-ориентированной архитектуры в компании имеет место быть. Обозначенную проблему можно считать актуальной, т.к. все публикации были сделаны за последнее десятилетие. Следовательно, проблема интеграции приложений стоит для компаний особенно остро, а исследование проблемы, в основном, носит аналитический характер. Примеров оценки эффективности на практике относительно мало, а также сложно найти какие-либо рекомендации по успешному переходу на SOA.

3. Анализ практического применения SOA в ИТ компании

Данный раздел работы посвящен анализу интеграции систем при использовании в компании сервисно-ориентированного подхода. В этой главе будет рассмотрен один бизнес-процесс и его протекание в нескольких смежных системах. Также будет описано взаимодействие систем при помощи вызовов веб-сервисов и передачи сообщений в XML-формате на примере одной точи интеграции (ТИ). В качестве объекта исследования выбрана модель сервисно-ориентированной архитектуры, развернутая в российской компании-интеграторе «ЗАО КРОК инкорпорейтед». На практических примерах будут раскрыты преимущества веб-сервисов, и будут приведены доказательства эффективности их использования. В Приложении 1 приведен глоссарий терминов и аббревиатур, используемых в Компании.

3.1 Описание деятельности компании «ЗАО КРОК Инкорпорейтед»

ЗАО «КРОК Инкорпорейтед» (далее - Компания) - российский системный интегратор, который работает на ИТ-рынке c 1992 года и входит в топ-10 крупнейших ИТ-компаний России [11].

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

Свою деятельность КРОК осуществляет в рамках проектов с внешними заказчиками, поэтому основу работы Компании составляет проектная деятельность. Компании КРОК соответствует матричная организационная структура (Приложение 2). В такой структуре присутствует как иерархичность подчинения верхним уровням, так и «горизонтальное» разделение по проектам. Таким образом, бизнес-процессы в Компании протекают через несколько функциональных подразделений, а не в рамках одного, и, как следствие, поддерживаются в разных смежных системах. Исходя из этого, в Компании реализован процессный подход к управлению, при котором единицей измерения деятельности компании является бизнес-процесс, и организация рассматривается как совокупность таких процессов. Именно при такой организационной структуре использование набора сервисов для выполнения процессов, протекающих через несколько департаментов, наиболее выгодно, поскольку в разных департаментах зачастую используются разные информационные системы для выполнения собственных нужд. Качественный обмен информацией между системами может быть успешно реализован посредством сервисно-ориентированной архитектуры.

3.2 Моделирование процесса, протекающего в смежных системах

В этом разделе будет рассмотрен процесс Согласования договора (СД), который главным образом протекает двух системах: в системе управления ресурсами компании 1С:ERP и системе автоматизации бизнес-процессов К2 с вызовами смежной системы финансового планирования Финансовый калькулятор (ФК).

Бизнес-процесс согласования договора охватывает часть жизненного цикла проекта. Процесс выполняется со следующими целями:

- согласовать договор с юристом, бухгалтером;

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

по итогам согласования проставить ЭЦП;

- отразить в карточке договора изменения, связанные с согласованием договора.

Автоматизация бизнес-процесса согласования договора выполняется с целями:

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

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

обеспечить контроль проставления ЭЦП.

Описание процесса по шагам представлено в разделе «3.2.1. Описание инициации и шагов процесса». Для создания схемы процесса выбрана нотация EPC, поскольку она позволяет описать процесс в виде последовательности функций, не имеет жесткого определенного набора необходимых элементов для построения, а также позволяет дать ответы на вопросы «С чего началось?», «Что сделали?», «Кто выполнил?». Данная нотация позволяет выделить важную информацию, необходимую в дальнейшем для построения схемы интеграционного взаимодействия, и избежать перегруженности схемы за счет опущения некоторых деталей (например, входящих/исходящих бумажных документов, терминов или товарно-материальных ценностей), которые в контексте интеграции систем не важны. Схема процесса в нотации EPC представлена в Приложении 3.

3.2.1 Описание инициации процесса и его шагов

Для понимания интеграционного взаимодействия первой ступенью является декомпозиция процесса на шаги и описание бизнес-смысла каждого шага:

)        Формирование

Интерфейс формирования открывается в системе К2 после перехода на нее из карточки договора в 1С и является стартовой формой бизнес-процесса. Процесс формируется после отправки данных с этой формы.

На этапе формирования пользователь заполняет открываемую в К2 стартовую форму, заполняет данные в карточке договора и запускает процесс. После формирования, процесс автоматически уходит на шаг Проверка администратором. С данного шага также есть возможность отклонить процесс, если тот стартован ошибочно.

)        Проверка администратором (ПА)

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

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

)        Согласование юристом (СЮ)

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

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

На данном шаге меняется ответственный за процесс, и ответственным становится юрист. Возможный исполнитель выбирается из заранее назначенной группы ответственных юристов. Любой из указанной группы имеет равные права для принятия решения на шаге, но решение принимается только одним участником - первым, кто обработал процесс. Юрист принимает решение о правомерности заключения определенного договора, проставляет ЭЦП на электронных документах. Если юрист замечает некорректность в заполнении договора, он имеет возможность отправить процесс обратно на Проверку администратором с соответствующим комментарием и статусом «Не утверждено». При успешном согласовании он также отправляет процесс на Проверку администратором со статусом «Утверждено».

)        Согласование менеджером (СМ)

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

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

)        Согласование Директором клиента (ДК)

Процесс должен быть отправлен на данный шаг процесс, если на этапе Формирования в карточке договора в 1С была указана организация, по которой в системе CRM значится Директор клиента.

Часть организаций в системе CRM не имеет Директора клиента и относится к так называемой «базе свободных клиентов». Организациям из свободной базы не назначен курирующий их сотрудник Компании (Директор клиента). Как правило, это организации-клиенты, не приносящие прибыли, сделки с которыми случаются очень редко, или только могут случиться потенциально. Процесс, в котором указаны такие организации, шаг Согласование Директором клиента не проходит.

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

)        Согласование бухгалтером (СБ)

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

)        Расчет рентабельности (РР)

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

3.2.2 Описание фрагмента интеграционной схемы

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

Поскольку для понимания точки интеграции систем с помощью веб-сервисов более важно визуализировать, как с помощью методов сервисов передается инициатива между системами в процессе, принято решение использовать для моделирования интеграции блок-схему в виду ее наглядности и лаконичности, а также концентрации больше на алгоритмике процесса, чем на его детализации. Кроме того, она позволяет распределить функции и элементы по контейнерам, что наглядно дает понять, на стороне какой системы происходит активность. Блок-схема осуществления интеграции систем в рамках процесса Согласования договора представлена в Приложении 4. В интеграционной схеме показан только шаг Формирование процесса Согласование договора в виду множественности вызовов веб-сервисов и размера интеграционной схемы, которые выходят за пределы установленных объемов данной работы.

В глоссарии в Приложении 1 описаны понятия, относящиеся к данной предметной области. В Таблице 3.1 описана суть методов веб-сервиса, вызываемого в данном процессе.

Таблица 3.1. Методы веб-сервиса

Описание шага «Формирование» с вызовами веб-сервисов: сотрудник создал в учетной системе 1С карточку договора и заполнил ее реквизиты (наименование, клиента и т.д.) и нажал на кнопку Согласование договора в карточке. Данное событие служит началом процесса Согласование договора, происходит переход в систему К2, открывается форма согласования К2. Система К2 вызывает метод GetAgreementData учетной системы 1С для получения заполненных реквизитов и вывода нужных из них на форму К2. По полученным сведениям К2 определяет, является ли это договором продажи или нет. Далее есть 2 сценария развития:

)        Если договор НЕ является договором продажи (т.е. это договор с поставщиком), но при этом имеет связные с ним договоры продажи, вызывается метод веб-сервиса GetSaleAgreementList для проверки связных договоров. Поскольку только договоры продажи имеют плановые данные и, следовательно, только они могут иметь корректируемые договоры, вызов метода получения иерархии GetAgreementHierarchy не нужен. На этом загрузка формы завершается, пользователь видит окончательно загруженную форму. Открытие контрола ФК также недоступно, поскольку контрол является интерфейсом для заполнения плановых данных, а плановых данных у договоров с поставщиками не предусмотрено.

Далее есть 2 опции: отменить процесс (в таком случае происходит выход) или нажать «Запустить». При нажатии «Запустить» происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если черновики есть, пользователю выводится сообщение о необходимости сохранить или удалить черновик, и переход на следующий шаг не осуществляется. Если метод вернул успех, процесс переходит на Проверку администратором. В случае с договорами не продажи данный метод всегда возвращает успех в виду отсутствия плановых данных.

)        Если договор является договором продажи, вызывается метод веб-сервиса CheckAgreement, который проверяет наличие этого договора в системе ФК и, если договор есть, метод возвращает успех, иначе инициируется отправка датаграммы для вставки договора в ФК, которая собирается из данных, полученных от 1С методом GetAgreementData. После чего выполнение метода CheckAgreement возвращает успех. На форму К2 выводятся данные по договору, открытие формы на этом завершается, и пользователь видит полностью загруженную форму.

Если при этом договор является корректируемым, то происходит вызов веб-сервиса для получения из учетной системы иерархии договоров GetAgreementHierarchy. При нажатии с формы кнопки «Открыть контрол для заполнения ПД», К2 вызывает открытие формы ФК, и открывается интерфейс для заполнения ПД. Дальнейшие действия по заполнению плановых данных происходят уже в системе ФК. При сохранении версии плановых данных в контроле и нажатии кнопки «Вернуться к процессу К2» происходит переход обратно на форму К2, откуда можно также отменить процесс или запустить. При нажатии Запустить происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если метод возвращает успех, процесс переходит на шаг Проверка администратором. При возвращении неудачи выводится информационное сообщение о необходимости сохранить или удалить черновик плановых данных. При возвращении методом успеха процесс переходит на шаг Проверка администратором.

Таким образом, сервисно-ориентированная архитектура делает возможной реализацию сложного бизнес-процесса, в котором присутствуют элементы, за создание и поддержание актуальности которых отвечают различные мастер-системы. Так, в процессе Согласования договора имеется карточка договора, мастер-системой по которой и по самой сущности договора является учетная система 1С, где и заводится карточка и ее атрибуты. Атрибуты этой сущности меняются только в учетной системе, остальные смежные системы потребляют изменение сущности онлайн-синхронизацией, реализованной через шину в формате XML-датаграмм. Кроме основных атрибутов в карточке у договора есть версии плановых данных, которые представляют собой план будущих работ и затрат, детализированный по этапам. Мастер-системой по плановым данным является система АРМ Финансовый калькулятор, поэтому, в процессе Согласования договора продажи, при необходимости заполнения плановых данных, необходимо вызывать интерфейс для работы с системой ФК.

Кроме этого, в процессе также происходят вызовы веб-сервисов с методами получения данных от прочих смежных систем. Например, система HRMS (мастер-система по сотрудникам) вызывается, чтобы подтянуть в карточку договора информацию о менеджере договора, система CRM (мастер-система по организациям) - чтобы подтянуть в карточку договора информацию по организации.

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

Интеграцию систем в процессе Согласования договора на шаге Формирования с участием большего числа систем (вспомогательных, для добавления в процесс актуальных данных) можно рассмотреть на следующем примере:

Компания собирается заключить договор с клиентом-организацией N на продажу лицензий ПО, т.е. планируется некий проект продажи и, возможно, предоставления сопутствующих услуг установки и обучения персонала. Первым делом назначается директор клиента, сотрудник Компании, ответственный за работу с этим клиентом и за заключение с ним сделок. Далее Директор клиента заводит организацию-клиента в системе CRM, где указывает ее данные, статус, проходит процесс проверки организации на чистоту. После этого назначаются менеджер договора и администраторы. Администратор заводит сущность договора в 1С, при этом для договора генерируется уникальный идентификационный номер. В карточке заполняется часть атрибутов, которые можно завести только в учетной системе 1С. Далее в карточку нужно внести информацию об организации, по которым 1С не является мастер-системой. В справочнике организаций 1С хранятся только GUID организации и ее наименование из CRM. Хранить такой справочник в учетной системе необходимо для возможности выбора организации из выпадающего списка в карточке договора. Притом в карточке договора кроме наименования организации должны содержаться и другие данные организации: реквизиты, адреса. Полная информация по организации-клиенту хранится только в CRM. При заведении новой организации, либо при изменении существующей, в шину отправляется полная датаграмма, которая раздает датаграммы в заинтересованные смежные системы, предварительно «обрезав» их по заранее настроенным фильтрам, которые настроены индивидуально для разных систем.

Так, в систему 1С приходит идентификатор, наименование и признак архивности, другие смежные системы могут потреблять более обширные данные, например, еще и реквизиты.

Когда сотрудник выбирает в выпадающем списке в карточке договора наименование организации, из данных справочника организации берется идентификатор этой организации и вызывается метод получения данных соответствующего веб-сервиса с идентификатором организации. Метод возвращает нужные данные по организации из CRM, и необходимые поля по организации заполняются в карточке договора автоматически. То же самое происходит при заполнении сотрудника, данные о котором приходят из системы HRMS. Вызовы смежных систем, от которых в процессе Согласования договора требуется только подтянуть нужную информацию в процесс (описанный выше пример вызовов CRM и HRMS систем), не вынесены на интеграционную схему с целью не перегружать модель. Данные методы являются методами получения информации, при выполнении которых не происходит преобразования данных в смежных системах, и их вызов не зависит от сценария развития процесса, поэтому в интеграции систем они играют вспомогательную роль.

Итак, сервисно-ориентированная архитектура позволяет веб-сервисам подгружать необходимые данные из различных мастер-систем в процесс. Эффективность такого подхода заключается в возможности хранить данные не в справочнике одной системы, а распределить полные данные по предметным областям систем, а в справочниках смежных систем хранить только уникальные ключи. Это позволяет облегчить базы данных организации, потому что хранение всех данных в одной базе, к которой все подряд системы будут обращаться при необходимости, имеет множество недостатков. Прежде всего, тяжело поддерживать целостность и актуальность таких данных, поскольку достаточно затруднительно назначить ответственных за поддержание данных отдельных таблиц в общей базе. Также, при таком хранении данных повышается риск дублирования данных, что тоже «утяжеляет» базу. Еще один существенный недостаток - время обработки запросов. Допустим, в организации имеется одна база данных, которая состоит из множества связанных или несвязанных таблиц (таблицы в базе могут храниться кластерами по предметным областям). Запрос к таблице такой базы, особенно при множественных операциях JOIN будет выполняться гораздо дольше, чем запрос к какому-либо справочнику системы, получению из него идентификатора сущности и вызову веб-сервиса для получения данных из мастер-системы по этому ключу для вывода их на форму.

Для подтверждения этого был проведен эксперимент: в процессе Согласования было замерено открытие формы в системе К2 на шаге Формирование, в которую подтягиваются данные из смежных систем с помощью вызовов методов получения данных. Это время составило 3 секунды. Если бы в Компании была общая база данных для всех систем, то при заполнении карточки договора потребовалось бы объединение таблиц: Agreement (договор), SystemUser (пользователь системы), Organization (организация), Firm (фирма), Direction (направление), Process (процесс), Manufacturer (производитель), Activity (активность) и нескольких других, содержащих большое количество атрибутов и строк каждая, а также несколько промежуточных таблиц-маппингов, описывающих связи многие-ко-многим.

Тестовый SQL-запрос с 1 условием из 8 таблиц произвольной базы данных, где таблицы имеют следующее количество строк: 57414, 7848, 17253, 50971, 116269, 35939, 18224, 26510 строк (что по объему даже меньше, чем справочники систем) выполнялся 9 секунд. Таким образом, выполнение SQL-запроса к массивной базе происходит дольше, чем получение данных с помощью веб-сервисов из распределенных справочников. Поскольку данные преимущественно динамичные, в такой базе будет неизбежно происходить постоянно обновление данных, а также к ней будет поступать слишком много запросов за единицу времени, что также увеличит время выполнения запроса.

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

3.3 Анализ одной точки интеграции

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

Поскольку в процессе Согласования договора преимущественно участвуют ранее описанные системы 1С:ERP, К2 и Финансовый калькулятор, далее будет рассмотрена точка интеграции этих трех систем и перечислены веб-сервисы от каждой системы, опубликованные в реестре. Кроме того, будет представлен пример вызова одного из сервисов в формате XML, также представленного на интеграционной схеме. Описание систем, участвующих в интеграции представлено в Таблице 3.2.

Таблица 3.2. Точка интеграции по процессу Согласование договора

Далее будет рассмотрен один из веб-сервисов системы Финансовый калькулятор под названием Integration, и представлено описание одного из методов сервиса (CheckAgreement). Затем будет проанализирована датаграмма одного вызова этого сервиса и ответа смежной системы.

Веб-сервис Integration, поставляемый системой Финансовый калькулятор, предназначен для интеграции систем ФК и К2, ФК и 1С. Методы (операции веб-сервиса) включают:

CheckOutAgreementPlanData: метод для блокировки плановых данных договора в системе ФК, необходим для прекращения всем пользователям доступа к редактированию договора в момент работы с этим договором другого пользователя;

CheckInAgreementPlanData: метод для снятия блокировки с плановых данных договора при прекращении с ним пользовательской работы;

MarkAsOfficial: метод для пометки последней версии договора, как окончательной;

CreatePDAVersion: метод для перевода чернового варианта договора в официальный и включения этой версии в проект;

SetAgreementPlanDataProperties: метод для получения изменений по договору, произведенных в др. системах (напр., различные статусы утверждения);

GetPlanData: метод для получения плановых данных;

CheckAgreement: метод для проверки наличия договора в системе (напр., чтобы убедиться, что сущность просинхронизировалась успешно из учетной системы);

CheckConfirmDocumentDrafts: метод для проверки наличия черновиков в системе.

Рассмотрим подробнее метод CheckAgreement. Метод CheckAgreement вызывается при первоначальном создании карточки договора в 1С на шаге Формирование. При этом в случае отсутствия договора в ФК при вызове метода CheckAgreement система ФК запрашивает данные по договору из системы 1С посредством шины (с помощью метода GetAgreementData, метод из другого веб-сервиса, опубликованного системой 1С). На основании полученных данных в системе ФК создается договор, после чего передается ответная информация о наличии договора в К2 через шину (см. Приложение 4).

Согласно требованиям к производительности из ТЗ: время на обработку одного вызова при наличии договора в ФК - не более 1сек., при отсутствие договора в ФК - не более 2 секунд, не считая времени выполнения метода GetAgreementData.

Пример входящего на ФК вызова CheckAgreement в виде XML-датаграммы, в которой передается параметр-идентификатор договора приведен ниже. Записи взяты из журнала интеграционных логов системы ФК данные получены запросом к таблице интеграционных логов:

SELECT * FROM IntegrationLogEntry AS ile.[TimeStamp] < '2017-04-20 14:59:33.007' and ile.[TimeStamp] > '2017-04-20 14:50:33.007' AND(ile.[Content] AS NVARCHAR(MAX)) LIKE '%CheckAgreement%'BY ile.[TimeStamp] DESC

Время сделанного вызова 2017-04-20 14:52:31.667. Датаграмма входящего сообщения:

<soapenv:Envelope xmlns:soapenv="#"896682.files/image005.gif">

Рисунок 3.1. Результат запроса к таблице логов

Как видно на данном примере, обмен информации (а именно получение датаграммы с кодом договора, проверки таблицы в базе системы ФК на предмет наличия договора и его вставка) произошел за 0,033 секунды.

Итак, преимущества веб-сервисов в ИТ-архитектуре очевидны. Использование веб-сервисов и сервисной шины для обмена данных между системами делает возможным формирование журнала логов, в котором записываются все входящие и исходящие вызовы на стороне каждой из систем. Записи в таких журналах содержат текст XML-датаграмм, временной штамп (TimeStamp), наименование операции, наименование источника сообщение, направление вызова (in/out). Логирование вызовов позволяет быстро определить ошибку и понять, на стороне какой системы произошел сбой. Таким образом, сокращается время на диагностику и правку ошибок, снижаются трудозатраты системных инжененров, и обеспечивается бесперебойный информационный обмен между системами.

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

Заключение

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

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

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

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

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

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

были описаны основные инструменты для интеграции систем (корпоративная сервисная шина, XML-сообщения);

был смоделирован в нотации EPC 1 бизнес-процесс, требующий интеграции 3 систем посредством шины и веб-сервисов;

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

были приведены фактические показатели, которые можно оптимизировать на счет SOA;

были приведены аргументы, почему SOA подход эффективен.

На основании всего изложенного можно еще раз заключить, что сервисно-ориентированная архитектура является разумным подходом к организации систем и приложений в компании. По результатам проведенного анализа можно также предположить, в каких ситуациях такой подход имеет смысл, и предложить несколько рекомендаций компаниям, которые рассматривают переход на SOA.

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

Переход также имеет смысл для бизнеса, развивающегося в динамичной индустрии (напр. в сфере информационных технологий), в которой часто возникают потребности в новых решениях, и для быстрого перехода на новые приложения необходима гибкость архитектуры. Более того, для ИТ компании SOA архитектура является своего рода рекламой высокой технологичности и демонстрацией профессионализма, что может привлекать клиентов и подталкивать их к сотрудничеству с такой компанией. Однако, такой переход стоит предпринимать в компании с четко сформулированным обоснованием необходимости переходи и при условии достаточной информационной грамотности и заинтересованности кадров. До перехода на такую архитектуру компаниям можно рекомендовать следующее:

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

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

обеспечить достаточную пропускную способность сети, доступность серверов;

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

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

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

провести психологическую подготовку персонала к предстоящему переходу, сформировать у них понимание эффективности перехода.

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

Источники

1. Portier B. Service, Architecture, Governance, and Business Terms [Электронный ресурс].-URL: https://www.ibm.com/developerworks/webservices/library/ws-soa-term1. (Дата обращения: 22.04.2017).

. SOA и Web-сервисы для новичков [Электронный ресурс]. - URL: https://www.ibm.com/developerworks/ru/webservices/newto/. (Дата обращения: 25.02.2017).

. SOA Архитектурные особенности и практические аспекты. [Электронный ресурс]. - URL: #"896682.files/image006.gif">

Организационная структура Компании

Приложение 3

Схема процесса Согласование договора в нотации EPC

Приложение 4

Интеграционная блок-схема процесса Согласование договора, шаг Формирование