Проектирование информационных систем

В последнее время многие разработчики программного обеспечения все чаще при проектировании новых программных продуктов обращают внимание на сервисно-ориентированную архитектуру (SOA). Чем же привлекателен данный подход к разработке ПО и какие преимущества он предоставляет? Попробуем разобраться.

Что такое SOA?

Наверняка вам уже приходилось сталкиваться с данной аббревиатурой, и вам хорошо известно, что за ней скрывается такое понятие, как Service-Oriented Architecture, или Сервисно-ориентированная архитектура. Данная технология относится к обойме наиболее перспективных и эффективных способов построения как корпоративных, так и публичных информационных систем. К ней приковано внимание большого количества разработчиков по всему миру. Обратившись к Google Trends можно увидеть по динамике запросов устойчивый рост интереса пользователей к технологии SOA.
 
Крупнейшие IT корпорации выделяют огромные бюджеты на проведение исследований в данной области и на внедрение SOA в технологические и бизнес-процессы. Но, так же, как и любые другие технологии, сервисно-ориентированная архитектура для наиболее эффективного ее использования требует глубокого понимания как объективных причин появления данного явления, так и принципов ее внутренней организации, потенциальных возможностей и ограничений.
Если не вдаваться в тонкости терминологии, то под «сервисно-ориентированной архитектурой» понимают такую организацию приложения, при которой информационные ресурсы доставляются потребителям посредством сетевых сервисов. Отсюда вытекают следующие важные свойства сервисно-ориентированной архитектуры: функционирование в сетевой среде, распределенность (SOA приложение в отличие от традиционных программных продуктов может состоять из отдельных модулей, функционирующих независимо друг от друга, зачастую находящихся на разных серверных платформах и взаимодействующих друг с другом посредством одного из SOA ориентированных протоколов) и функционирование в соответствии со схемой «запрос – ответ». Последнее свойство указывает на родство между сервисно-ориентированной архитектурой и технологией «клиент – сервер». Функционирование SOA в сетевой среде предполагает использование определенного набора сетевых протоколов как для организации взаимодействия элементов системы, так и для обмена информацией со внешней средой. Для этого могут использоваться как традиционные протоколы из стека TCP/IP, так и работающие поверх него специализированные протоколы, разработанные специально для организации сетевой инфраструктуры SOA. К таким протоколам относятся, прежде всего, SOAP (Simple Object Access Protocol)и REST (Representational State Transfer).
Однако, перечисленные характерные признаки SOA не раскрывают до конца всех особенностей этой технологии. Следовательно, для того, чтобы разбираться в тонкостях SOA, для того, чтобы знать о ее возможностях и ограничениях, необходимо понять и принять философию и генезис SOA.

Архитектура программного обеспечения

Из самого термина «сервисно-ориентированная архитектура» видно, что это прежде всего одна из разновидностей архитектуры программного обеспечения. Под архитектурой программного обеспечения, в свою очередь понимается способ построения, композиции законченного программного продукта из отдельных логических или функциональных модулей. Приходящая многим в голову аналогия со строительной архитектурой является весьма удачной – любое здание представляет собой некую строго организованную систему, состоящую из отдельный элементов, причем список этих элементов зависит от выбранного нами уровня детализации (либо фундамент, стены, двери, окна, крыша; либо кирпичи, стеновые блоки, плиты перекрытия и так далее). Так и в любом программном продукте можно выделить набор «кирпичиков», из которых складывается готовый продукт. Далее, существуют определенные законы, которые необходимо соблюдать при строительстве здания. Причем, это как естественные законы природы (например, закон всемирного тяготения не позволяет экономить на цементе, без которого вся конструкция неизбежно развалится и рухнет на землю), так и законы, установленные общественными институтами (например, запрет на использование вредных для здоровья строительных материалов). Кроме законов приходится считаться еще и пожеланиями заказчика (например, выкрасить стены дома в радикально красный цвет, идеально подходящий к цвету галстука будущего хозяина).
То же самое происходит и в сфере разработки программного обеспечения. Есть определенные правила построения программного кода и организации взаимодействия отдельных его элементов (обусловленные аппаратной платформой и используемыми технологиями). Есть требования, предъявляемые к программному обеспечению корпоративный, отраслевыми, государственными и межгосударственными стандартами. И, наконец, есть требования, изначально предъявляемые заказчиком программного обеспечения. Все эти факторы приходится учитывать при проектировании практически любого программного продукта.
Итак, можно сказать, что архитектура программного продукта — это некоторое видение того, из каких элементов будет состоять приложение, и каким образом они будут взаимодействовать друг с другом. Вернемся к примеру с проектированием здания. Архитектура здания может храниться в голове создавшего ее человека, что конечно же, по ряду очевидных причин, является не самым лучшим решением. Или же, может быть облачена в материальный вид, например, на листе ватмана. Такое материализованное видение будущей системы называют проектом. Процесс разработки программного обеспечения аналогичным образом начинается с проектирования, а законченная композиция из элементов информационной системы и описания их взаимодействия называется программным проектом. Кстати, как проектирование строительных сооружений занимается архитектор, так и проектирование программных продуктов осуществляет Архитектор программного обеспечения (Software Designer) – одна из ключевых фигур в процессе разработки информационных систем.

Кульман, ватман и другие

При создании чертежа здания архитектор придерживается однозначно трактуемого стандартного стиля оформления. Определенные элементы он оформляет линями строго заданного начертания и толщины, использует условные обозначения. Другими словами, есть некая система кодирования информации, которую архитектор использует в своей работе. Такая система однозначного кодирования информации (в данном контексте информация понимается в самим широком смысле, включая строительный чертеж, древний наскальный рисунок или листинг программы)называется языком.
В расположении архитектора программного обеспечения также имеются средства кодирования информации, то есть языки проектирования, позволяющие создать строго формализированное описание информационной системы. Пожалуй, самым распространенным языком проектирования является UML. Но, кроме UML при проектировании информационных систем широко используются и другие нотации, большинство из которых являются прямыми потомками языка UML, или подмножествами XML (что обеспечило их одним весьма любопытным свойством, но об этом немного ниже). Некоторые из них имеют самое непосредственное отношение к сервисно-ориентированной архитектуре. Так, нотация WSDL (Web Services Description Language, или язык описания Web сервисов)используется, как видно из его названия, для проектирования структуры и функциональных возможностей web служб. Нотация BPEL (Business Process Execution Language)предназначен для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL как бы расширяет модель взаимодействия web служб, делая ее подходящей для проектирования бизнес-процессов. RDF (Resource Description Framework) – созданная при поддержке консорциума W3C модель для описания как доступных через web интерфейс ресурсов, так и метаданных об этих ресурсах.
Перечисленные нотации являются подмножествами XML, и, следовательно, способны не только описывать структуру некоторой системы, но и нести в себе некоторую полезную информацию, являющуюся частью самой системы. Благодаря такой возможности, размываются границы между проектированием и разработкой системы. То есть, некоторая сервисно-ориентированная архитектура, описанная в формате одной из перечисленных нотаций (за исключением UML), представляет собой не просто проект, но с определенными допущениями, готовую, способную к функционированию систему! Так, бизнес-процессы проекта, описанные с помощью нотации BPEL могут быть запущены на выполнение с помощью ряда Framework'ов.
Другие графические нотации более традиционны и более близки языку UML, будучи предназначенными только для проектирования. К таковым относится, прежде всего, семейство нотаций IDEF, а так же такие системы, как DFD (Data Flow Diagrams), ERD, STD, SADT. Каждая из этих систем предназначена для решения определенного круга задач в проектировании программного обеспечения и заслуживает отдельного рассмотрения. К некоторым из них, я надеюсь, мы вернемся в дальнейшем, посвятив им отдельные статьи.
Снова вернемся к строительству здания. Эффективность работы архитектора во многом зависит от того, как организована его деятельность, какие инструменты он использует в своей работе. С большой долей вероятности можно утверждать, что эффективность труда архитектора, использующего ту или иную CAD/CAM систему будет значительно выше, чем эффективность труда архитектора, рисующего чертежи будущего здания по старинке карандашами и тушью на листе ватмана. Проектирование информационных систем в общем, и SOA приложений, в частности, аналогичным образом будет более эффективным при использовании соответствующего инструментария. Системы проектирования программного обеспечения разрабатываются многими ведущими вендорами, зачастую являясь составной частью системы RAD.

Объединяя части в целое

Мы уже выяснили, что проектирование информационной системы заключается в выявлении ее структурных элементов и взаимосвязей между ними. Можно предположить, что количество всевозможных кирпичиков, из которых строится программный продукт, достаточно велико, а уровень их детализации добавляет еще большей вариантности. А про количество возможных сочетаний данных элементов и способов их взаимодействия друг с другом и говорить нечего. Но, на самом деле, существует ограниченное количество жизнеспособных, и, что еще более важно, эффективных композиций отдельных элементов информационной системы в единое целое. Данные композиции представляют собой ничто иное, как разновидности архитектуры программного обеспечения. И одной из первоочередных задач архитектора является выбор такой архитектуры для программного проекта, которая наиболее точно соответствует специфике проекта и особенностям его окружающей программной и бизнес-среды. Как уже было отмечено выше, одной из наиболее востребованных является сервисно-ориентированная архитектура (SOA). Помимо сервисно-ориентированной архитектуры используются такие подходы к построению композиции программного продукта, как:

• клиент-серверная архитектура
• архитектура распределенных вычислений (Distributed Computing)
• одноуровневая архитектура (Peer-to-peer)
• система «классной доски» (Blackboard)
• архитектура неявных вызовов (Implicit invocation)
• архитектура каналов и фильтров (Pipes and filters)
• расширяемая архитектура (PlugIns)
• монолитная система (Monolithic System)
• Древовидная архитектура (Three-tier)
• Структурированная архитектура (Structured)
• Объектно-ориентированная архитектура
• Сервисно-ориентированная архитектура
• Поисково-ориентированная архитектура (Search-oriented)

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

Рисуя дорожную карту

Мы выяснили, какую роль играет проектирование информационных систем в совокупном процессе создания программного проекта, а так же то, как соотносятся между собой процесс проектирования программного продукта и его архитектура. Рассмотрели инструменты, имеющиеся в распоряжении архитектора и те разновидности архитектуры, которые могут быть использованы при проектировании. Еще раз повторюсь, что нет хороших и плохих архитектур – для каждой из них, в том числе, и для SOA существует своя ниша эффективного использования. В следующих номерах журнала мы познакомимся с элементами сервисно-ориентированной архитектуры, с характеристиками web сервисов и имеющимся инструментарием по их разработке и внедрению, разберем конкретные примеры создания приложений в соответствии с идеологией SOA. А также узнаем о используемых при разработке web-сервисов шаблонов проектирования и познакомимся с наиболее значимыми языками проектирования web-сервисов и бизнес-процессов.
И, конечно же, какой толк от теории без практики. Мы рассмотрим предлагаемые платформой Microsoft .Net возможности для создания распределенных приложений на основе сервисно-ориентированной архитектуры. Забегая вперед, скажу, что возможности эти весьма впечатляют, включая в себя весь стек необходимых технологий, начиная от WCF и заканчивая MS BizTalk Server.