Назовите меня троллем, если хотите, но я серьезно - как точно новый тренд SOA отличается от архитектуры клиентского сервиса, которую я строил 15 лет назад? Я продолжаю слышать SOA, но я не вижу, как это отличается от того, что мы всегда делали. Назад 10 лет назад, у компании было несколько клиентов (на нескольких языках), которые говорили с одним и тем же сервисом. Это был не XML (это был двоичный протокол под названием Microsoft DCOM), и не было автоматического обнаружения через WSDL, но это нормально, так как чтение документов было так же просто. Наша система была даже "открытой" в том смысле, что мы ее достаточно документировали, чтобы третьи стороны могли говорить с нашими сервисами. Мы не были пионерами - каждая другая компания, которую я знала 10 лет назад, делала то же самое. Единственная разница, которую я вижу между тогда и сейчас, заключается в том, что теперь в Интернете есть одна служба, а 10 лет назад каждый клиент будет размещать свой экземпляр службы. Но это не проблема архитектуры, где физическая жизнь службы прозрачна для всех, кто пользуется службой.

Так что же такое SOA, которая отличается от того, что мы делали годами? Является ли SOA просто маркетинговым термином, представляющим собой наилучшую практику, которая на самом деле стала распространенной давным-давно? Или я немного упустил SOA, что отличается от того, что мы делали все это время?

10 ответов

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

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

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

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

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

Позвольте мне использовать знаменитого мальчика-бичевателя Integration Hell: Telco.

Вернувшись в 90-е годы, компании сотового телефона были в изобилии в моем районе, почти так же многочисленны, как и реселлеры на большие расстояния, которые стали возможными благодаря дерегулированию коммуникаций середины 90-х. Ну, время продолжается, и Bell Atlantic становится электростанцией Verizon и поглощает компанию после компании (и хотя бы одного Baby Bell). У каждой из этих компаний есть технологии на башнях, в коммутационном оборудовании, в биллинговых системах, которые ПОЛНОСТЬЮ несовместимы друг с другом.

Итак, компания уходит и говорит, хорошо, у нас есть эти модели для того, как мы занимаемся бизнесом, давайте дружеское, последовательное лицо на ВСЕХ наших технологиях в виде WSDL/SOAP/XSD - на каждом языке и в системе мы сегодня могут быть сопряжены с этим! Медленно, но верно, компания создает все системы, способные сообщать о возможностях, быть опрошенными для загрузки и выставления счетов, а также подвергать будущих виджетов использованию в манерах, которые еще не были учтены.

Любой может создать SOA-клиент. Любой, у кого есть wget и текстовый редактор. И каждый может анализировать результаты (XML).

Это принципиально отличается от прошлых клиент-серверных архитектур. На днях я просто поговорил с кем-то о взаимодействии систем Cobol и Smalltalk с архитектурой SOA. Это легкая проблема для решения. Скажите, вы можете сказать то же самое для своих систем DCOM.

SOA ничего, кроме способа дизайна , в котором модули взаимодействуют друг с другом через "сервисы". Это просто, и теперь следующий вопрос: что такое "сервис" и каково его отличие от обычного "метода"?

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

SOA не имеет ничего общего с конкретной технологией, это всего лишь особый способ проектирования.

Для меня сервис-ориентированная архитектура возникает, когда Enterprise хочет интегрировать выбор разрозненных приложений, которые относятся к общему домену, к набору совместимых сервисов, которые работают против одного источника данных.

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

Возможно, именно в "дорожной карте" для корпоративных возможностей или набора для каждого решения станет совместимым сервисом по мере завершения решений и ввода службы. Для этого, возможно, команды разработчиков будут применять модульный/компонентный подход к построению soluton (возможной службы), чтобы упростить включение решения в качестве службы в сервис-ориентированную архитектуру.

В случае, когда существующие острова программного обеспечения становятся интероперабельными службами в сервис-ориентированной архитектуре, подход позволяет программным элементам, которые могут быть распространены и могут быть записаны на разных языках, для связи через открытый API и/или общий протокол (например, вкус веб-службы) и общий формат данных (например, XML).

SOA - это подход или идея. Это не каркас или инструмент. Когда WDSL и EJB получают имя-падение, это часто забывается... так же, как идея SOA совсем не нова.

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

Аналогия: Игрушки строятся с использованием строительных блоков Lego.

Большинство ответов здесь, по-видимому, говорят о том, что SOA (Service Oriented architecture) относится к созданию приложения стандартизованным образом, чтобы другие приложения могли взаимодействовать с ним независимо от платформы.

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

Конечно, при разработке приложения вы не можете гарантировать, что он будет совместим с кросс-платформой. Возьмем, например, stock Trading systems . Они используют Fix protocol для передачи сообщений. Ожидаете ли вы теперь вернуть данные в формате XML, чтобы он мог быть так назван SOA-совместимым? Точно нет! SOA - это архитектурный подход, который может помочь вам decouple your application/services и позволить им взаимодействовать друг с другом. Магистраль SOA - это ESB (Enterprise Service Bus) , которая используется для передачи данных из одной службы в другую. Архитектура SOA должна заботиться о преобразованиях форматов. Например -

FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)

Эти модули преобразования обычно называются adapters и обычно являются частью пакета SOA. Для получения дополнительной информации обратитесь к другому ответу -

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

Превращение SOA из концепции в инструмент возможно только тогда, когда все заинтересованные стороны понимают принципы процессного подхода и готовы применять его в качестве основы для управления изменениями в компании.

Уже несколько лет в России, как и во всем мире, обсуждаются вопросы, связанные с применением принципов сервис-ориентированной архитектуры (Service Oriented Architecture, SOA). Многие производители информационных систем уже заявили о поддержке принципов SOA, но реализация этих принципов на практике пока ограничивается единичными случаями. Мы рассмотрим предпосылки появления SOA и основные требования, которые должна выполнить компания, чтобы успешно применять концепцию SOA в своей практике.

«Проблема в том, что в аббревиатуре SOA люди больше обращают внимание на «service oriented», нежели на «architecture». Однако именно архитектура и дисциплина могут помочь SOA принести реальный результат».

Джеймс Гавернор (James Governor), ведущий аналитик, компания Redmonk

Термин SOA пока что несет на себе сильный маркетинговый отпечаток, а для самого понятия SOA на сегодняшний день все еще существуют различные трактовки. Многие отождествляют SOA с технологией Web-сервисов или определенными информационными системами, например, системами для управления бизнес-процессами (Business Process Management, BPM). Но SOA — это не коробочный продукт или технология, а идеология информатизации бизнеса, основанная на процессном подходе и методологии управления бизнес-процессами BPM.

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

Можно сказать, что SOA — это развитие известных принципов структурного и объектно-ориентированного программирования: разработка элементарных стандартных процедур и функций, годных к многократному повторному использованию, но на новом витке. SOA требует перехода с уровня разработки, каталогизации и типизации отдельных детальных операций и алгоритмов на уровень бизнес-функций и бизнес-процессов. В случае использования SOA создание, внедрение или изменение бизнес-процесса представляет собой компоновку (оркестровку) ранее разработанных сервисов, предназначенных для автоматизации бизнес-функций.

Принципы SOA

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

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

Аналогичная ситуация складывается сейчас с информационными решениями. Многие уже поняли на своем опыте, что монолитные системы (ERP, CRM, SCM и т. д.) обладают двумя врожденными пороками: ограниченной гибкостью (не всегда позволяют внести требуемые изменения в необходимые сроки) и высокой стоимостью владения и внесения изменений. Эти два фактора критичны для современных компаний, работающих в высококонкурентном и динамичном мире, что заставляет их уделять пристальное внимание оптимизации в данной области.

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

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

Оценив сложившуюся маркетинговую ситуацию и потенциал SOA для бизнеса, ведущие поставщики информационных систем поспешили заявить о своей готовности к SOA. Не отставали здесь ни пресса, ни аналитики. Если вспомнить начало кампании в 2005 г., то все единодушно говорили о большом потенциале SOA, и как следствие в 2006-2007 гг. было начато множество пилотных проектов SOA. Затем появилась информация о первых результатах, первых трудностях и неудачах. Темпы развития рынка SOA оказались не столь высоки, как ожидалось. По данным аналитиков, 90% компаний, запустивших пилотные проекты, завязли в них.

Сегодняшний момент можно охарактеризовать как окончание первичной стадии завышенных ожиданий. Обсуждение идеологии SOA переходит к конструктивным вопросам, касающимся проблем интеграции и выработки единых стандартов.

Цели и средства внедрения SOA

Изначально при внедрении SOA ставятся следующие цели:

• сокращение времени адаптации сложных информационных систем к постоянно изменяющимся бизнес-процессам компании;
• снижение стоимости владения ИТ (Total Cost of Ownership, TCO) в масштабе времени — за счет сокращения затрат на проектирование, внедрение, документирование, внесение изменений и т. п.;
• систематизация компонентов ИТ-архитектуры и повышение степени интегрированности информационных систем компании.

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

Так какие же технологические средства необходимы для внедрения SOA? Для начала это инструментарий документирования бизнес-процессов, далее репозиторий — библиотека унифицированных сервисов, позволяющая быстро компоновать новые автоматизированные процессы, далее — технология перехода от описания бизнес-процессов и определения сервисов к их реализации, например, с возможностью генерации BPEL, и, наконец, среда вызова сервисов и выполнения бизнес-процессов (рис. 1).

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

Помимо перечисленного инструментария для применения SOA очень важно обеспечить правильное выделение сервисов (рис. 2). Если сервисов будет очень много, то требуемая типизация не будет достигнута, но если сервисы будут слишком высокоуровневыми, то их применение будет затруднено из-за специфических различий в бизнес-процессах. При этом, с одной стороны, размер сервиса не должен сдерживать изменения процесса, с другой — он должен быть таким, чтобы им можно было свободно оперировать на уровне изменяемых бизнес-процессов.

Таким образом, методология SOA предоставляет возможность стандартизации в той сфере, где ее катастрофически не хватает, что и позволяет найти «золотую середину» между типовыми процессами и специфическими требованиями бизнес-пользователей.

Условия успешного применения SOA

Несмотря на то что все ведущие вендоры ИТ-мира вписали в свои маркетинговые материалы аббревиатуру SOA, а заказчики все чаще требуют от внедренцев, чтобы ИТ-решение у них строилось с использованием принципов SOA, ясные и понятные цели SOA очень часто не достигаются. Причина в первую очередь кроется в низком уровне бизнес-культуры и процессной зрелости компаний. Поскольку SOA, как мы уже говорили, базируется на идеологии BPM, трудно поверить в «кусочное» внедрение SOA в какой-либо компании, разве что в узкотехнологическом аспекте — применении технологии Web-сервисов. Это подтверждается и опытом первых проектов SOA — многие из них, зайдя в тупик из-за непрозрачности ИТ-архитектуры и непонимания общей картины ИТ-поддержки бизнеса, вызвали к жизни проекты документирования и управления архитектурой предприятия (Enterprise Architecture, EA). И наоборот — успешные проекты описания архитектуры предприятия дали жизнь SOA-проектам, поскольку стало очевидно, в каких областях идеология SOA применима и может дать наибольший эффект.

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

Доходы будущих периодов

Этот тезис подтверждают и данные аналитиков: по прогнозу Aberdeen Group, в течение следующих пяти лет крупнейшие глобальные компании ожидают экономии до 53 трлн долл. за счет внедрения SOA. Эти данные заставляют задуматься над стратегическими вопросами применения SOA.

Еще один взаимосвязанный аспект и критический фактор успеха внедрения идеологии SOA — дисциплина. Нужно помнить, что переход от монолитных систем к приложениям на основе SOA на первый взгляд приносит больше свободы. Однако при слабой системе управления, низком уровне культуры управления проектами и изменениями в компании эта свобода грозит превратиться в анархию. Поэтому мало провозгласить SOA; нужно еще обеспечить диктатуру дисциплины во всех проектах, очень внимательно анализировать вопросы безопасности и интеграции данных.

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

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

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

Игнорирование перечисленных условий и требований, чрезмерное увлечение технологической стороной в ущерб процессной грозят привести к совершенно противоположным результатам:

• расширение, а не сужение, «зоопарка» информационных систем и приложений,
• снижение надежности поддержки бизнеса;
• повышение стоимости владения ИТ;
• и в конечном счете — дискредитация идеологии SOA как таковой.

Заключение

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

Уроки первых проектов позволяют утверждать, что:

• SOA требует присутствия процессного управления в компании;
• SOA может стать средством интеграции, но не панацеей от «зоопарка приложений»;
• SOA не снимает вопросов интеграции данных и обеспечения безопасности;
• SOA не только не отменяет, но, напротив, обостряет необходимость системного подхода, корпоративного управления знаниями, изменениями, процессами и проектами.

Не следует ждать немедленного сокращения времени внедрения и экономии от SOA: это «доходы будущих периодов», базирующиеся на предварительно созданной SOA-инфраструктуре и репозитории сервисов. Но если мы не хотим «остаться за бортом» и рассчитываем получить стратегические бизнес-преимущества, этим надо заниматься уже сейчас — потому что к 2010 г., согласно прогнозу аналитиков Gartner Group, по меньшей мере 65% больших компаний переведут более 35% своего портфеля приложений на SOA.

Андрей Коптелов , директор департамента развития и внедрения ИТ
Виктор Голубев , директор департамента продвижения продуктов и услуг компания «IDS Scheer Россия и страны СНГ»

Дословно SOA расшифровывается как service-oriented architecture (сервис-ориентированная архитектура).

В последнее время это стало эдаким buzzword, то есть отчасти модным словечком, отчасти термином специально произносимым произвести впечатление на окружающих.

Все крупнешие компание-производители программного обеспечиния (такие как IBM, BEA, Oracle) постоянно преподносят новости, которые так или иначе обыгрывают SOA. Большинство фирм-консалтеров и интеграторов различными способами информируют, что занимаются реализацией и внедрением сервис-ориентированной архитектуры у клиентов. Часто правда каждый понимает сервис-ориентированную архитекту́немного (или сильно) по своему.

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

Традиционные проблемы информационных систем

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

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

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

Определение SOA

По своей сути service-oriented architecture (SOA) не содержит новых революционных идей, а является обобщением лучших практик создания программно-информационных систем уровня предприятия и выше, она не привнесла ничего оригинального, но она служит квитэссенцией ведения интеграционных проектов.

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

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

SOA характеризуют следующие основные принципы, следование которым позволяет сказать является ли информационная система сервис-ориентированной или нет:

• сервисы как компоненты информационной системы, которые публикуют свои интерфейсы (контракты). Эти контракты являются независимыми от платформы, языка программирования, операционной системы и других технических особенностей реализации, сервисы взаимодействуют между собой и вспомогательными службами посредством открытых, широко используемых стандартов.
• каждый, составляющий информационную систему сервис реализует отдельную бизнес-функцию, которая является логически обособленной, повторяющейся задачей, являющейся составной частью бизнес-процесса предприятия.
• низкая связанность (loose coupling). Сервисы в системах, построенных на SOA могут быть реализованы в независимости от других служб системы, необходимо только знание интерфейса используемых сервисов.

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

Рассмотрим их немного подробнее.

Сервисы как компоненты информационной системы

Сервисом называется независимый программный компонент, выполняющий определенную задачу, такую как например «проверить кредитную карточку», не требующей для использования клиентами какой-то определенной программной технологии.

Использование открытых стандартов является важной характерной особенностью SOA. Это значительно уменьшает время подключения нового бизнес-сервиса к существующей системе, так же как и (что является часто крайне важным моментом для предприятий, имеющих богатые наработки за предыдущее время), при внедрении СОА, нет необходимости переписывать или просто отказываться от проверенных годами и действующих решений.

Выбор распределенной технологии играет существенную роль. Использование, например, SNA или DCOM в качестве средства общения сервисов накладывают такое ограничение, при котором все компоненты в системе обязаны использовать SNA или DCOM, что ограничивает применимость системы.

Когда же говорят том, что информационная система следует принципам СОА, то сервис, реализованный, например, на языке Java и работающий в EE контейнере должен быть применим для использования клиентами, реализованными в Windows среде и наоборот.

Сервис выполняет повторяющуюся бизнес функцию

Что такое сервис в контексте SOA? Является ли сервисом функция в приложении? Являются ли технические сервисы сервисами, о которых говорят, когда имеют в виду СОА? Все это важные и уместные вопросы. Сервисы в SOA реализуют повторяющиеся бизнес-функции, которые необходимы для организации согласованной работы сложных, состоящих из большого числа различных компонентов, приложений.

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

Таким образом функциональность используется многочисленными приложениями и существует возможность быстро и относительно просто изменить бизнес-логику, приспосабливая ее к постоянно меняющимся условиям рынка.

Причем изменения необходимо вносить только в один-единственный сервис, и сделанные изменения одновременно используются всеми клиентскими приложениями.

Это и является одним из главных достоинств SOA.

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

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

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

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

Низкая связанность (loose coupling)

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

Благодаря этой особенности также значительно облегчается внесение изменений в функциональность сервисов, поскольку это совершенно не затрагивает другие сервисы.

Благодаря низкой связанности значительно упрощается пошаговое создание корпоративной системы из-за отсутствия барьеров реализации функциональности сервиса за несколько итераций.

Возможность динамически подключать новые сервисы, также как и поиск этих сервисов клиентами является также одним из краеугольных принципов системы, построенной на основе service-oriented architecture.

Пример построенной на SOA информационной системы

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

Однако все-таки, наверное, имеет смысл рассмотреть, из каких компонент может состоять некая идеальная усредненная SOA система. Многие из предоставленных ниже этих составляющих частей настолько важны и объемны, что могут являться темами отдельного рассмотрения, здесь же эти компоненты будут предоставлены только для общего ознакомления.

Итак, основными компонентами (представлены на рисунке 1) являются сервисная шина предприятия (ESB), СОА реестр (SOA Registry), workflow engine, сервисный брокер (service broker), СОА супервизор (SOA supervisor) Все они играют собственную роль в системе, при этом взаимодействуя друг с другом.

Рисунок 1.

Сервисная шина предприятия (ESB):

В сервис-ориентированной архитектуре все различные части программного обеспечения общаются друг с другом, как правило, посылаю друг другу достаточно много сообщений. Эти сообщения должны быть доставлены быстро и доставка должна быть гарантирована.

Для передачи сообщений в SOA как правило используют сервисную шину предприятия (Enterprise Service Bus – ESB). Сервисная шина является настолько важной в СОА, что возможно представить, что сервис-ориентированная архитектура не может существовать без нее и, наоборот, наличие ее является достаточным условием для SOA. На самом деле можно построить основанную на сервис-ориентированной архитектуре систему без применения сервисной шины и ее наличие не гарантирует позиционирование системы как СОА.

Сервисная шина предприятия может быть представлена как отдельный уровень программного обеспечения, который совместно с корпоративной сетью обеспечивает гарантированный сервис отправки-приема сообщений, которые посылаются всеми остальными частями корпоративной системы.

СОА реестр (SOA Registry):

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

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

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

СОА реестр также хранит информацию каждого компонента.

Workflow engine:

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

Workflow engine это программный продукт, позволяющий соединить весь бизнес процесс в корпоративной информационной системе от начала до его завершения, система для воспроизведения потока работ по имеющейся модели.

При этом обработка данных на отдельных этапах осуществляется в различных независимых друг от друга приложениях, а функции организации процесса и связи различных подсистем реализует специализированная Workflow система.

Продукты, моделирующие бизнес процессы, существовали задолго до СОА, существует огромное количество предложений от различных поставщиков, часто специализирующихся в различных областях. Около 15 лет назад большинство из этим систем были связаны с системами документооборота. Сейчас же поставщики этих систем все более тяготеют к системам управления бизнес-процессами и административными регламентами (business process management system или просто BPM).

Cервисный брокер (service broker):

Сервисным брокером является служба, соединяющая различные сервисы вместе. Он получает всю необходимую информацию от СОА реестра (SOA Registry), что означает, что реестр и брокер должны работать координировано.

Рисунок 2.

На рисунке 2 представлено как в некоторой СОА системе сервисный брокер организовывает обработку заказов. Схема включает только 4 бизнес сервиса и workflow engine.

Стрелками изображены действия сервисного брокера, утолщенные линии изображают потоки запросов.

Последовательность действий может выглядеть следующим образом:

1. Пользователь входит в систему и запрашивает службу обработки заказов. Поскольку эта служба еще не запущена, сервисный брокер получает соответствующее уведомление и начинает свою работу
2. Сервисный брокер запрашивает у СОА реестра, что необходимо для запуска службы обработки заказов и возможно ли ее стартовать в настоящее время
3. Сервисный брокер проверяет, запущены ли 4 необходимых для службы обработки заказов бизнес-сервиса, если еще не запущены, то стартует их.
4. На основании полученной от реестра СОА сервисный брокер проверяет интерфейсы между бизнес компонентами. Эти компоненты можно затем соединить вместе для службы обработки заказов.
5. Сервисный брокер уведомляет бизнес компоненты, что они должны связаться с workflow engine для выполнения необходимой службы и бизнесс процесс начинает выполняться

Некоторые реализации сервисной шины предприятия (ESB) выполняют также функции сервисного брокера.

СОА супервизор (SOA supervisor):

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

Одна из основных задач СОА супервизора это отслеживать работу различных компонентов внутри СОА системы, оценивать корректность их функционирования, а также отслеживать запросы, посланные во внешние системы.

Трудно переоценить важность этого компонента.

Не секретом является тот факт, что для достижения определенного уровня перфоманса гораздо проще не использовать принцип низкой связанности, поскольку его реализация ведет к необходимости создания определенной инфраструктуры, которая несомненно налагает свой отпечаток на скорость выполнения.

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

Обзор терминологии SOA

Часть 1. Сервис, архитектура, управление и бизнес-термины

Бертран Портье (Bertrand Portier)
Опубликовано 25.06.2008

Серия контента:

Семантика важна в любой области, а особенно – в сервис-ориентированной архитектуре (Service-oriented architecture - SOA). Поскольку SOA связывает между собой команды и организации, согласованная терминология чрезвычайно важна. В этой серии статей мы проводим ознакомительный тур по SOA, определяя термины и стоящие за ними идеи. Здесь вы изучите терминологию, достаточную для общения в области SOA. Вы поймете, почему каждый из терминов важен для SOA, что он значит в данном контексте, с какими стандартами он связан и чем отличается от остальных терминов.

Организационное замечание

Перечисленные ниже термины не выстроены по алфавиту, равно как и по степени важности. Они организованы скорее в блочном стиле. Мы начинаем с "сервиса", поскольку это фундаментальное понятие в рамках SOA. На этом понятии мы строим определения таких терминов, как "архитектура", "управление" и "бизнес". Во многих случаях мы разбиваем объемные термины на их составные компоненты.

Сервис

Сервисы являются, несомненно, сердцем сервис-ориентированной архитектуры: сам термин сервис широко используется. Однако разные люди понимают его по-разному, а потому вопрос "Что такое сервис?" часто приводит к долгим спорам. Мне приходилось слышать, как люди разговаривают о бизнес-задачах, бизнес-сервисах, функциях приложений, технических сервисах и сервисах из области инфраструктуры. Позвольте, я дам вам определение, основанное на IBM Rational® Method Composer Plug-in for SOA Governance и на IBM Rational® Unified Process for Service-Oriented Architecture. Дополнительную информацию вы найдете в .

"Сервис – это видимый ресурс, выполняющий повторяющуюся задачу и описанный внешней инструкцией".

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

• Ориентация на бизнес : сервисы ориентируются не на возможности ИТ, а на нужды бизнеса. Ориентация сервисов на бизнес поддерживается анализом сервиса и техникой проектирования.
• Инструкции : сервисы самодостаточны и описываются в терминах интерфейсов, операций, семантики, динамических характеристик, политик и свойств сервиса.
• Повторное использование : повторное использование сервисов обеспечивается их модульным планированием.
• Соглашения : сервисные соглашения заключаются между сущностями, именуемыми поставщиками и пользователями. Эти соглашения основываются на сервисных инструкциях и не влияют на реализацию самих сервисов.
• Размещение и видимость : в течение своего жизненного цикла сервисы размещаются и становятся видимы благодаря сервисным метаданным, реестрам и хранилищам.
• Агрегация : на слабо связанных сервисах строятся объединяющие бизнес-процессы и сложные приложения для одного или нескольких предприятий.

Эти характеристики в совокупности показывают, что SOA имеет дело не только с "технологиями", но и с потребностями и нуждами бизнеса.

Также важно учитывать, что не все является сервисом. Есть такие ИТ-функции, которые размещать в качестве сервисов смысла нет. Такие аналитические техники, как IBM Service-Oriented Modeling and Architecture (SOMA), помогают определять соответствие сервисов перечисленным выше идеям. Все эти моменты (включая все выделенные термины из данного раздела) мы подробно рассмотрим в данной статье.

Архитектура

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

На форуме Open Group Architecture Forum (TOGAF) есть два определения архитектуры в зависимости от контекста:

1. "Формальное описание или подробный план системы на уровне компонентов для руководства в процессе ее создания.
2. Структура компонентов, их взаимосвязи, принципы и направления развития, определяющие их разработку и эволюцию."

Эти два определения критически важны для понимания "A" (архитектуры) из аббревиатуры SOA. Заглянув глубже, мы видим также, что архитектура необходима для следующего:

• Разработка и моделирование на разных уровнях абстракции
• Отделение инструкции от реализации
• Построение гибких систем
• Проверка на соответствие бизнес-требованиям
• Анализ объема изменений при появлении новых требований
• Проверка на соответствие правилам

Архитектура предприятия

Вот определение из Википедии:

"Архитектуру" можно отнести на уровень проектов, а "архитектуру предприятия" - на уровень организаций. Отметьте также упоминания о процессах, информационных системах, персонале, целях, стратегии и бизнес-ориентации ИТ.

Главная цель создания архитектуры предприятия – согласование бизнес-стратегии и вложений в сектор ИТ. Таким образом, архитектура предприятия позволяет от общей бизнес-стратегии перейти на уровень ниже, к лежащей в ее основе технологии."

Вы можете отнести "архитектуру" на уровень проектов, а "архитектуру предприятия" - на уровень организаций. Отметьте также упоминания о процессах, информационных системах, персонале, целях, стратегии и бизнес-ориентировке ИТ.

Сервис-ориентированная архитектура

Ориентация на сервисы

Как написано в техническом обзоре IBM SOA foundation, "... ориентация на сервисы – это путь интеграции бизнеса как набора связанных сервисов." Больше информации об IBM SOA foundation вы найдете в .

Ключевое слово здесь - "бизнес". Ориентация на сервисы, например, позволяет гибко реализовывать и связывать сервисами бизнес-процессы из одной отрасли бизнеса (ОБ), разных ОБ, а также с бизнес-партнерами.

Эталонная модель SOA foundation

IBM SOA foundation содержит эталонную модель SOA, показанную на рисунке 1, в которой отображены ключевые характеристики, необходимые для поддержки сервис-ориентированной архитектуры.

Поскольку сама модель сервис-ориентированная, она позволяет осуществлять постепенное принятие SOA при возникновении у бизнеса новых потребностей, начиная с маленьких проектов и со временем интегрируясь во всю организацию. Более подробную информацию о SOA foundation можно найти в .

Рисунок 1. Эталонная модель SOA foundation

Сервис-ориентированная архитектура

В IBM SOA foundation SOA определена следующим образом:

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

SOA обладает следующими характеристиками:

• Она улучшает взаимосвязь между архитектурой предприятия и бизнесом.
• Она позволяет из наборов интегрированных сервисов создавать сложные приложения.
• Она создает гибкие бизнес-процессы.

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

Структура решений SOA, показанная на рисунке 2, представляет собой эталонную модель SOA, отражающую концептуальное (высокоуровневое) устройство решений SOA.

Эта модель, иногда также называемая "многослойной архитектурой SOA", включает в себя такие слои и понятия, как бизнес-процесс, сервис, сервисный компонент, а также взаимосвязи между ними.

Она не зависит от технологий, на которых построена. Как вы увидите в разделе "Модельно-управляемая архитектура" (Model-Driven Architecture - MDA) во второй статье данной серии, это разделение важно.

Рисунок 2. Структура решений SOA

Структура состоит из 5 функциональных слоев (снизу вверх):

• Эксплуатационные системы : представляют существующие ИТ-решения, показывают ценность и важность вложений в ИТ для SOA и возможность их использования.
• Сервисные компоненты : реализуют сервисы, при этом могут использовать одно или более приложений с уровня эксплуатационных систем. Как вы видите из модели, у пользователей и бизнес-процессов, в отличие от сервисов, нет прямого доступа к компонентам. Существующие компоненты могут быть повторно использованы или, если они для этого подходят, внедрены в SOA.
• Сервисы : представляют размещенные в среде сервисы. Эти сервисы являются управляемыми видимыми сущностями.
• Бизнес-процесс : представляет операционные программы, создающие бизнес-процессы в виде хореографий сервисов.
• Пользователи : представляют каналы, используемые для доступа к бизнес-процессам, сервисам и приложениям.

Управление

Для успешного принятия SOA управление необходимо, в частности, из-за кросс-организационной природы SOA, где владельцы, разработчики, программисты, технический персонал и пользователи могут находиться в разных организациях, бизнесах, ИТ-департаментах, ОБ, отделах или департаментах.

Этот раздел содержит определения из IBM Rational Method Composer Plug-in for SOA Governance. Здесь определяются термины "управление", "ИТ-управление", "SOA-управление", а также определяется разница между управлением, руководством и соответствием. Тут же описываются проблемы, стоящие перед SOA-управлением. Более подробную информацию о Rational Method Composer вы найдете в .

Управление

"Под управлением мы подразумеваем:

• Установление цепочек ответственности, полномочий и связей, чтобы уполномочить людей (права на принятие решений)
• Установление механизмов для измерений, расчетов и контроля с тем, чтобы люди могли выполнять свои обязанности в рамках своей ответственности

Управление следит за назначением прав на принятие решений и решает, какими критериями и правилами руководствоваться при принятии этих решений. Правами на принятие решений наделяются определенные должности, а не личности. В отличие от управления, руководство включает назначение персонала на должности и слежение за исполнением правил.

Частью любого управленческого решения является соответствие организационным правилам соответствия. Соответствие - это документированное доказательство того, что управление имеется и реализуется: решения документируются, а правила принятия решений соблюдаются."

ИТ-управление

"ИТ-управление касается тех моментов управления, которые относятся к процессам в сфере информационных технологий в организации и того, насколько эти процессы соответствуют целям бизнеса."

ИТ-управление может быть описано как назначение прав на принятие решений и средств оценки ИТ-процессов.

SOA-управление

"SOA-управление – это надстройка над ИТ-управлением, ориентированная на сервисы и прочие продукты жизненного цикла SOA."

В частности, SOA-управление фокусируется на методах и процессах, касающихся идентификации сервисов, финансирования, прав собственности, разработки, программирования, размещения, повторного использования, обнаружения, доступа, мониторинга, руководства и изъятия из обращения.

"SOA-управление предназначено для решения следующих проблем:

• Какие новые организационные должности и структуры нужны для идентификации, разработки и совместного использования сервисов?
• Какие метрики поддерживают вложение средств, обслуживание, жизнеспособность и совместное использование сервисов?
• Как бизнесу решить вопрос об инвестициях в создание и обслуживание сервисов?
• Что такое зрелость производства в области сервис-ориентированности?
• Какие необходимы образование, обучение или наставничество?"

Жизненный цикл

Жизненный цикл сервиса

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

Во время своих "жизней" сервисы проходят через многие этапы и фазы (как и мы;-)). Можно представить себе жизненный цикл сервисов как бизнес-машину с состояниями (позициями), в которых могут пребывать сервисы, и переходами, которые переводят сервисы из одного состояния в другое.

SOA-управление имеет дело с планированием, определением, разрешением и измерениями на протяжении жизненного цикла сервисов. SOA-управление определяет, какие должны быть сервисные состояния, какие действия должны совершаться для перемещения из состояния в состояние (переходы), как (процессы и методы) и кем (должности, контролеры).

Например, SOA-управление может определять следующие сервисные состояния: идентифицированное, профинансированное, специфицированное, запрограммированное, одобренное, рабочее, опубликованное, одобренное к изъятию, изъятое.

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

В определении жизненного цикла SOA IBM SOA foundation отмечает четыре фазы:

• Модель состоит из бизнес-анализа и разработки (требования, процессы, цели, ключевые показатели продуктивности) и ИТ-анализа и разработки (определение и спецификация сервисов).
• Сборка состоит из программирования сервисов и построения сложных приложений.
• Размещение состоит из размещения приложений и средств времени исполнения, таких как Enterprise Service Buses (ESB).
• Руководство состоит из поддержки операционной среды, мониторинга производительности сервисов и слежения за соблюдением сервисных политик.

Определенные выше SOA-управление и процессы поддерживают эти четыре фазы. Это отображено на рисунке 3.

Рисунок 3. Жизненный цикл SOA

Бизнес

В наши дни компаниям необходима способность быстро обнаруживать и реагировать на перемены, в то же время поддерживая свои экосистемы из работников, партнеров и клиентов. В IBM On Demand Business описано, что для этого технологии должны использоваться по максимуму. Информацию о IBM On Demand Business вы найдете в .

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

Ориентация на бизнес

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

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

Компонентное представление бизнеса

сайтponent Business Model® - стратегический метод, позволяющий компаниям фокусироваться на своих ключевых сферах деятельности – на том, чем компания отличается от своих конкурентов, на отслеживании потребления ресурсов и установлении лучшей связи бизнеса со сферой ИТ. В вы найдете дополнительную информацию о Component Business Model. С помощью и благодаря ориентации на сервисы достигается интеграция и взаимодействие этих компонентов бизнеса, а также гибкость, благодаря которой можно проводить аутсорсинг компонентов: у каждого из компонентов бизнеса есть своя уникальная цель, а сообщаются они между собой посредством набора бизнес-сервисов, которые они поставляют другим компонентам либо получают от других компонентов. Это можно рассматривать как часть "бизнес-архитектуры".

Бизнес-моделирование

Бизнес-моделирование определяется IBM Rational Unified Process® следующим образом:

"Дисциплина Rational Unified Process Business Modeling предоставляет точное руководство для описания с помощью набора подходов и техник, на разных уровнях формализации "текущего" или "желаемого" бизнеса".

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

SOA – долговременная стратегия реорганизации бизнеса и ИТ-систем, цель которой - быстрое реагирование на перемены. В есть ссылка на журнал IBM Systems (том 44, номер 4), рассказывающий о SOA, в котором вы найдете более подробное рассмотрение связанных с бизнесом сторон сервис-ориентированного мышления.

Бизнес-процесс

Бизнес-процесс – это последовательность действий, дающая полезный результат.

Бизнес-процесс включает в себя протекающие сквозь него связанные бизнес-элементы (данные), в том числе входящие и исходящие данные процесса.

Бизнес-деятельность и задачи

Бизнес-деятельность и задачи – это элементы, которые, будучи связаны, образуют бизнес-процессы.

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

Моделирование бизнес-процессов

"Существующие" бизнес-процессы в организации могут быть сложны, поскольку они часто являются результатом многочисленных изменений, внесенных в изначальный процесс. Жизненно важными требованиями являются понимание, формальное определение и документирование бизнес-процессов. Кроме того, моделирование и имитация "существующих" и "желаемых" (будущих) бизнес-процессов позволяет определиться с затратами, временными задержками и областями, подлежащими автоматизации.

Моделирование бизнес-процессов дает не только визуальное представление, но и позволяет позже связать элементы модели бизнес-процесса с элементами ИТ – в том случае, если осуществляется в инфраструктуре, которая работает с лежащими в основе процессов метаданными.

Задачи для людей

Довольно часто в процессах требуется человеческое вмешательство (например, утверждение командировки или кредита). Такие задачи при моделировании бизнес-процесса определяются как ручные, и для каждой задачи назначается определенная роль. После размещения для выполнения процессов SOA потребуется поддержка задач, выполняемых людьми. Такие продукты, как, например, IBM WebSphere Process Server, предоставляют пользователям списки ожидающих их задач для людей. При их комбинировании с такими продуктами, как IBM WebSphere Portal и Lotus Sametime, пользователи также могут сотрудничать между собой и оповещать систему о принятых ими решениях, чтобы система могла продолжать выполнение процессов. Этот человеческий фактор критически важен для успеха SOA.

BPEL

IBM, Microsoft и другие компании участвовали в разработке языка Business Process Execution Language (BPEL) for Web services specification (язык выполнения бизнес-процессов для создания спецификаций Web-сервисов), являющегося средством формального описания бизнес-процессов и протоколов взаимодействия.

Отрасли

В разных сферах деятельности и отраслях бизнес-процессы могут иметь свою специфику, как, например, в страховании. Отраслевые бизнес-процессы определяются промышленными консорциумами. Например, TeleManagement Forum определяет enhanced Telecom Operations Map (eTOM) для телекоммуникационной отрасли. Кроме того, компании, чтобы выделиться среди конкурентов, могут внедрять свои собственные бизнес-процессы, основанные на проверенных моделях, таких как IBM Industry Models. В приведена ссылка на IBM Insurance Application Architecture (IAA), которая является примером IBM Industry Models.

Управление бизнес-процессами

Управление бизнес-процессами (Business Process Management - BPM) занимается полным жизненным циклом бизнес-процессов с целью повышения их эффективности, гибкости и управляемости.

BPM проводит моделирование, симулирование, оптимизацию, размещение, прогонку, руководство и мониторинг бизнес-процессов, после чего выдает нужные для улучшения моделей результаты и опять начинает цикл усовершенствований. Вместе с IBM WebSphere поставляется набор разнообразных необходимых для BPM продуктов.

Заключение

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

Благодарности

Я хотел бы поблагодарить моих коллег из IBM, которые внесли большой вклад в сервис-ориентированную архитектуру и описанные в статье идеи. Особую благодарность выражаю Ричарду Джонсону (Richard D. Johnson) и Стиву Киндеру (Steve Kinder) за рецензию на эту статью.