ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ СЕРВИС – ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ

Сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) , классификация сервисов, осуществляющих проектирование информационных систем, слои сервис-ориентированной архитектуры.

Концепция архитектуры SОА (сервис-ориентированной архитектуры) содержит много новых подходов и является очень пер­спективной. SОА — это метод построения корпоративных систем. Он ориентируется на сервисы и, характеризуется распределенной архитектурой и слабосвязанными интерфейсами. Сервис в данном случае как единица работ, выполняемая сервис-провайдером для обеспечения желаемого результата потребителю сервиса. Именно сервис является повторно используемым, при этом он не зависит от технологий, языковых сред и других ресурсов.

Процесс сервис-ориентированного моделирования и построения архитектуры состоит из трех основных шагов: идентификации, спецификации и реализации сервисов, компонентов и потоков (обычно путем объединения сервисов)[4, с.54].

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

• метод на основе информации;
• метод на основе процесса моделирования;
• метод на основе требований.

Восходящий подход заключается в объединении существующих приложений в виде сервисов. Сервисы, обслуживаемых приложений, могут быть повторно включены для построения композитных сервисов, основанных на потребностях бизнеса. Такой подход начинается с определение основных компонентов сервисов, как мельчайшую часть будущей системы. Это позволяет комбинировать их с более крупными элементами на следующем уровне, продолжая этот процесс до тех пор, пока части не будут интегрированы в законченное приложение сложных сервисов и отношений [1,с. 34].

Классификация сервисов осуществляется при идентификации сервисов. Очень важно начать классификацию сервиса в иерархии сервисов, отражая композитную или фрактальную их природу: сервисы могут и должны быть скомпонованы из более тонкоструктурных компонентов и сервисов [5, с.66]. Существуют следующие базовые категории сервиса:

1. Основные сервисы. Это сервисы, которые обеспечивают основные функции бизнеса, их нельзя разбивать на несколько сервисов. Как правило, эти сервисы предоставляют первый фундаментальный слой бизнеса. Есть два типа основных сервисов: сервисы для данных и сервисы для логики.
2. Составные сервисы. Это сервисы, у которых имеет доступ к нескольким серверам и, следовательно, они состоят из нескольких основных сервисов.
3. Сервисы процесса. Это сервисы, которые представляют собой долгосрочные рабочие процессы или бизнес-процессы.

Для анализа берутся подсистемы, найденные в результате декомпозиции домена, и определяются взаимозависимости и потоки данных между ними. Кроме того выявляются случаи использования, идентифицированные во время декомпозиции домена как раскрытые сервисы в интерфейсе подсистемы. Анализ подсистем заключается в создании моделей объекта для представления внутренних операций и конструкций подсистем, раскрывающих и анализирующих сервисы [4,с.70]. Проектная конструкция подсистемы впоследствии реализуется как конструкция реализации крупноструктурного компонента, реализующего сервисы в данной системе.

При спецификации компонента определяются следующие его детали, реализующего сервисы:

• данные;
• правила;
• функции;
• настраиваемые профили;
• вариации (возможно, полиморфизм).

Здесь также задаются спецификации обмена сообщениями, спецификации событий и дается определение управления.

Размещение сервисов заключается в распределении сервисов по подсистемам, которые уже были идентифицированы. В этих подсистемах присутствуют корпоративные компоненты, реализующие их опубликованную функциональность. Структурирующие компоненты появляются при использовании шаблонов для создания корпоративных компонентов в комбинации с [4, с.81]:

1. посредниками (медиаторами);
2. моделями представления (фасадами);
3. правилами;
4. настраиваемыми профилями;
5. реестрами служб.

Размещение сервиса заключается также в распределении сервисов и реализующих их компонентов по соответствующим уровням SОА. Такое размещение является ключевой задачей, требующей документирования и анализа основных архитектурных решений, относящихся не только к архитектуре приложения, но и к операционной архитектуре, разработанной и используемой для поддержки реализации SOА в процессе работы.

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

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

Сервис-ориентированная архитектура (SОА) состоит из семи основных «слоев» взаимодействия. Каждый слой является самодостаточным и способным общаться со слоями вокруг него для выполнения задач, поставленных клиентом. Семь слоев включают операционные системы, компоненты предприятия, сервисы, объединение бизнес-процессов, презентацию, интеграцию архитектуры и качества обслуживания.

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

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

Не все функциональные компоненты предприятие становится публично доступной для пользователей. Слой сервисов состоит из всех доступных сервисов. Они могут существовать отдельно или как композитный (составной) сервис.

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

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

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

Слой качества обслуживания предоставляет возможности для мониторинга и поддержки таких аспектов качества обслуживания, как обеспечение безопасности, производительности и доступности, и управления ими. Он является фоновым процессом, использующим механизмы запросов и ответов, а также инструменты, контролирующие общее состояние приложений SOА [1, с.78].

Чтобы архитектура стала ориентированной на сервисы, сами сервисы должны удовлетворять следующим критериям.

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

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

Сервисы автономны. Услуги должны действовать самостоятельно во всех аспектах, такие как развертывание, управление версиями и так далее. Сервисы должны быть изолированы и отделены друг от друга, чтобы сделать их автономными. Для достижения этого:

• Сервисы должны быть развернуты независимо от системы, в которой они используются.
• Контракты должны быть разработаны в предположении, что после опубликования они не могут быть изменены. Этот подход заставляет разработчиков предусмотреть гибкость в их схемы.
• Изолировать сервис от отказа, приняв пессимистический прогноз.

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

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

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

Список литературы:

1. Бертсекас Д., Галлагер Р. Сети передачи данных. — М.: Мир,2009.-544 с
2. Бутрименко A.B. Разработка и эксплуатация сетей ЭВМ. — М.:Финансы и статистика, 2011. — 256с.
3. Игнатьев В.М., Ларкин Е.В. Анализ производительности ЭВМ//Учеб. пособие,- Тула: ТулГТУ, 2009. -104 с.
4. Задков В.П., Пономарев Ю.В. Компьютер в эксперименте. Архитектура и программные средства систем автоматизации. — М.: Наука, 2002. -376с.
5. Ломов Б.Ф., Венда В.Ф., Забродин Ю.М. Психологические проблемы взаимной адаптации человека и машины в системах управления. М.:Наука,2005-320с.[schema type=»book» name=»ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ СЕРВИС – ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ» author=»Власенко Сергей Валерьевич, Лобейко Владимир Иванович» publisher=»БАСАРАНОВИЧ ЕКАТЕРИНА» pubdate=»2017-06-19″ edition=»ЕВРАЗИЙСКИЙ СОЮЗ УЧЕНЫХ_ 30.12.2014_12(09)» ebook=»yes» ]