Из неопубликованного. Материал был написан в конце 2006-го года.
pdf версияНе секрет, что для разворачивания в компании более или менее полноценного OSS решения, состоящего из нескольких модулей, необходимы четкое видение задач и целей менеджментом компании на несколько лет вперед и немалые финансовые и человеческие ресурсы для осуществления этих задач. Представители компании ТехноСерв АС, опираясь на значительный опыт внедрений OSS модулей, выделили бы в качестве базового набора модулей следующую связку: Inventory, Fault Management, Performance Management, Service Provisioning. На сегодняшний день, указанными качествами обладают, в основном, компании, развивающие бизнес в области телекоммуникаций. К моменту внедрения OSS, традиционный программно-аппаратный комплекс оператора, как правило, уже включает биллинговую систему (возможно, не одну, а несколько), ERP-систему, систему документооборота, а также децентрализованную кусочную систему управления оборудованием, поставляемую непосредственно самим производителем. Все эти системы должны быть так или иначе интегрированы между собой, а изменения в них, при необходимости, должны вноситься «на лету». OSS модули, по своему назначению, обязаны взаимодействовать с указанным программно-аппаратным комплексом. Более того, каждый модуль комплексного OSS решения может быть от разных производителей, тем самым еще более усложняя интеграционную задачу. И в таком непростом IT-ландшафте переход к концепции SOA позволяет понизить сложность поставленной задачи, поскольку архитектура SOA является слабосвязанной. Но для того, чтобы воспользоваться преимуществами сервис-ориентированной архитектуры, необходимо четко понимать, что она из себя представляет, какие дополнительные требования за собой влечет, какие имеет ограничения.
Построение технологических систем на основе предоставления сервисов (услуг), конечно же, не является революционно новым архитектурным решением; в обыденной жизни мы все так или иначе пользуемся услугами различных компаний, будь то такси или же мобильный оператор. Однако, поскольку все эти веяния идут из сферы информационных технологий, то под сервисами и архитектурой, как правило, понимаются особенности построения приложений и протоколов обмена между различными модулями. Тогда возникает вполне резонный вопрос со стороны опытных разработчиков и архитекторов: «Что такого нового вы представляете, чего мы еще не видели?» И они, действительно, правы. Если ограничиваться только узкими рамками разработки программного обеспечения, то за последние 20-25 лет было сменено несколько парадигм построения приложений и способов модульных кросскоммуникаций. Аббревиатур много: OVL, RPC, COM\DCOM, CORBA, RMI, … и что дальше? Чем SOA (а в IT-домене это, как правило, трансформируется в понятие web-services) отличается от всего вышеуказанного? Чего ради делать такие огромные вложения в новую архитектурную концепцию? Для ответа на все эти вопросы, и еще некоторые другие, будет посвящена оставшаяся часть статьи.
Здесь не предполагается каких-либо частных откровений о SOA, все в рамках стандартов. В качестве базового документа воспользуемся [Reference Model for Service Oriented Architecture 1.0. OASIS Standard, 12.10.2006].
Определение: Сервис-ориентированная архитектура (SOA) является парадигмой для организации и использования распределенных мощностей по реализации различных задач. Причем эти мощности могут находиться в ведении различных функциональных подразделений.
Заметим, что в этом определении ничего не сказано, что это архитектура построения приложений или порталов. Определение носит общий характер и может описывать процессы даже не связанные с IT, например, доставка почты или же производство обуви. В общем случае субъекты (люди или организации) создают возможности для решения задач или же поддержки процессов, возникающих в ходе существования бизнеса. И вполне естественным является возможность использования этих возможностей как другими людьми из этой же компании, так и другими компаниями.
Парадигма SOA имеет 3 ключевых понятия: видимость (
visibility), взаимодействие (
interaction) и эффект (
effect).
Первое понятие, «
visibility», описывает принцип доступности информации о существующих возможностях и возникающих потребностях. Т.е. каждая компания\подразделение\человек etc. предоставляют информацию о том, какую задачу они могут выполнить, как быстро они смогут ее сделать, сколько это может стоить и другие параметры. Одовременно с этим доступна информация о потенциальных пользователях и их потребностях.
Второе понятие, «
interaction», описывает механизмы, которые предоставляет архитектура, для сопоставления возникающих потребностей с возможностями и наоборот.
Третье понятие, «
effect», означает, что в результате взаимодействия пользователя с поставщиком той или иной услуги должно произойти изменение в окружающей среде. Парадигма SOA не занимается описанием изменений в закрытой области (например, в рамках компании-поставщика услуги). Важным фактом является то, что эффект происходит в разделяемой или пограничной среде, доступ к которой, потенциально, могут получить и другие пользователи. Ключевой аспект во всех взаимодействиях – использование возможностей без знания о внутреннем устройстве компании, предоставляющих эту возможность.
Последний пункт, который требует детализации — понятие «сервис». Согласно словарному определению «Сервис — работа по удовлетворению чьих н. бытовых, текущих или постоянных нужд». В общепринятом же понимании, термин «сервис» является комбинацией следующих положений:
• Возможность выполнения работы для 3-го лица.
• Спецификация работы предлагаемой для выполнения 3-му лицу.
• Предложение выполнения работы для 3-го лица.
Такая концепция позволяет достаточно четко провести разделение между потенциальными возможностями и способностью воплотить эти возможности в нечто реальное. Потребности и возможности существуют независимо от парадигмы SOA, и их значение неизменно. А вот определение понятия «сервис» в рамках SOA незначительно трансформируется, формализуется и принимает вид: «Сервис — это механизм посредством которого происходит связка потребностей в выполнении тех или иных функций и возможностей эти функции выполнить».
Каковы же основные отличия концепции SOA от ранее предложенных парадигм? Наиболее показательным примером будет сравнение в тематике проектирования программных комплексов\программирования, как наиболее передовой сферы, воплощающей лучшие архитектурные подходы в числе первых. К настоящему моменту лидирующее положение во многих предметных областях заняла объектно-ориентированная парадигма программирования (OO). Очевидно, что наиболее показательным и ярким будет сравнении SOA и OO.
В отличие от парадигмы OO, фокусирующейся на инкапсуляции данных и методов для манипуляции этими данными в единый объект, выступающей в качестве законченной конструктивной единицы, в SOA фокусируется на решении конкретной бизнес-задачи или предоставлении бизнес-функции, т.е. осуществляется переход от предмета к действию, имеющему реальный эффект. Различие проявляется следующими способами:
• В парадигме OO методы намеренно объединяются с данными. В таком контексте методы манипулирования могут представляться как некие свойства объекта. В рамках концепции SOA методы (сервисы) могут рассматриваться как способах доступа к данным, но фактически, жесткая связь между данными и методами может отсутствовать. Более того, для конечного потребителя сервисов, информация о связи между различными данными и методами доступа вообще может быть недоступна.
• В рамках OO использование объектов (т.е. вызов методов) возможно только после создания конкретного экземпляра на основе предопределенного шаблона. В SOA возможно использование сервисов\служб как только они становятся доступны. При этом для конечного пользователя сервисов отпадает необходимость в заботе о создании, проверки, размещении и пр. соответствующих структур данных.
• Объект в концепции OO представляет собой изнутри простую структуру данных без какой-либо семантической информации. В концепции SOA четкое описание семантики является одним из фундаментальных требований.
Как OO так и SOA есть способ отображения объектов и методов реального мира в рамки создаваемой модели. Важнейшим моментом является правильное понимание и корректное использование парадигмы. Таким образом вопросы «Что есть сервис?» и «Что есть объект?» лишены смысла без координатной привязки. Все может быть представлено как сервисом так и объектом. Основное значение выбора парадигмы — создание более ясной и простой картины. SOA обеспечивает более надежный фундамент для построения крупномасштабных систем потому как предоставляет модели, наиболее приближенные к способу организации человеческой деятельности.
Каким же образом парадигма SOA отличается от других подходов к организации и структурированию IT средств? По существу, есть две области, в которых подход SOA отличается от существующих концепций и фреймворков, лежащих в основе распределенных систем.
Во-первых, SOA отражает реальность границ собственности, являющуюся одним из базовых принципов архитектуры и дизайна систем. Этот факт непреложным образом вытекает из основных концепций SOA: видимости (visibility), взаимодействия (interaction) и влияния (effect). Для того чтобы в полной мере нести ответственность за такие концепции как доверие (trust), бизнес транзакции (business transactions), полномочия (authority), делегирование (delegation) и т.д. — требуются дополнительные платформы (framework) и элементы архитектуры. В контексте SOA, они, вероятно, будут представлены в рамках
описаний и интерфейсов сервисов (служб). Существующие механизмы описаний и интерфейсов сервисов содержат в себе возможности для включения таких ссылок, и тем самым облегчают повторное использование внешних платформ (framework) и возможности взаимодействия систем, включенных в повторное использование.
Во-вторых, в парадигме SOA учтен печальный опыт по состыковке возможностей различных сервисных IT компаний и потребностей бизнеса. Так, два или более лица объединяются в контексте единого взаимодействия, подразумевающего обмен некими данными. Этот же принцип является основным при совершении торговых сделок в реальном мире. Таким образом, есть все предпосылки для предположения, что SOA будет успешно развиваться вне зависимости от существующих на рынке в данный момент услуг; технологии и концепции, заложенные в SOA, могут масштабироваться, следуя потребностям рынка.
Переход к сервис-ориентированной архитектуре следует воспринимать как неизбежную тенденцию. Многие крупнейшие производители программного обеспечения начали свое движение в этом направлении. В частности, компании Alcatel-Lucent, BEA, IBM и другие провозглашают переход к SOA как одно из приоритетнейших направлений. И это совершенно неудивительно, поскольку только за последние несколько лет рынке произошло значительное количество слияний. В частности, были объединены активы компании Cramer и Amdocs, Micromuse и IBM, MetaSolv и Oracle и пр… А объединение различных OSS-модулей под крылом одной компании воспринимается конечным заказчиком исключительно в одном ключе: «модули одного производителя обязаны иметь ‘out-of-the-box’ интеграцию». Но, поскольку, эти модули первоначально разрабатывались в различных коллективах, в различные моменты времени и с использованием различных архитектурных подходов, это высказывание не соответствует действительности. И в задачу производителя теперь входит создание механизмов интеграции приобретенных модулей, что, зачастую, является совсем нетривиальной задачей. И в этот момент, звезда «SOA» начинает сиять особенно ярко. Именно благодаря слабосвязанности архитектуры SOA, производители OSS продуктов получают возможность путем незначительных вложений (относительно стандартных методов разработки ПО) создать интегрированный комплекс.
Для корректности следует отметить, что при переходе к приземленным вопросам, например, к вопросам интеграции, терминология меняется. SOA является более философским термином, а для решения конкретных интеграционных задач используется инструментарий, именуемый Enterprise Service Bus (ESB). Enterprise Service Bus является брокером, поддерживающим вызов сервисов\служб в синхронном и асинхронном режимах. Она разрешает передачу данных и уведомлений о событиях между отдельными модулями или приложениями. ESB помогает потребителям найти провайдеров сервисов\служб и управляет деталями взаимодействия между ними, все в полном соответствии с концепцией SOA.
Как правило, потребители сервисов\служб сталкиваются с искусственным выбором между двумя стилями взаимодействия: синхронным или асинхронным. Синхронная ESB является шлюзом служб, который выступает как центральный координатор множества служб. Асинхронная ESB является шиной сообщений, чьи службы поддерживают также способности Web-служб к самоописанию и обнаруживаемости. Для разрешения этой дилеммы, ведущие производители ESB, такие как IBM (WebSphere), BEA (WebLogic), Oracle (Oracle ESB), включают в свои продукты поддержку обоих режимов и, фактически, могут предложить две модели вызова для одной и той же службы. В этом случае потребитель при запросе адреса службы сможет получить два варианта: один для синхронного режима, второй для асинхронного, что, несомненно, повышает гибкость ESB как интеграционного инструмента. Исходя из потребностей, потребитель сможет выбрать модель вызова, которая ему больше всего подходит. Важно отметить, что независимо от выбранной модели вызова, выполняться будет одна и та же служба, хотя конкретный экземпляр провайдера службы может при этом и отличаться.
Как обычно, каждое архитектурное решение имеет свои минусы. В случае с SOA уверенно можно сказать, что плюсов от перехода к SOA будет существенно больше, чем минусов. Поэтому только заострим внимание на ключевых технических моментах, которые должны быть детально проработаны до перехода на SOA. Если эти моменты оставить в тени, то переход к SOA может стать неоправданной тратой средств.
• Для реализации SOA в обязательном порядке потребуется модель сообщений для обмена информацией между модулями.
• Для получения выгоды использования SOA необходимо согласование стандартов сообщений большого числа разнородных систем, участвующих в интеграционном процессе.
• Отсутствие четкого долгосрочного планирования при интеграции может превратить механизм версионности сообщений, как раз и предназначенный для ослабления межмодульной связи, превратить в жесткую сцепку.
• Реализации могут зависеть от специфики используемой ESB.
• Требуется дополнительное программно-аппаратное обеспечение.
• Вводится очередной абстрактный уровень обработки и трансляции сообщений, со всеми вытекающими последствиями.
• ROI архитектурных решений с использованием SOA, как правило, начинает проявляться только при их тиражируемости.
• Для эффективного осуществления требуется наличие в компании четкой стратегии развития и определенной зрелости модели управления ИТ.
В заключение еще раз отметим, что в свете означенных тенденций, демистификации концепций, четкое и понятное формулирование целей, стандартизация подходов, существенно сокращают издержки перехода к системам, построенным с использованием парадигмы сервис-ориентированной архитектуры, и уменьшают риски возможных провалов.
