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

Утверждая, что вычислительные системы повторяют идею эволюции от одноклеточного к многоклеточных организмам, Бурбек предлагает воспользоваться 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). В такой структуре присутствует как иерархичность подчинения верхним уровням, так и «горизонтальное» разделение по проектам. Таким образом, бизнес-процессы в Компании протекают через несколько функциональных подразделений, а не в рамках одного, и, как следствие, поддерживаются в разных смежных системах. Исходя из этого, в Компании реализован процессный подход к управлению, при котором единицей измерения деятельности компании является бизнес-процесс, и организация рассматривается как совокупность таких процессов. Именно при такой организационной структуре использование набора сервисов для выполнения процессов, протекающих через несколько департаментов, наиболее выгодно, поскольку в разных департаментах зачастую используются разные информационные системы для выполнения собственных нужд. Качественный обмен информацией между системами может быть успешно реализован посредством сервисно-ориентированной архитектуры.