Организация сети в SOA

Автор: Daniel Minoli
Перевод: Крук О.А.
Источник: Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and Infrastructure Technology

XML и SOAP обмен сообщений

XML и SOA обмен сообщений в контексте SNAF ограничен по сути, потому что наш центр области находится в верхних уровнях стека.

XML - обмен сообщений

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

Основы SOAP обмен сообщений

SOAP - обмен сообщений стал ведущим стандартом для использования с WS и был принят MOM-производителем в дополнение к другим протоколам.

SOAP представляет собой легкий протокол для обмена на основе XML информации в распределенных средах и предназначен для разрешения явным посредникам выполнять обработку от имени службы компонентов в SOA

Репрезентативная форма передачи (REST)

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

REST архитектуры веб-служб соответствует W3C Web-архитектуре и использует архитектурные принципы веб в свою пользу, строит свою силу на проверенной инфраструктуре веб. Он использует семантику HTTP когда это возможно и большинство принципов, ограничений, и лучшие практики, опубликованные W3C технической архитектурной группой (ТАG).

Термин REST впервые был введен Рой Филдингом для описания веб-архитектуры. Веб-служба REST в SOA основывается на концепции "ресурс". Ресурс - все, что имеет Universal Resource Identifier (URI). Ресурс может иметь ноль или больше представлений. Обычно, люди говорят, что ресурс не существует, если представление не для этого ресурса. Веб-службы REST требуют следующих дополнительных ограничений:

1. Интерфейсы ограничиваются HTTP. Определена следующая семантика:

• HTTP GET используется для получения представления ресурса. Потребитель использует его для получения представления из URI. Услуги, оказываемые через этот интерфейс не должны нести каких-либо обязательств со стороны потребителей.
• HTTP DELETE используется для удаления представления ресурса.
• HTTP POST используется для обновления или создания представления ресурса.
• HTTP PUT используется для создания представления ресурса.

2. Больше всего сообщений находятся в XML, ограниченной схемой, написанной на языке схемы, как например, схема XML от W3C или ELAX NG.

3. Простые сообщения могут кодироваться с шифрованием URL.

4. Обслуживание и поставщики услуг должны быть ресурсами, пока потребитель может быть ресурсом.

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

Расширенный SOAP обмен сообщений

Основные возможности SOAP обмена сообщений были осуществлены в первых освобожденных стандартах. Однако, дополнительные передовые возможности обмена сообщений предложены WS и в настоящее пускаются в ход WS-ReliableMessaging (WSRM), WS-BusinessActivity, WS-Policy, WS-контекст и т.д.

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

Безопасность SOA, управление подлинностью и контроль доступа

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

Основные принципы безопасности SOA

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

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

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

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

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

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

Безопасность в пределах центральной для сети среды имеет свои собственные проблемы:

• ограничения Брандмауэра (защиты от распространения влияния ошибки) - Разрешение входящим HTTP иметь доступ к интернет-сервису открывает серверы к потенциальной атаке, которая, возможно, не обнаружима антивирусами. Например, вредоносное сообщение может быть сконструировано так, чтобы вызвать внутренний прикладной буферный избыток, хотя выглядит полностью безопасным для брандмауэра и сервера HTTP. В последнее время появилось много новой XML продукции, которая пытается защитить веб-сервисы на уровне SOAP, но их эффективность не была близко изучена, и расположение этой продукции в пределах полной архитектуры безопасности предприятия пока не известно.
• Служба безопасности на уровне семантики – Большинство усилий стандартизации были сосредоточены на определении проволочных форматов, необходимых для обеспечения обмена информацией. Стандарты в значительной степени пренебрегают подобной проблемой определения механизма, посредством которого различные интерфейсы связываются друг с другом, чтобы достичь целей безопасности, как например идентификация и уполномочивание. Например, язык разметки для систем обеспечения безопасности (SAML) определяет структуры XML и протоколы для посылки опознавательных утверждений, но это не предписывает, кто должен передавать какую информацию и кому, когда информация должна быть передана, или какая информация может быть использована.
• Функциональная совместимость решений безопасности - Из-за отсутствия стандартного профилирования на уровне сервисного интерфейса, продукция безопасности интернет-сервиса на рынке сегодня не полностью совместима, хотя вся она требует соответствия стандартам безопасности интернет-сервиса. Кроме того, многие из них точечные решения, которые не отвечают всем требованиям Министерства обороны США (DoD) предприятия архитектуры безопасности, и не способны выходить за границы предприятия.
• Многоразовые области безопасности и уровни классификации - Современные технологии охраны еще не ориентированы на подключение и должны эволюционировать, чтобы поддерживать XML и безопасность SOAP – обмена сообщений.
• Безопасность в отношении производительности – архитектура безопасности включает в себя множество вычислений ресурсоемких задач, таких как подписание сообщения, кодирование, и проверки сертификатов. Посылка должным образом подписанного сообщения может быть во много раз медленнее, чем менее безопасный вариант, и, как правило, прямая связь обратная между производительностью и безопасностью. Осторожное планирование и эффективные методы оптимизации необходимы, чтобы гарантировать, что среда обеспечения SOA будет соответствовать эксплуатационным требованиям.
• Воздействие на существующие политики и процессы - Текущая выдача свидетельства и политика аккредитации (C & A) в целом требуют определения границ системы, тогда как в SOA-сети доверительные отношения устанавливаются более динамически. Одно возможное решение - определить границы (C & A) в интерфейсах WS.

Существует набор требований ключевой безопасности, которые должны быть выполнены:

• Идентификация - поставщики услуг в большинстве случаев требуют, чтобы потребители прошли проверку подлинности, прежде чем принимать запрос на обслуживание. Сервисным потребителям также нужно будет удостоверить поставщиков услуг, когда ответ получен. Различные опознавательные механизмы нужно поддерживать, и эти механизмы должны быть настраиваемыми и взаимозаменяемыми согласно специфическим для обслуживания требованиям.
• Авторизация - В дополнение к идентификации потребительских услуг, доступ к обслуживанию будет также требовать, чтобы потребитель обладал определенными привилегиями. Эти привилегии проводят проверку авторизации, которая обычно основана на контроле доступа, например, кто может получить доступ к обслуживанию и при каких условиях. Различные модели могут быть использованы для разрешения, такие как обязательные или основанные на контроле доступа. Выполнение авторизации должно быть расширяемым, чтобы позволить конкретные настройки
• Конфиденциальность - сообщения или документы, которые переносят основные транспортные коммуникации, не могут быть доступны для посторонних лиц. Иногда только фрагмент сообщения или документа (например, завернутый в пределах определенного тега XML), возможно, должны быть конфиденциальными.
• Целостность данных - должна быть обеспечена защита от несанкционированного изменения сообщений во время транспортировки.
• Невозможность отказа от авторства - Невозможность отказа гарантирует, что отправитель не может отрицать, что сообщение уже послано и получатель не может отрицать того, что сообщение уже получено. Более распространенной формой безотказности для систем обмена сообщений является безотказность отправителя, которая только гарантирует, что отправитель не может отрицать, что сообщение уже было отправлено. Невозможность отказа особенно важно в денежных операциях и аудите безопасности.
• Управляемость - архитектура безопасности должна также обеспечивать возможности управления функциями безопасности. Они могут включать, но не ограничиваясь, управление учетными данными, пользовательское управление, и управление контролем доступа.
• Отчетность - включает обеспечение безопасной регистрации и проверки, которая также необходима для безотказности претензий. Кроме того, следующие дополнительные требования также имеют важное значение в среде SOA.
• Функциональная совместимость - Функциональная совместимость является краеугольным камнем SOA, и архитектура безопасности должна сохранить ее в максимально возможных пределах. Главная интеграция безопасности в архитектуре указывает на то, что как между потребителями и поставщиками услуг, а также между поставщиками услуг и инфраструктурными требованиями безопасности имеются устойчивые, последовательные интерфейсы, основанные на государственных стандартах. Эти интерфейсы позволяют каждой области или организации выполнять свои собственные рыночные решения, поддерживая эффективную совместимость.
• Моделирование с учетом ограничений в политике безопасности - в традиционной области безопасности, ресурсы и услуги часто охраняются единым набором правил безопасности, которые не гранулированы достаточно, чтобы соответствовать специфическим прикладным потребностям. В SOA требования услуг может изменяться в пределах того, как они должны быть защищены. Например, одна служба может потребовать X.509-аутентификацию на основе сертификатов, в то время как другой может потребоваться только имя пользователя/пароль. Следовательно, политика безопасности должна быть выразительной и достаточно гибкой, чтобы быть адаптированной в соответствии с различными параметрами(например, главные свойства).
• Обеспечение других услуг инфраструктуры в рамках SOA, таких как открытие, обмен сообщений, посредничества и управления услугами.
• Ненавязчивость - архитектура должна быть ненавязчивой к другим сервисным выполнениям. Более конкретно, для развертывания в новой архитектуре безопасности, поставщику услуг не придется:
• Ограничивать использование какого-либо конкретного языка программирования;
• Подбор соответствия существующей реализации услуг конкретной аппаратной платформе;
• Изменение существующей реализации в отношении любого конкретного производителя интерфейса API;
• Перекомпилировать или перестраивать существующие кодовые наборы.

Управление подлинностью и контроль доступа

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

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

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

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

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

Политика безопасности

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

Политика управления

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

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

Политика управления жизненным циклом процесса

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

Политика управления жизненным циклом процесса

SOA Управления, согласования, риска (GRC)

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

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

Соглашение об уровне сервиса (SLA) и контракты

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

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

Управление и контроль WS

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

Эти инструменты могут быть внеинтегральными в полном решении сетевого управления.