Модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений
Рассмотрение эффективности корпоративной сервисной шины и веб-сервисов. Ознакомление со стеком технологий веб-сервисов. Исследование и характеристика процесса взаимодействия между потребителем и провайдером сервиса, который задается с помощью интерфейса.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 22.08.2017 |
| Размер файла | 596,0 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Оглавление
Введение
1. Концепция сервисно-ориентированной архитектуры
2. Обзор публикаций. Определение глубины исследования проблемы
3. Анализ практического применения SOA в ИТ компании
3.1 Описание деятельности компании «ЗАО Крок Инкорпорейтед»
3.2 Моделирование процесса, протекающего в смежных системах
3.2.1 Описание инициации процесса и его шагов
3.2.2 Описание фрагмента интеграционной схемы
3.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. Аналогии многоклеточных организмов и компьютерных сетей
|
Особенность |
Многоклеточные организмы |
Вычислительные сети |
|
|
Специализация вытесняет общее поведение |
Клеткам при развитии определяется специализация, которая сохраняется с ними на протяжении всего жизненного цикла |
Большинство сервисов имеют чересчур большой репертуар неиспользуемых характеристик, которые снижают их эффективность. Биология позволяет предположить, что большая специализация будет преимуществом. |
|
|
Коммуникация с помощью полиморфных сообщений |
Клетки многоклеточных организмов передают информацию с помощью молекул-посыльных, но никогда через ДНК. Значение сообщения клетка-клетке определяется принимающей клеткой, не отправителем. |
Исполняемый код - это аналог ДНК. Многие сервисы позволяют скачивание исполняемого кода (напр. .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.
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 Описание инициации процесса и его шагов
Для понимания интеграционного взаимодействия первой ступенью является декомпозиция процесса на шаги и описание бизнес-смысла каждого шага:
1) Формирование
Интерфейс формирования открывается в системе К2 после перехода на нее из карточки договора в 1С и является стартовой формой бизнес-процесса. Процесс формируется после отправки данных с этой формы.
На этапе формирования пользователь заполняет открываемую в К2 стартовую форму, заполняет данные в карточке договора и запускает процесс. После формирования, процесс автоматически уходит на шаг Проверка администратором. С данного шага также есть возможность отклонить процесс, если тот стартован ошибочно.
2) Проверка администратором (ПА)
Возможным исполнителем на шаге является выбранный администратор договора в карточке 1С. Администратор является ответственным за прохождение процесса согласования. Он проверяет корректность заполнения плана работ по договору после каждого шага согласования и, при необходимости, вносит корректировки в план.
После заполнения и проверки плановых данных администратор имеет возможность отправить процесс на один из следующих шагов: Расчет рентабельности, Согласование бухгалтером, Согласование директором клиента, Согласование менеджером, Согласование юристом. В зависимости от условий, в процессе может потребоваться прохождение всех шагов, либо некоторые из них могут быть опущены. С каждого из вышеперечисленных шагов процесс возвращается на шаг Проверка администратором со статусом утверждения, либо с комментарием о необходимости отклонения. При получении с шага положительного согласования администратор имеет возможность отправлять процесс на дальнейшие согласования, при этом на шаг Расчет рентабельности процесс отправляется после получения всех необходимых согласований с других шагов, в противном случае процесс будет ему возвращен с комментарием пройти все необходимые шаги. Очередность шагов администратор выбирает сам исходя из собственной оценки сделки и профессионального опыта, отправляя договор в первую очередь на шаги, где согласование с большей вероятностью может быть отклонено, или может возникнуть потребность дополнительного анализа сделки. Так делается для того, чтобы при отклонении процесса на одном из шагов минимизировать количество уже пройденных шагов и не потратить впустую время других согласующих.
3) Согласование юристом (СЮ)
Администратор имеет необходимость и возможность отправить процесс на шаг Согласование юристом при условии, что сумма сделки превышает определенный ценовой порог. Данное значение утверждается финансово-аналитическим отделом раз в год и является конфиденциальной информацией Компании. Это значение заносится в конфигурационные файлы системы. При превышении суммы договора этого конфигурационного параметра в пользовательский интерфейс выводится кнопка «Отправить на согласование юристом».
Такая логика связана с необходимостью дополнительной проверки правовых аспектов сделки с особо крупными суммами контракта.
На данном шаге меняется ответственный за процесс, и ответственным становится юрист. Возможный исполнитель выбирается из заранее назначенной группы ответственных юристов. Любой из указанной группы имеет равные права для принятия решения на шаге, но решение принимается только одним участником - первым, кто обработал процесс. Юрист принимает решение о правомерности заключения определенного договора, проставляет ЭЦП на электронных документах. Если юрист замечает некорректность в заполнении договора, он имеет возможность отправить процесс обратно на Проверку администратором с соответствующим комментарием и статусом «Не утверждено». При успешном согласовании он также отправляет процесс на Проверку администратором со статусом «Утверждено».
4) Согласование менеджером (СМ)
Прохождение этого шага необходимо, если администратор договора и менеджер договора - не одно лицо, и в карточке договора в 1С на Формировании указан код проекта, в который в перспективе планируется включить договор. В случаях, когда менеджер договора сам администрирует договор, либо когда в карточке договора не задан проект, шаг пропускается.
На данном шаге менеджер проверяет необходимость включения договора в проект, т.е. смотрит, действительно ли обязательства по данному договору должны выполняться в рамках указанного проекта. С данного шага процесс возвращается на Проверку администратором с соответствующим статусом утверждения.
5) Согласование Директором клиента (ДК)
Процесс должен быть отправлен на данный шаг процесс, если на этапе Формирования в карточке договора в 1С была указана организация, по которой в системе CRM значится Директор клиента.
Часть организаций в системе CRM не имеет Директора клиента и относится к так называемой «базе свободных клиентов». Организациям из свободной базы не назначен курирующий их сотрудник Компании (Директор клиента). Как правило, это организации-клиенты, не приносящие прибыли, сделки с которыми случаются очень редко, или только могут случиться потенциально. Процесс, в котором указаны такие организации, шаг Согласование Директором клиента не проходит.
Отправка на этот шаг определяется необходимостью проверить корректность заполнения реквизитов организации-клиента лицом, ответственным за этого клиента, а также для подтверждения факта сотрудничества с этой организацией по данному договору. С данного шага процесс возвращается на Проверку администратором с соответствующим статусом утверждения.
6) Согласование бухгалтером (СБ)
Аналогично шагу Согласование юристом, администратор имеет необходимость и возможность отправить процесс на шаг Согласование бухгалтером при условии, что сумма сделки превышает определенный ценовой порог. Это необходимо для дополнительной проверки договоров с особо крупными суммами.
Исполнителем на шаге является любой сотрудник из заранее определенной группы ответственных бухгалтеров. Решение принимается одним исполнителем, первым обработавшим процесс. На этом шаге бухгалтеры проверяют договор для финансового и налогового учета, анализируют последствия налогового бремени заключаемого договора. С данного шага процесс возвращается на Проверку администратором с соответствующим статусом утверждения.
7) Расчет рентабельности (РР)
На Расчет рентабельности администратор отправляет процесс после сбора всех необходимых согласований на шагах, описанных выше. На этом шаге происходит финальное утверждение договора, после которого он считается успешно согласованным, и ему проставляется статус «Согласован». Исполнителями на шаге являются сотрудники из группы отдела Расчета рентабельности. Они проверяют целесообразность заключения данного договора, анализируют рассчитанную рентабельность при условии выполнения договора в указанные сроки, проводят оценку вероятности получения рассчитанной прибыли. При необходимости процесс могут вернуть на Проверку администратору для внесения коррективов в план договора, либо с комментарием отклонить процесс в виду нецелесообразности его заключения. Выход из процесса возможен после прохождения этого шага (помимо случаев отклонения процесса на шаге Проверка администратором). При успешном согласовании договора на данном шаге процесс Согласования договора завершается, при этом, в зависимости от того, какая была указана цель при создании процесса, автоматически запускается один из процессов «Старт нового проекта», либо «Включение договора в проект».
3.2.2 Описание фрагмента интеграционной схемы
Поскольку процесс протекает в нескольких системах, для проектирования взаимодействия необходимо составить интеграционную схему, из которой будет видно, на каких этапах бизнес процесса вызываются те или иные веб-сервисы и их методы. Вызов веб-сервисов происходит отправкой через шину запросов в формате XML и получения аналогичным способом ответа. Подобная схема обмена сообщениями и вызовов методов веб-сервисов характерна сервисно-ориентированной архитектуре.
Поскольку для понимания точки интеграции систем с помощью веб-сервисов более важно визуализировать, как с помощью методов сервисов передается инициатива между системами в процессе, принято решение использовать для моделирования интеграции блок-схему в виду ее наглядности и лаконичности, а также концентрации больше на алгоритмике процесса, чем на его детализации. Кроме того, она позволяет распределить функции и элементы по контейнерам, что наглядно дает понять, на стороне какой системы происходит активность. Блок-схема осуществления интеграции систем в рамках процесса Согласования договора представлена в Приложении 4. В интеграционной схеме показан только шаг Формирование процесса Согласование договора в виду множественности вызовов веб-сервисов и размера интеграционной схемы, которые выходят за пределы установленных объемов данной работы.
В глоссарии в Приложении 1 описаны понятия, относящиеся к данной предметной области. В Таблице 3.1 описана суть методов веб-сервиса, вызываемого в данном процессе.
Таблица 3.1. Методы веб-сервиса
|
Метод веб-сервиса |
Описание сути метода |
|
|
GetAgreementData |
Возвращает набор данных о договоре из учетной системы (1С) |
|
|
GetSaleAgreementList |
Возвращает список договоров, связанных с согласуемым |
|
|
CheckAgreement |
Возвращает успех при наличии договора в системе ФК и неудачу при его отсутствии |
|
|
GetAgreementHierarchy |
Возвращает иерархию договоров из учетной системы (1С) |
|
|
CheckConfirmDocumentDrafts |
Проверяет наличие черновика плановых данных договора в системе ФК. |
Описание шага «Формирование» с вызовами веб-сервисов: сотрудник создал в учетной системе 1С карточку договора и заполнил ее реквизиты (наименование, клиента и т.д.) и нажал на кнопку Согласование договора в карточке. Данное событие служит началом процесса Согласование договора, происходит переход в систему К2, открывается форма согласования К2. Система К2 вызывает метод GetAgreementData учетной системы 1С для получения заполненных реквизитов и вывода нужных из них на форму К2. По полученным сведениям К2 определяет, является ли это договором продажи или нет. Далее есть 2 сценария развития:
1) Если договор НЕ является договором продажи (т.е. это договор с поставщиком), но при этом имеет связные с ним договоры продажи, вызывается метод веб-сервиса GetSaleAgreementList для проверки связных договоров. Поскольку только договоры продажи имеют плановые данные и, следовательно, только они могут иметь корректируемые договоры, вызов метода получения иерархии GetAgreementHierarchy не нужен. На этом загрузка формы завершается, пользователь видит окончательно загруженную форму. Открытие контрола ФК также недоступно, поскольку контрол является интерфейсом для заполнения плановых данных, а плановых данных у договоров с поставщиками не предусмотрено.
Далее есть 2 опции: отменить процесс (в таком случае происходит выход) или нажать «Запустить». При нажатии «Запустить» происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если черновики есть, пользователю выводится сообщение о необходимости сохранить или удалить черновик, и переход на следующий шаг не осуществляется. Если метод вернул успех, процесс переходит на Проверку администратором. В случае с договорами не продажи данный метод всегда возвращает успех в виду отсутствия плановых данных.
2) Если договор является договором продажи, вызывается метод веб-сервиса CheckAgreement, который проверяет наличие этого договора в системе ФК и, если договор есть, метод возвращает успех, иначе инициируется отправка датаграммы для вставки договора в ФК, которая собирается из данных, полученных от 1С методом GetAgreementData. После чего выполнение метода CheckAgreement возвращает успех. На форму К2 выводятся данные по договору, открытие формы на этом завершается, и пользователь видит полностью загруженную форму.
Если при этом договор является корректируемым, то происходит вызов веб-сервиса для получения из учетной системы иерархии договоров GetAgreementHierarchy. При нажатии с формы кнопки «Открыть контрол для заполнения ПД», К2 вызывает открытие формы ФК, и открывается интерфейс для заполнения ПД. Дальнейшие действия по заполнению плановых данных происходят уже в системе ФК. При сохранении версии плановых данных в контроле и нажатии кнопки «Вернуться к процессу К2» происходит переход обратно на форму К2, откуда можно также отменить процесс или запустить. При нажатии Запустить происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если метод возвращает успех, процесс переходит на шаг Проверка администратором. При возвращении неудачи выводится информационное сообщение о необходимости сохранить или удалить черновик плановых данных. При возвращении методом успеха процесс переходит на шаг Проверка администратором.
Таким образом, сервисно-ориентированная архитектура делает возможной реализацию сложного бизнес-процесса, в котором присутствуют элементы, за создание и поддержание актуальности которых отвечают различные мастер-системы. Так, в процессе Согласования договора имеется карточка договора, мастер-системой по которой и по самой сущности договора является учетная система 1С, где и заводится карточка и ее атрибуты. Атрибуты этой сущности меняются только в учетной системе, остальные смежные системы потребляют изменение сущности онлайн-синхронизацией, реализованной через шину в формате XML-датаграмм. Кроме основных атрибутов в карточке у договора есть версии плановых данных, которые представляют собой план будущих работ и затрат, детализированный по этапам. Мастер-системой по плановым данным является система АРМ Финансовый калькулятор, поэтому, в процессе Согласования договора продажи, при необходимости заполнения плановых данных, необходимо вызывать интерфейс для работы с системой ФК.
Кроме этого, в процессе также происходят вызовы веб-сервисов с методами получения данных от прочих смежных систем. Например, система HRMS (мастер-система по сотрудникам) вызывается, чтобы подтянуть в карточку договора информацию о менеджере договора, система CRM (мастер-система по организациям) - чтобы подтянуть в карточку договора информацию по организации.
Как правило, в каждой системе хранятся справочники всех сущностей, при этом каждая система хранит только нужные ей атрибуты из справочника мастер-системы. Полные данные хранятся только в мастер-системе, но могут быть получены смежными системами с помощью методов веб-сервисов.
Интеграцию систем в процессе Согласования договора на шаге Формирования с участием большего числа систем (вспомогательных, для добавления в процесс актуальных данных) можно рассмотреть на следующем примере:
Компания собирается заключить договор с клиентом-организацией N на продажу лицензий ПО, т.е. планируется некий проект продажи и, возможно, предоставления сопутствующих услуг установки и обучения персонала. Первым делом назначается директор клиента, сотрудник Компании, ответственный за работу с этим клиентом и за заключение с ним сделок. Далее Директор клиента заводит организацию-клиента в системе CRM, где указывает ее данные, статус, проходит процесс проверки организации на чистоту. После этого назначаются менеджер договора и администраторы. Администратор заводит сущность договора в 1С, при этом для договора генерируется уникальный идентификационный номер. В карточке заполняется часть атрибутов, которые можно завести только в учетной системе 1С. Далее в карточку нужно внести информацию об организации, по которым 1С не является мастер-системой. В справочнике организаций 1С хранятся только GUID организации и ее наименование из CRM. Хранить такой справочник в учетной системе необходимо для возможности выбора организации из выпадающего списка в карточке договора. Притом в карточке договора кроме наименования организации должны содержаться и другие данные организации: реквизиты, адреса. Полная информация по организации-клиенту хранится только в CRM. При заведении новой организации, либо при изменении существующей, в шину отправляется полная датаграмма, которая раздает датаграммы в заинтересованные смежные системы, предварительно «обрезав» их по заранее настроенным фильтрам, которые настроены индивидуально для разных систем.
Подобные документы
Возможности интерфейса программирования приложений ARI крупных картографических веб-сервисов в процессе создания двух картографических веб-сервисов. Анализ существующих веб-сервисов. Карты Яндекса и Google, пользовательские карты. Выбор среды разработки.
дипломная работа [4,5 M], добавлен 24.09.2012Особенности создания набора web-сервисов, учитывающих функцию кредитоспособности покупателя. Учет возможности управления статусом заказа. Анализ функциональной декомпозиции системы. Использование разработанных сервисов и технологий, их эффективность.
курсовая работа [2,0 M], добавлен 24.02.2012Эволюция облачных сервисов. Характеристики и классификация облачных сервисов. Анализ возможностей облачных сервисов, предлагаемых для использования в малом бизнесе. Анализ стоимости владения локальным решением по автоматизации деятельности бухгалтерии.
курсовая работа [2,7 M], добавлен 10.05.2015Ознакомление с проблемами реализации сервис-ориентированной архитектуры предприятия. Анализ активных элементов бизнес-архитектуры. Рассмотрение инструментов реализации языка ArchiMate в программном средстве Archi. Исследование мотивационных концепций.
курсовая работа [2,0 M], добавлен 25.08.2017Рассмотрение взаимосвязи информационных подсистем предприятия. Характеристика сервис-ориентированной архитектуры информационных систем. Оценка реализации SOA-инфраструктуры на базе сервисной шины предприятия. Анализ бизнес-цели внедрения SOA-решений.
контрольная работа [1,0 M], добавлен 28.03.2018Идеи по использованию сервисов поисковой системы Google для совместной работы с учащимися в блоге "Учимся с Google". Организация коллективной деятельности с помощью сервисов Google. Характеристика функций основных сервисов, их достоинства и недостатки.
реферат [24,5 K], добавлен 27.11.2012Облачные технологии в бизнес-процессах. Модели использования бизнес-приложений в качестве интернет-сервисов. Практика применения облачных технологий. Приложения, созданные на основе Windows Azure. Создание систем и офисных приложений по запросу.
реферат [25,3 K], добавлен 16.06.2013Мониторинг сервисов веб-приложения. Проблема отслеживания большого количества сервисов, поддерживающих работу веб-приложения, ее решение с помощью "Service discovery"-инструментов. Применение программного инструмента Consul как клиент-серверной системы.
статья [184,4 K], добавлен 10.12.2016Анализ облачных сервисов для автоматизации бизнеса и обоснование преимуществ перехода на облачную обработку данных. Виды и модели облачных сервисов для бизнеса, принципы их работы и характеристики. Задачи автоматизации бизнеса на примере облачных решений.
дипломная работа [2,3 M], добавлен 06.09.2017Web 2.0 как новое поколение сетевых сервисов, его возможности и преимущества по сравнению с предшественниками. Принцип работы и назначение открытых общественных веб-сервисов. Деятельность и значение социальных сетевых сервисов на современном этапе.
курсовая работа [46,1 K], добавлен 03.07.2009
