ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.10.2023
Просмотров: 101
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
1. Концепция сервисно-ориентированной архитектуры
2. Обзор публикаций. Определение глубины исследования проблемы
3. Анализ практического применения SOA в ИТ компании
3.1 Описание деятельности компании «ЗАО КРОК Инкорпорейтед»
3.2 Моделирование процесса, протекающего в смежных системах
», опубликованной в журнале «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.
Если в своей работе Бурбек больше проецировал «многоклеточность» живых организмов на отдельные компьютеры, которые составляют вычислительную сеть, то авторы данной статьи рассматривают к качестве звеньев сети веб-сервисы. Такой исследовательский подход более близок к современно модели 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.