Модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений - Программирование, компьютеры и кибернетика дипломная работа
Главная
Программирование, компьютеры и кибернетика
Модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений
Рассмотрение эффективности корпоративной сервисной шины и веб-сервисов. Ознакомление со стеком технологий веб-сервисов. Исследование и характеристика процесса взаимодействия между потребителем и провайдером сервиса, который задается с помощью интерфейса.
посмотреть текст работы
скачать работу можно здесь
полная информация о работе
весь список подобных работ
Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
1. Концепция сервисно-ориентированной архитектуры
2. Обзор публикаций. Определение глубины исследования проблемы
3. Анализ практического применения SOA в ИТ компании
3.1 Описание деятельности компании «ЗАО Крок Инкорпорейтед»
3.2 Моделирование процесса, протекающего в смежных системах
3.2.1 Описание инициации процесса и его шагов
3.2.2 Описание фрагмента интеграционной схемы
В условиях современной рыночной конкуренции компании остро нуждаются в новом поколении информационных систем и сервисов, которые способны предоставить расширенный, по сравнению с предыдущими системами, функционал, а также обеспечивать доступ к различным сервисам по требованию. Кроме того, бизнес нуждается в гибкости и динамичности таких сервисов, которые смогут иметь доступ к общим хранилищам данных, обмениваться данными между собой и обеспечивать различные виды взаимодействия, например, межсистемный или «бизнес для бизнеса» (B2B). Такие системы и сервисы должны грамотно интегрироваться, поскольку именно это позволит им быстро перестраиваться под меняющиеся бизнес-потребности, реагировать на изменения бизнес-правил, предоставлять возможность без потерь заменять устаревшие информационные компоненты, внедрять новые программные продукты в общую ИТ-инфраструктуру или переходить на новые платформы. Совокупность сервисов и систем, эксплуатируемых в компании, составляет общую ИТ-архитектуру, грамотное построение которой представляет сложность для большинства компаний.
Вышеперечисленные бизнес-потребности послужили причиной растущей популярности нового подхода к организации и интеграции сервисов, называемого сервисно-ориентированной архитектурой , или SOA (также сервис-ориентированная архитектура ). Для современных компаний SOA является достаточно привлекательной моделью ИТ-архитектуры, которая позволяет лучшим образом выровнять потребности бизнеса по отношению к имеющимся информационным ресурсам и использовать весь информационный потенциал компании по максимуму. Тема данной дипломной работы - «Анализ эффективности сервисно-ориентированной архитектуры в ИТ компании», и в данной работе будут рассмотрены основные особенности этого архитектурного подхода и приведены доказательства его эффективности.
SOA - это новый стиль архитектуры информационных систем, который позволяет разрабатывать и интегрировать бизнес-приложения. Эта архитектурная модель объединяет в себе техническую и организационную составляющие, которые позволяют компании иметь общую платформу для выполнения независимых бизнес-функций и сервисов, при этом по минимуму пресекаться в функциональности и избегать дублирования сервисов, приложений и данных. Поскольку сейчас большинство компаний инвестируют большие средства в крупномасштабные системы, такие как ERP (enterprise resource planning), CRM (customer relationship management), HRMS (human resource management systems), а подобные решения чаще всего «коробочные», у бизнеса возникает потребность выносить часть функционала в отдельные сервисы и интегрировать их на одной общей платформе. Следовательно, компании занимаются поиском оптимального соотношения сервисов и приложений и разделения между ними функциональности так, чтобы она не дублировалась, а также поиском наиболее эффективного инструмента интеграции для обеспечения взаимодействия между этими системами. Проблема современного бизнеса заключается в чрезмерном инвестировании во внутренние ИТ-проекты и во временных затратах на выполнение бизнес-функций, которые являются следствием выбора неэффективного системного решения.
Актуальность выбранной тематики для исследования объясняется высокой скоростью изменения информационных технологий и частым вхождением на рынок новых бизнес-приложений, которые с трудом интегрируются в устаревающую централизованную ИТ-архитектуру, состоящую из одной-двух массивных систем. Кроме того, актуальность исследования SOA заключается в возможности построить архитектуру приложений, которая позволит сократить общие затраты за счет снижения затрат на внедрение, техническую поддержку и затрат, связанных с временными потерями.
Таким образом, объектом исследования является модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений. Предмета м и исследования выступают наиболее часто используемые инструменты интеграции сервисов в распределенной архитектуре - корпоративная сервисная шина и веб-сервисы, эффективность которых будет рассмотрена в этой работе. Гипотеза на момент начала исследования: SOA является эффективным подходом к построению архитектуры в компании с потребностью в объемном функционале для удовлетворения бизнес-потребностей.
Главной целью данной дипломной работы является доказательство целесообразности применения концепции SOA в компании. Критерием целесообразности будет выступать оценка общей эффективности применения SOA в целом и в отдельно взятом российском ИТ-интеграторе. В свою очередь, оценка эффективности будет сформирована на основе уже проведенных исследований в данной области и на основе некоторых количественных показателей, таких как время передачи датаграммы в смежные системы и время получения ответного сообщения. Также, целью является набор сформулированных рекомендаций для успешного внедрения SOA и комментариев, касательно того, когда это внедрение имеет смысл. Для достижения поставленной цели будут выполнены следующие задачи :
- анализ зарубежных и российских публикаций с целью подтверждения наличия заявленной проблемы;
- моделирование одного бизнес-процесса, требующего для своей реализации интеграции систем;
- анализ интеграционного взаимодействия (точки интеграции) с замерами определенных показателей взаимодействия;
- предложение набора рекомендаций для успешного перехода на SOA.
Для решения поставленных задач будут использованы следующие методы : качественные методы анализа научных статей, методы сравнительной и описательной характеристик, процессное моделирование, выполнение интеграционных кейсов на практике с последующим количественных анализом.
Данная работа представлена в 3 главах. В первой главе дается описание концепции SOA, выделяются основные преимущества этого архитектурного подхода. Во второй главе проводится анализ имеющихся публикаций по заявленной проблеме с целью найти первоначальное подтверждение гипотезы и сделать предварительные выводы об эффективности, которым далее в практической части работы будет предоставлено подтверждение. В третьей главе будет описан опыт компании, использующей SOA, смоделирован один бизнес-процесс, и представлен фрагмент его интеграционной схемы. Далее будет проведен замер времени обмена сообщениями между системами.
В заключительной части будет подведен итог о проделанной работе, обоснована целесообразность перехода к SOA, и даны некоторые рекомендации для успешного перехода на эту архитектуру.
Сервисно-ориентированная архитектура, как результат эволюции ИТ-инфраструктуры, оформилась примерно в 1990-е годы. Переход к такой системной модели происходил постепенно. Еще в 1980-е годы организационные структуры компаний представляли собой вертикальные, изолированные подразделения, которые затем сменились горизонтальными, процессно-ориентированными структурами. Архитектура систем также трансформировалась вместе с бизнесом, и потребность в распределенных системах росла с ростом процессно-ориентированных организаций. Первыми были монолитные системы, в которых логика обработки данных и функциональная логика приходились на одну систему, размещенную на одной машине. Позднее логика была разделена на клиентскую и серверную части, из которых еще позже сервисы обработки данных были вынесены на отдельный сервер, образовав таким образом трехзвеньевую архитектуру. Такая архитектура затем эволюционировала в многозвеньевую, когда логически однородные функции, ранее хранившиеся на одном сервере, стали размещать на разных машинах для распределения нагрузки на сервера. Затем появились децентрализованные системы с распределенными объектами - компьютерные сети, основанные на равноправии участников. В таких сетях, как правило, отсутствуют выделенные серверы, а каждый узел является как клиентом, так и сервером [1-2]. Самой недавней архитектурой стала SOA - парадигма использования распределенных информационных ресурсов (приложений и данных), находящихся в сфере ответственности разных владельцев. Схема развития архитектурных решений представлена на Рисунке 1.1.
Рисунок 1.1. Эволюция архитектурных решений
Для сервисно-ориентированной архитектуры особое значение имеют слабая связь компонентов, независимость от географии расположения этих компонентов и независимость от протоколов (способов связи). Сервис в этой модели определяется как «исполнимая единица кода, которая предоставляет собой «черный ящик»: инкапсуляцию определенных функций. Он может быть вызван другими сервисами или системами с помощью стандартизированного потока сообщений»[3]. На Рисунке 1.2 представлена схема SOA с описанием основных понятий.
- Сервисы: логические сущности, которые определяются публикующим их интерфейсом;
- Провайдер сервиса: системная сущность, которая определяет специфику сервиса;
- Потребитель сервиса: системная сущность, которая вызывает провайдера сервиса. Является синонимом понятия «клиент», может быть пользовательским приложением или другим сервисом;
- Локатор сервиса: особый вид сервиса, выступающий в качестве реестра остальных сервисов и позволяющий осуществлять поиск нужных сервисов;
- Брокер: особый вид провайдера сервиса, который может передавать запросы к сервису другим сервис-провайдерам.
Взаимодействие между потребителем и провайдером сервиса задается с помощью интерфейса, который определяется набором сигнатур методов [4].
Все составляющие сервисно-ориентированной архитектуры можно разложить на технологии, составляющие в совокупности так называемый стек технологий веб-сервисов (Рисунок 1.3).
Рисунок 1.3. Стек технологий веб-сервисов
Стек технологий веб-сервисов условно делится на 2 составляющие: технологии для обеспечения функциональности и технологии для обеспечения качества сервисов. Эти составляющие, в свою очередь, можно разделить на слои.
- Транспортный слой: механизмы, используемые для обмена данными между веб-сервисами (HTTP, JMS);
- Коммуникационный слой: формализация механизмов использования транспортных протоколов веб-сервисами (SOAP);
- Слой описания сервисов: формализация интерфейсов веб-сервисов для обеспечения их независимости от аппаратно-программной платформы (XML, WSDL);
- Сервисный слой: доступные к использованию единицы функциональности, вызываемые с помощью WSDL;
- Бизнес-процесс: описание организации веб-сервисов для выполнения потока работ и процессов;
- Слой реестров сервисов: хранилище сервисов и их организация в иерархические структуры.
Технологии качества сервиса, в свою очередь, характеризуется следующими составляющими:
- Политики: описание правил, по которым веб-сервисы могут быть вызваны;
- Слой безопасности: возможности обеспечения безопасного доступа к сервисам (разделение доступа, ролевые модели, авторизация, аутентификация);
- Транзакционный слой: описание свойств транзакционности распределенных систем;
- Управленческий слой: возможности управления веб-сервисами и их масштабируемостью[5-6].
Таким образом, SOA -- это инструмент, позволяющий определить бизнес как наборов взаимосвязанных услуг. Одним из его преимуществ являются независимость сервисов от аппаратно-программного обеспечения, масштабируемость сервисов, их гибкость и простота при разработке новых приложений. SOA создает коммуникационную среду для программных компонентов, реализующих прикладную бизнес-логику. Информация о таких компонентах публикуется в стандартной форме, при которой их не требуется знаний об их реализации.
Феномен сервисно-ориентированной архитектуры относительно молод; хотя проблема интеграции информационных ресурсов появилась намного ранее. Как было отмечено во введении, в 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. Аналогии многоклеточных организмов и компьютерных сетей
Специализация вытесняет общее поведение
Клеткам при развитии определяется специализация, которая сохраняется с ними на протяжении всего жизненного цикла
Большинство сервисов имеют чересчур большой репертуар неиспользуемых характеристик, которые снижают их эффективность. Биология позволяет предположить, что большая специализация будет преимуществом.
Коммуникация с помощью полиморфных сообщений
Клетки многоклеточных организмов передают информацию с помощью молекул-посыльных, но никогда через ДНК. Значение сообщения клетка-клетке определяется принимающей клеткой, не отправителем.
Исполняемый код - это аналог ДНК. Многие сервисы позволяют скачивание исполняемого кода (напр. .exe-файлы).
Биология предполагает, что на это должен быть запрет, при этом обмен сообщениями должен происходить при вызове заинтересованной стороны с помощью не прямого выполнения кода, а вызова сервисов.
Создание внешних структур в зависимости от потребностей и под влиянием окружающей среды
Многоклеточные организмы способны выстраивать структуры в зависимости от условий окружающей среды и под ее влиянием (кости, панцири и т.п.)
Интрасети и базы данных - это структуры, образованные информационными сетями под влиянием потребностей бизнеса, поэтому опираться на такие естественным образом сформированные структуры эффективно.
Общая защита организма от вымирания отдельных клеток
Каждая клетка в многоклеточном организме готова к отмиранию.
Это отражает перспективу многоклеточного организма - пожертвовать отдельными клетками ради общего здоровья организма.
Составляющие компьютерной сети должны быть в состоянии отторгать ненужное: скачивание непроверенного кода, самостоятельно отключаться от малознакомых сетей. Кроме того, компоненты должны быть готовы к «отмиранию», т.е. быть быстро изъяты из системы и заменены другими приложениями или сервисами.
В современном сервисно-ориентированном подходе эти 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 уровня интеграций, необходимых для успешного функционирования бизнеса:
1) Интеграция коммуникативного уровня: интегрируемые распределенные приложения требуют, чтобы любые отдельно взятые приложения могли взаимодействовать и обмениваться информацией. Например, приложению может быть необходимо знать статус и операции удаленного приложения для того, чтобы выполнять определенные задачи, допустим, календарное планирование. Приложение с помощью протоколов способно запросить статус данных другой системы.
2) Интеграция данных: подразумевает исходные схемы, промежуточные схемы и их маппинг. Понятие «исходная схема» применимо к модели данных из источника данных; промежуточные схемы - это представления исходных схем для интегрируемых систем; маппинг представляет механизм преобразование запросов и данных для интегрируемых систем из исходных схем. Недостаток интеграции данных в том, что он требует существенных усилий на понимание моделей данных и на поддержание актуальности промежуточных схем, если меняются исходные.
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.
Данный раздел работы посвящен анализу интеграции систем при использовании в компании сервисно-ориентированного подхода. В эт
Модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений дипломная работа. Программирование, компьютеры и кибернетика.
Курсовая работа по теме Сущность логистики и ее роль в организации деятельности предприятия
Сострадание Это Определение Для Сочинения
Русский Классицизм Реферат По Литературе
Курсовая работа по теме Понятие и состав правонарушения
Реферат: Македонские земли в 1878-1914 гг.
Реферат: Leprosy In Medieval And Islamic Societies Different
Реферат: Внеклассное мероприятие по математике и информатике для 6 класса Кладоискатели
Управление Брендом Компании Курсовая
Курсовая работа по теме Диагностика и лечение стафилококковых инфекций
Дипломная работа по теме Государственная поддержка инновационной активности малого бизнеса
Реферат: A Separate Peace Chapter Summaries Essay Research
Курсовая работа по теме Сталінські репресії
Практическое задание по теме Встроенные типы данных в С#. Массивы. Строки. Регулярные выражения
Реферат по теме Економічне становище в Україні в 50-60-х роках ХХ століття
Доклад по теме Возможные побочные эффекты вакцинации
Пособие по теме История России от расселения восточных славян до нашего времени
Реферат: Периферийные устройства, модемы
Реферат: От атомов к молекулам. Скачать бесплатно и без регистрации
Реферат: Алекса ндр Христофо рович Восто ков
Реферат: Модели нейронных сетей
Происхождение человека: задача решена? - Биология и естествознание реферат
Метод ведения счетов и двойной записи - Бухгалтерский учет и аудит контрольная работа
Європейське бароко - Культура и искусство контрольная работа