Почему мы так часто заблуждаемся насчет SOA? Этот вопрос не дает покоя Дэвиду Линтикуму, известному эксперту в области SOA и интеграции приложений. «Возможно, дело в многочисленных вендорах, пытающихся урвать свой куш в данной области и использующих для этой цели разнообразные и противоречивые маркетинговые кампании, сбивающие потребителя с толку, а может быть, всему виной ИТ-пресса, ненадлежащим образом информирующая потенциально заинтересованного клиента и породившая в его голове массу заблуждений… Так или иначе, неверные представления о SOA уже сложились, и пришло время их опровергнуть», - так решительно рассуждает Дэвид и отвечает категорическое «нет» на семь, с его точки зрения, самых распространенных заблуждений.

Заблуждение номер один: сервис-ориентированные архитектуры – это новая, доселе неизвестная концепция.

Нет, это не совсем так. Попытки создать решения и технологии, которые позволяли бы совместно использовать функциональное поведение, или сервисы, были предприняты давно, ведь в организациях давно уже используется более одного компьютера. Удаленные вызовы процедур (Remote Procedure Call, RPC) были первой попыткой создать архитектуру подобного рода. Затем появились методы межпроцессного взаимодействия (Inter-process communication, IPC), а потом – и более сложные технологии, такие как распределенные объекты вроде COM и CORBA. На сегодняшний день SOA-архитектуры строятся в основном на базе Web-сервисов. Web-сервисы – это новый стандарт, но функционирует он, по большому счету, по тому же принципу, что и привычные нам «распределенные» объекты. Таким образом, мы не стали свидетелями революционного прорыва в лице SOA, наоборот, SOA – это закономерный результат эволюционного развития архитектур и технологий.

Заблуждение номер два: для того чтобы построить SOA, нужны Web-сервисы.

Нет, это не так. Web-сервисы – это только один из доступных стандартов, использующихся во многих SOA-архитектурах. Вы можете построить свою SOA-архитектуру на основе технологий, использующих другие стандарты, такие как CORBA, COM, J2EE и другие. Теперь SOA можно построить даже на базе проприетарных технологий. Помните, что SOA – это архитектура! Нет универсальной SOA, которая бы подходила всем, вы должны применять те технологии, которые подходят именно вам и позволяют решать именно ваши задачи.

Заблуждение номер три: если вы приобрели дорогую ESB, то SOA уже у вас в кармане.

Нет, это не совсем так. ESB, или корпоративная сервисная шина, - это действительно очень замечательная и прогрессивная технология, поскольку позволяет передавать информацию в приложения и позволяет приложениям обмениваться информацией. И все это осуществляется через интерфейсы Web-сервисов. Но, тем не менее, ESB – это всего лишь одно решение из многих, и прежде чем приобретать ее, необходимо тщательно проанализировать те задачи, которые вы намереваетесь решить с помощью вашей SOA-архитектуры. Может оказаться, что другие технологии более эффективны для решения ваших задач. Так что не спешите приобретать кота в мешке, присмотритесь получше к каждому котенку в коробке, ведь именно он должен первым войти в ваш новый дом. И помните, готовая технология, которую вы приобретаете – это только часть SOA, а не готовая SOA. Котенок – это всего лишь один из обитателей дома, символ очага, а не сам очаг. Но без него – и очаг не очаг.

Заблуждение номер четыре: SOA-архитектуры, как правило, хорошо масштабируемы.

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

Заблуждение номер пять: SOA нужна всем, ее внедрение всегда оправдано.

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

Заблуждение номер шесть: при построении SOA следует пользоваться услугами только одного поставщика.

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

Заблуждение номер семь: главное – выбрать технологию и поставщика и уже исходя из этого, приниматься за построение SOA-архитектуры.

Категорическое «нет»! Сначала надо проанализировать свои требования, какие задачи вы хотите решить в первую очередь, т.е. рассмотреть проблему на бизнес-уровне и только потом можно переходить к проектированию системы. Рассмотреть проблему на бизнес-уровне означает понять семантику, изучить вопросы обеспечения целостности и безопасности, разобраться в сервисах, уже имеющихся на предприятии, и в том, какие именно новые сервисы нужно создать, и еще многое и многое другое. И только после того, как проделан весь этот огромный фронт работ на бизнес-уровне, можно обратиться к технической стороне дела. И не забудьте о такой «мелочи» при покупке технологии, как концептуальное тестирование, дабы убедиться в правильности выбора технологии, прежде чем выписать чек на оплату.

По материалам блога Real World SOA

Комментарии