Введение

Service Oriented Architecture. Основные положения. Понятие Сервиса

Изменения штата

Изменения ПО

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

Во всех организациях сотрудники продвигаются по служебной лестнице, переходят на другую работу или увольняются. Если это происходит в разгар работы по разработке ПО, то с уходом специалиста теряются не только технологические знания. Теряются также практические знания по разработке продуктов, на овладение которыми ушло много времени. Новые сотрудники, даже зная технологию, не смогут заниматься разработкой продукта без задокументированного процесса SCM. Таким образом, SCM является точкой отсчета и базой данных об истории разработки проекта. Благодаря SCM новый сотрудник может узнать, «как» идет процесс разработки в организации и «что нового» в проекте на конкретную дату.

Напомним определение программной архитектуры, которое будет использовано в этой главе.

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

Сервис-ориентированная архитектура основывается на 4 абстракциях [26]:

• Прикладной интерфейс (application frontend)
• Сервис (service)
• Репозиторий сервисов (service repository)
• Шина сервисов (service bus)

Несмотря на то что application frontend часто выступает в роли основного «владельца» бизнес процесса, именно сервис предоставляет ту бизнес функциональность, которую application frontend и другие сервисы могут использовать. Сервис состоит из реализации которая обеспечивает бизнес логику и данные; контракта на обслуживание, который определяет функциональность, использование и ограничения для клиентов сервиса; кроме того, сервис предоставляет интерфейс который экспортирует функциональность для использования вне сервиса. Репозиторий сервисов хранит индивидуальные контракты сервисов всей архитектуры SOA. Шина сервисов (service bus) обеспечивает взаимодействие сервисов и прикладных интерфейсов.

Ниже схематично представлен состав основных абстракций SOA.

Сервисы – это, как правило крупные, части функциональности системы, которые не имеют встроенных прямых вызовов между собой. Т.е. относительно независимы по реализации. Вместо прямых вызовов друг-друга, они общаются с помощью специально утверждённых протоколов.

Сервис-ориентированная архитектура – это архитектура, основывающаяся на четырёх основных абстракциях (application frontend, service, service repository и service bus). Сервис состоит из контракта, одного или нескольких интерфейсов и реализации.

Оркестратция (планирование, организация) – деятельность, выполняемая как экспертом в бизнес области, так и специальным ПО, направленная на выстраивание цепочки и условия вызова сервисов.

Сервис-ориентированная архитектура фокусируется на понятии бизнес инфраструктуры. Здесь, под понятием сервис, в первую очередь подразумевается бизнес сервис, такой как, например, резервирование авиабилета. Такой сервис предоставляет бизнес операции, такие как: получить резервирование, отменить резервирование или получить профиль заказчика. В противоположность бизнес сервисам, технические сервисы, такие как хранение данных (persistency), управление транзакциями, предоставляют такие операции как: начать транзакцию, сохранить данные и т.п. И хотя технические операции несомненно являются очень важными, они имею мало отношения к бизнес функциям системы и поэтому имеет смысл исключать их из рассмотрения бизнес архитектуры системы. Вообще говоря SOA должна позволять отделить бизнес архитектуру системы от её технических деталей, тем самым оставляя свободу реализации того или иного сервиса.

Application frontend – это тот компонент SOA, который предоставляет функциональность конечным потребителям. Тем не менее, всегда следует иметь ввиду, что именно сервисы представляют струкруру и архитектуру SOA системы. Сервисы часто остаются неизменными на протяжении многих лет, в то время как application frontend и свяи между сервисами могут изменяться достаточно гибко и часто. Как следствие – время жизни application frontend значительно короче чем service’а.