Введение в SOA. Часть 1. Проектирование информационных систем
В последнее время многие разработчики ПО все чаще при проектировании новых программных продуктов обращают внимание на сервисно-ориентированную архитектуру (SOA). Чем же привлекателен данный подход и какие преимущества он предоставляет? Попробуем разобраться.
Что такое SOA?
Наверняка вам уже приходилось сталкиваться с данной аббревиатурой, и вам хорошо известно, что за ней скрывается такое понятие, как Service-Oriented Architecture, или сервисно-ориентированная архитектура. Данная технология относится к обойме наиболее перспективных и эффективных способов построения как корпоративных, так и публичных информационных систем. К ней приковано внимание большого количества разработчиков по всему миру. Обратившись к Google Trends можно увидеть по динамике запросов устойчивый рост интереса пользователей к технологии SOA.
Google Trends – Динамика запросов по SOA
Крупнейшие ИT-корпорации выделяют огромные бюджеты на проведение исследований в данной области и на внедрение SOA в технологические и бизнес-процессы. Но, как и в случае других технологий, достичь наиболее эффективного использования сервисно-ориентированной архитектуры можно лишь разобравшись как в объективных причинах возникновения данного явления, так и в принципах ее внутренней организации, потенциальных возможностях и ограничениях.
Если не вдаваться в тонкости терминологии, то под сервисно-ориентированной архитектурой понимают такую организацию приложения, при которой информационные ресурсы доставляются потребителям посредством сетевых сервисов. Отсюда вытекают следующие важные свойства SOA: функционирование в сетевой среде, распределенность (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 (что обеспечило их одним весьма любопытным свойством, но об этом немного ниже). Некоторые из них имеют самое непосредственное отношение к SOA. Так, нотация 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. Безоговорочным же лидером в данной области многие эксперты заслуженно считают корпорацию IBM, предлагающую широкий спектр систем проектирования семейства Rational Software. Кстати, данное подразделение Голубого гиганта некогда являлось самостоятельной софтверной компанией, примечательной прежде всего своим значительным вкладом в развитие языка UML и создавшей первый программный продукт, предназначенный для UML-проектирования – Rational Rose – долгие годы являвшийся эталоном среди инструментов проектирования информационных систем. В числе сотрудников компании были главные идеологи UML – Гради Буч (Grady Booch) и Джеймс Рамбо (James Rumbaugh).
Основные игроки на рынке SOA
Здесь будет уместным сделать небольшое отступление и сказать несколько слов о компании IBM. Этот лидер ИТ-индустрии занимает ведущие позиции во многих секторах как производства ПО и аппаратной части, так и в научных исследованиях и экспериментальных разработках, связанных с самым широким спектром вопросов, затрагивающих в той или иной мере вопросы автоматизации бизнес-процессов. И среди такого разнообразия направлений деятельности компании сервисно-ориентированная архитектура входит в число приоритетных, в результате чего IBM принадлежит значительная доля рынка SOA.
Объединяя части в целое
Мы уже выяснили, что проектирование информационной системы заключается в выявлении ее структурных элементов и взаимосвязей между ними. Можно предположить, что число всевозможных кирпичиков, из которых строится программный продукт, достаточно велико, а уровень их детализации добавляет еще большей вариантности.
А про количество возможных сочетаний данных элементов и способов их взаимодействия друг с другом и говорить нечего. Но на самом деле существует ограниченное количество жизнеспособных и, что еще более важно, эффективных информационных систем, собранных из отдельных элементов в единое целое. Данные композиции представляют собой не что иное, как разновидности архитектуры ПО. И одной из первоочередных задач архитектора является выбор такой архитектуры для программного проекта, которая наиболее точно соответствует специфике проекта и особенностям его окружающей программной и бизнес-среды. Как уже было отмечено выше, наиболее востребованной является сервисно-ориентированная архитектура. Помимо SOA используются такие подходы к построению композиции программного продукта, как:
- клиент-серверная архитектура;
- архитектура распределенных вычислений (Distributed Computing);
- одноуровневая архитектура (Peer-to-Peer);
- система «классной доски» (Blackboard);
- архитектура неявных вызовов (Implicit Invocation);
- архитектура каналов и фильтров (Pipes and Filters);
- расширяемая архитектура (PlugIns);
- монолитная система (Monolithic System);
- древовидная архитектура (Three-Tier);
- структурированная архитектура (Structured);
- объектно-ориентированная архитектура;
- поисково-ориентированная архитектура (Search-Oriented).
Из представленного списка SOA является одной из самых молодых (самая «свежая» концепция – поисково-ориентированная архитектура, которая, впрочем, пока находится в стадии становления и не закреплена стандартами). Сказанное совсем не означает, что прочие подходы к построению архитектуры приложения устарели и больше нигде не используются – у каждой разновидности есть своя ниша, своя область применения, свои преимущества и недостатки. Но в то же время было бы неверным закрывать глаза на тот факт, что у каждой архитектуры из представленного списка был свой звездный час, когда именно она оказывалась наиболее востребованной. В настоящее время звездный час переживает SOA (не лишенная при этом недостатков и имеющая ограничения в вариантах использования, как и любая другая архитектура).
Рисуя дорожную карту
Мы выяснили, какую роль играет проектирование информационных систем в совокупном процессе создания программного проекта, а также то, как соотносятся между собой процесс проектирования программного продукта и его архитектура. Рассмотрели инструменты, имеющиеся в распоряжении архитектора и те разновидности архитектуры, которые могут быть использованы при проектировании. Еще раз повторюсь, что нет хороших и плохих архитектур –каждая из них, в том числе и SOA, имеет свою нишу эффективного использования. В следующих номерах журнала мы познакомимся с элементами сервисно-ориентированной архитектуры, с характеристиками Web-сервисов и имеющимся инструментарием по их разработке и внедрению, разберем конкретные примеры создания приложений в соответствии с идеологией SOA. А также узнаем об используемых при разработке Web-сервисов шаблонов проектирования и познакомимся с наиболее значимыми языками проектирования Web-сервисов и бизнес-процессов.
Программные продукты IBM Rational для проектирования
- IBM Rational Rose Data Modeler – визуальное моделирование систем и Round-Trip-разработка баз данных;
- IBM Rational Rose Developer for UNIX – визуальное моделирование систем для UNIX;
- IBM Rational Rose Technical Developer – визуальное моделирование обычных систем и систем реального времени на платформах UNIX и Windows;
- IBM Rational Rose XDE Developer for Java – интегрированное средство Round-Trip-разработки Java-приложений;
- IBM Rational Rose XDE Developer for Visual Studio – интегрированное средство Round-Trip-разработки приложений с использованием Visual Studio .Net;
- IBM Rational Rose XDE Developer – интегрированное средство Round-Trip-разработки Java и .Net приложений со средствами Runtime анализа;
- IBM Rational Rose XDE Modeler – визуальное моделирование без возможностей Round-Trip-разработки.
Типовые задачи и требования к архитектору программного обеспечения
Требования:
- высшее техническое образование;
- опыт проектирования и разработки программных решений;
- опыт разработки, оформления и сдачи проектной документации заказчикам;
- желателен опыт работы в проектах по внедрению решений в качестве архитектора, аналитика в области телекоммуникаций или безопасности;
- опыт работы с одним или несколькими продуктами линейки IBM (Lotus, Websphere, Tivoli, Rational, DB2);
- хорошие коммуникационные качества;
- знание английского языка (ведение переписки).
Ключевые обязанности:
- участие в проектах компании, ведение подпроектов на базе решений отдела;
- разработка архитектуры решений для проектов на базе продуктов линейки IBM Lotus, Websphere, Tivoli, Rational, DB2;
- участие в переговорах с заказчиком, презентация разработанных решений;
- подготовка спецификаций, концепций, технико-коммерческих предложений, другой проектной документации по сопровождаемым проектам;
- разработка типовых решений отдела, совместно с начальником отдела определение направлений развития отдела;
- консалтинг, подготовка и проведение обучения для коммерческих подразделений компании.
Условия:
- официальная заработная плата (3500–5000 долл.), медицинское обслуживание, повышение квалификации за счет компании;
- участие в крупных проектах;
- неограниченные возможности профессионального роста.
Типовые задачи и требования к Java архитектору
Обязанности:
- разработка и документирование архитектуры ПО и технического дизайна;
- управление командой разработчиков (около 10 человек) с полной ответственностью за техническую выработку;
- общение с клиентом (большей частью на уровне переписки);
- разработка критически важных компонентов;
- анализ программного кода.
Требования:
- опыт работы архитектором, опыт разработки архитектуры и технического дизайна для Enterprise-приложений. Успешный опыт управления командой. Уверенные знания в области объектно-ориентированного проектирования и шаблонов проектирования, хорошее знание UML;
- Java Web Development (JSP, Servlets, Web Services, JDBC, Junit);
- хорошее знание и опыт работы с сетевыми протоколами (TCP/IP, HTTP/S, SSL, IPSec, VPNs);
- Проектирование и разработка кроссплатформенных Web-приложений (HTML, DHTML, JavaScript, XML, CSS);
- Test-Driven-разработка, unit testing;
- понимание принципов управления кодом и владение соответствующим инструментарием (CVS/SVN, Ant, CruiseControl);
- опыт проектирования (ER-диаграммы) и разработки приложений с использованием реляционных БД;
- знание методологий разработки ПО (RUP, agile);
- опыт J2EE-разработки (EJB) – будет являться преимуществом.
Ссылки на основные SOA-стандарты
|
Обсуждение статьи
|
|
|
|
RE: Введение в SOA. Часть 1. Проектирование информационных систем
изнес-логика хранится на сервере приложений. Если нужно внести поправки в алгоритм какого-то отчета или расчета, например заработной платы, не требуется менять функции клиентских приложений, надо изменить один сервер приложений!
http://www.amerisleep.com/ |
|
|
Keywords: zPOSTz zCODEz z10132z
Для Авторов: edit  delete
Автор: Николай Байбородин
web site
Дата: 10.09.2009 11:33:13©
|
Архив номеров
