Архитектура SOA как она есть
SOA совершенно не зависима от языков программирования, платформ или протокольных спецификаций, с помощью которых сервисы разрабатываются, а также от того, где и с помощью чего они развернуты. Практически архитектура SOA требует наличия не только сервисов, но и средств, с помощью которых эти сервисы могут быть обнаружены и подключены независимо от нижележащей инфраструктуры. SOA — это не продукт или спецификация, поэтому вы не можете просто пойти и купить “коробку с SOA”.
Вы должны настроиться на тщательное выстраивание данной архитектуры, состоящей из множества компонентов, таких, как серверы приложений, связующее ПО, репозиторий и даже специализированные пакеты централизованного управления SOA.
Строго говоря, SOA нельзя относить ни к новой реализации CORBA, ни к обновленной архитектуре RMI (Remote Method Invocation). Ключевой компонент SOA — сервис. Сервисы здесь являются бизнес-функциями, предназначенными для обеспечения согласованной работы больших, состоящих из множества частей приложений. По сути, это строительные блоки для отражения бизнес-логики в разрабатываемых приложениях. А конечным местом, где сервисы “обитают”, является сервер приложений, будь то WebLogic от BEA Systems, WebSphere от IBM, Application Server от Oracle или Java AS от Sun Microsystems.
Чтобы реализовать архитектуру SOA для гипотетического предприятия NWC Inc., в лаборатории журнала Network Computing мы использовали платформы WebSphere 6.0 (WAS) фирмы IBM и .Net компании Microsoft. Сервер WAS содержит сервисы по управлению данными о покупателях и заказах, тогда как сервер .Net обеспечивает сервисы по управлению складскими запасами. Для создания комплексно-го приложения по обслуживанию клиентов нам необходимо задействовать оба сервера (см. рисунок).
Функции, или операции, в SOAP (Simple Object Access Protocol) должны быть интуитивно понятными и соответствовать своим названиям — например, submitPurchaseOrder (“подтвердить заказ на покупку”) или validateCustomerAccounts (“проверить лицевой счет заказчика”). В отличие от обычных приложений сервис в архитектуре SOA назначается для использования всем реализованным бизнес-функциям. В то время как обычные корпоративные приложения содержат в себе похожие фрагменты бизнес-логики или даже дублируют отдельные объекты — например, объект клиентского заказа, — в архитектуре SOA вам нужно запустить лишь единственный экземпляр такой бизнес-функции. Таким образом, вы можете повторно использовать функциональность в среде с множественными приложениями и быстро корректировать бизнес-логику, для того чтобы иметь возможность приспосабливаться к меняющимся условиям рынка. В этом и состоит главное достоинство SOA.
С изменением единственного экземпляра бизнес-функции в SOA автоматически вносятся коррективы и во все приложения, опирающиеся на эту функцию. Так что, например, любые изменения в правилах ценообразования или политики скидок применяются во всех приложениях. Аналогично любые изменения в поддерживающей инфраструктуре остаются прозрачными для всех приложений, использующих сервисы. Например, если вы переходите с одной версии базы данных на другую, то будут модифицированы лишь связанные с ней сервисы, поскольку приложения в архитектуре SOA работают со всеми инфраструктурными приложениями только посредством сервисов. В недавнем прошлом изменения в связующем ПО или в базе данных заставляли переделывать всю систему, включая клиентские настольные приложения.
Одно из важных преимуществ архитектуры SOA — ее надежность, особенно если речь заходит о ее реализации на базе Web-сервисов и спецификации SOAP, наиболее часто использующих протокол HTTP. Дело в том, что изначально HTTP не планировался для целей гарантированной доставки, поэтому сам по себе он не обеспечивает надежного выполнения критически важных транзакций. Для решения этой проблемы были созданы два относительно новых конкурирующих стандарта — WS-RM (Web Services Reliable Messaging) и WS-R (Web Services Reliability), но современные реализации SOA для обеспечения гарантированной доставки используют более традиционные методы, — например, ESB (Enterprise Service Bus).
Связующее ПО ESB может служить опорой вашей архитектуры SOA, обеспечивая гарантированную доставку сообщений, обработку исключительных ситуаций и использование всех возможностей модели “публикация—подписка”. Оно работает так же, как и традиционное связующее ПО обмена сообщениями, такое, как MQ Series фирмы IBM, EMS фирмы Tibco или JMS (Java Message Service), выполняющее маршрутизацию сообщений с их промежуточным хранением. Сервисы на сервере приложений “контактируют” с шиной ESB, запуская асинхронные сервисные механизмы и гарантированную доставку сообщений. ПО ESB также может служить в качестве средства интеграции, позволяющего множеству приложений осуществлять доступ к одной и той же транзакции в пределах системы.
Другим важным компонентом хорошо спланированной архитектуры SOA является централизованный репозиторий, который содержит справочник всех сервисов, доступных на вашем предприятии. Здесь подойдет любая их классификация, наилучшим образом соответствующая вашей организации. Она должна обеспечивать группирование сервисов по бизнес-функциям, подразделениям, источникам данных или даже по версии исходного кода. Используйте такую классификацию, которая позволит вашим разработчикам быстро находить сервисы, в которых они нуждаются для создания новых приложений.
Указанную функциональность в SOA обеспечивает реестр, основанный на стандарте UDDI (Universal Description, Discovery and Integration), который можно рассматривать как справочник “желтые страницы” Web-сервисов. В нем перечислены компании и связанные с ними сервисы (все используемые здесь стандарты — UDDI, WSDL и SOAP — находятся в ведении организации OASIS). Данные механизмы позволяют организовать доступ ваших партнеров по бизнесу к реестру, тем самым обеспечивая возможность быстрой интеграции ваших приложений.
Однако это все мечты, а пока что сервисы, ориентированные на партнеров или клиентов, часто составляются из множества более мелких “комплектующих Web-сервисов”, для сшивания которых и используется UDDI. Таким образом, сегодня UDDI используется, например, для создания сервисов между торговыми партнерами или в цепочках снабжения.
На данный момент времени уже создано ПО реестра сервисов, соответствующее стандарту UDDI. Это, в частности, Registry компании Infravio, Service Manager фирмы SOA Software и Business Service Registry от Systinet. Каждый из этих продуктов функционирует как центральный интеллектуальный концентратор, посредством которого осуществляются систематизация сервисов SOA, доступ к ним, а в некоторых случаях и управление (как, например, в продукте Systinet).
Одним из важных вопросов построения архитектуры SOA являются ее администрирование и обеспечение безопасности. При наличии сотен сервисов, готовых к применению, у пользователя возникает потребность в централизованной системе администрирования, с помощью которой можно было бы осуществлять их мониторинг и защиту.
Существует множество систем администрирования SOA (на базе агентов и без них). Продукты SOAPStation компании Actional, Management Foundation, Service-Level Manager и Exception Manager фирмы AmberPoint, Gateway от Reactivity и Service Manager компании SOA Software являются наибо-лее популярными средствами, предназначенными для администрирования сервисов в рамках всего предприятия. Компании Computer Associates и Hewlett-Packard со своими продуктами Unicenter и OpenView соответственно также предлагают программные средства для оперативного администрирования и мониторинга SOA.
Администрирование SOA означает как мониторинг работоспособности отдельных сервисов, так и регистрацию и проверку необходимых функций в соответствии с различными законодательными актами, регламентирующими правила и сроки хранения бухгалтерской отчетности и других деловых документов. Программные продукты по администрированию SOA также облегчают распределение сервисов, автоматически отслеживая ненадежные соединения и проблемы взаимодействия корпоративных сетей с помощью средств захвата сообщений, по своим возможностям намного превосходящие традиционные анализаторы сетевых протоколов.
В зависимости от нужд вашей организации вы можете обеспечить безопасность архитектуры SOA с помощью обычных продуктов управления на базе протокола SOAP или других специальных продуктов. Например, нашей гипотетической компании NWC Inc. из соображений экономии лучше всего подошли бы совмещенные решения по управлению и обеспечению безопасности, но большие организации, возможно, захотят разделить эту функциональность между двумя разными продуктами.
Программные продукты, отвечающие за безопасность, такие, как XS40 компании DataPower, Sentry и Xwall от ForumSystems, Gateway от Reactivity и XML Guardian от Sarvega, представляют собой единую точку доступа, через которую должны проходить все сервисные запросы.
Безопасность вполне допустимо обеспечивать и на уровне сервера приложений, на котором размещаются сервисы, но это является невыполнимой задачей, если ваш партнер по бизнесу будет взаимодействовать с вашей архитектурой SOA. Внешние Web-сервисы или шлюз XML являются более гибкими средствами для предо-ставления доступа партнеру (или клиенту) к вашей SOA, значительно облегчающими жизнь разработчикам приложений. Если принять во внимание тот факт, что архитектура SOA не имеет четкого набора объединяемых систем, то нет ничего страшного в том, чтобы разделить функции обеспечения безопасности и администрирования сервисов.
Вы должны настроиться на тщательное выстраивание данной архитектуры, состоящей из множества компонентов, таких, как серверы приложений, связующее ПО, репозиторий и даже специализированные пакеты централизованного управления SOA.
Строго говоря, SOA нельзя относить ни к новой реализации CORBA, ни к обновленной архитектуре RMI (Remote Method Invocation). Ключевой компонент SOA — сервис. Сервисы здесь являются бизнес-функциями, предназначенными для обеспечения согласованной работы больших, состоящих из множества частей приложений. По сути, это строительные блоки для отражения бизнес-логики в разрабатываемых приложениях. А конечным местом, где сервисы “обитают”, является сервер приложений, будь то WebLogic от BEA Systems, WebSphere от IBM, Application Server от Oracle или Java AS от Sun Microsystems.
Чтобы реализовать архитектуру SOA для гипотетического предприятия NWC Inc., в лаборатории журнала Network Computing мы использовали платформы WebSphere 6.0 (WAS) фирмы IBM и .Net компании Microsoft. Сервер WAS содержит сервисы по управлению данными о покупателях и заказах, тогда как сервер .Net обеспечивает сервисы по управлению складскими запасами. Для создания комплексно-го приложения по обслуживанию клиентов нам необходимо задействовать оба сервера (см. рисунок).
Понятные функции
Функции, или операции, в SOAP (Simple Object Access Protocol) должны быть интуитивно понятными и соответствовать своим названиям — например, submitPurchaseOrder (“подтвердить заказ на покупку”) или validateCustomerAccounts (“проверить лицевой счет заказчика”). В отличие от обычных приложений сервис в архитектуре SOA назначается для использования всем реализованным бизнес-функциям. В то время как обычные корпоративные приложения содержат в себе похожие фрагменты бизнес-логики или даже дублируют отдельные объекты — например, объект клиентского заказа, — в архитектуре SOA вам нужно запустить лишь единственный экземпляр такой бизнес-функции. Таким образом, вы можете повторно использовать функциональность в среде с множественными приложениями и быстро корректировать бизнес-логику, для того чтобы иметь возможность приспосабливаться к меняющимся условиям рынка. В этом и состоит главное достоинство SOA.
С изменением единственного экземпляра бизнес-функции в SOA автоматически вносятся коррективы и во все приложения, опирающиеся на эту функцию. Так что, например, любые изменения в правилах ценообразования или политики скидок применяются во всех приложениях. Аналогично любые изменения в поддерживающей инфраструктуре остаются прозрачными для всех приложений, использующих сервисы. Например, если вы переходите с одной версии базы данных на другую, то будут модифицированы лишь связанные с ней сервисы, поскольку приложения в архитектуре SOA работают со всеми инфраструктурными приложениями только посредством сервисов. В недавнем прошлом изменения в связующем ПО или в базе данных заставляли переделывать всю систему, включая клиентские настольные приложения.
Одно из важных преимуществ архитектуры SOA — ее надежность, особенно если речь заходит о ее реализации на базе Web-сервисов и спецификации SOAP, наиболее часто использующих протокол HTTP. Дело в том, что изначально HTTP не планировался для целей гарантированной доставки, поэтому сам по себе он не обеспечивает надежного выполнения критически важных транзакций. Для решения этой проблемы были созданы два относительно новых конкурирующих стандарта — WS-RM (Web Services Reliable Messaging) и WS-R (Web Services Reliability), но современные реализации SOA для обеспечения гарантированной доставки используют более традиционные методы, — например, ESB (Enterprise Service Bus).
Связующее ПО ESB может служить опорой вашей архитектуры SOA, обеспечивая гарантированную доставку сообщений, обработку исключительных ситуаций и использование всех возможностей модели “публикация—подписка”. Оно работает так же, как и традиционное связующее ПО обмена сообщениями, такое, как MQ Series фирмы IBM, EMS фирмы Tibco или JMS (Java Message Service), выполняющее маршрутизацию сообщений с их промежуточным хранением. Сервисы на сервере приложений “контактируют” с шиной ESB, запуская асинхронные сервисные механизмы и гарантированную доставку сообщений. ПО ESB также может служить в качестве средства интеграции, позволяющего множеству приложений осуществлять доступ к одной и той же транзакции в пределах системы.
Другим важным компонентом хорошо спланированной архитектуры SOA является централизованный репозиторий, который содержит справочник всех сервисов, доступных на вашем предприятии. Здесь подойдет любая их классификация, наилучшим образом соответствующая вашей организации. Она должна обеспечивать группирование сервисов по бизнес-функциям, подразделениям, источникам данных или даже по версии исходного кода. Используйте такую классификацию, которая позволит вашим разработчикам быстро находить сервисы, в которых они нуждаются для создания новых приложений.
Указанную функциональность в SOA обеспечивает реестр, основанный на стандарте UDDI (Universal Description, Discovery and Integration), который можно рассматривать как справочник “желтые страницы” Web-сервисов. В нем перечислены компании и связанные с ними сервисы (все используемые здесь стандарты — UDDI, WSDL и SOAP — находятся в ведении организации OASIS). Данные механизмы позволяют организовать доступ ваших партнеров по бизнесу к реестру, тем самым обеспечивая возможность быстрой интеграции ваших приложений.
Однако это все мечты, а пока что сервисы, ориентированные на партнеров или клиентов, часто составляются из множества более мелких “комплектующих Web-сервисов”, для сшивания которых и используется UDDI. Таким образом, сегодня UDDI используется, например, для создания сервисов между торговыми партнерами или в цепочках снабжения.
На данный момент времени уже создано ПО реестра сервисов, соответствующее стандарту UDDI. Это, в частности, Registry компании Infravio, Service Manager фирмы SOA Software и Business Service Registry от Systinet. Каждый из этих продуктов функционирует как центральный интеллектуальный концентратор, посредством которого осуществляются систематизация сервисов SOA, доступ к ним, а в некоторых случаях и управление (как, например, в продукте Systinet).
Администрирование и безопасность
Одним из важных вопросов построения архитектуры SOA являются ее администрирование и обеспечение безопасности. При наличии сотен сервисов, готовых к применению, у пользователя возникает потребность в централизованной системе администрирования, с помощью которой можно было бы осуществлять их мониторинг и защиту.
Существует множество систем администрирования SOA (на базе агентов и без них). Продукты SOAPStation компании Actional, Management Foundation, Service-Level Manager и Exception Manager фирмы AmberPoint, Gateway от Reactivity и Service Manager компании SOA Software являются наибо-лее популярными средствами, предназначенными для администрирования сервисов в рамках всего предприятия. Компании Computer Associates и Hewlett-Packard со своими продуктами Unicenter и OpenView соответственно также предлагают программные средства для оперативного администрирования и мониторинга SOA.
Администрирование SOA означает как мониторинг работоспособности отдельных сервисов, так и регистрацию и проверку необходимых функций в соответствии с различными законодательными актами, регламентирующими правила и сроки хранения бухгалтерской отчетности и других деловых документов. Программные продукты по администрированию SOA также облегчают распределение сервисов, автоматически отслеживая ненадежные соединения и проблемы взаимодействия корпоративных сетей с помощью средств захвата сообщений, по своим возможностям намного превосходящие традиционные анализаторы сетевых протоколов.
В зависимости от нужд вашей организации вы можете обеспечить безопасность архитектуры SOA с помощью обычных продуктов управления на базе протокола SOAP или других специальных продуктов. Например, нашей гипотетической компании NWC Inc. из соображений экономии лучше всего подошли бы совмещенные решения по управлению и обеспечению безопасности, но большие организации, возможно, захотят разделить эту функциональность между двумя разными продуктами.
Программные продукты, отвечающие за безопасность, такие, как XS40 компании DataPower, Sentry и Xwall от ForumSystems, Gateway от Reactivity и XML Guardian от Sarvega, представляют собой единую точку доступа, через которую должны проходить все сервисные запросы.
Безопасность вполне допустимо обеспечивать и на уровне сервера приложений, на котором размещаются сервисы, но это является невыполнимой задачей, если ваш партнер по бизнесу будет взаимодействовать с вашей архитектурой SOA. Внешние Web-сервисы или шлюз XML являются более гибкими средствами для предо-ставления доступа партнеру (или клиенту) к вашей SOA, значительно облегчающими жизнь разработчикам приложений. Если принять во внимание тот факт, что архитектура SOA не имеет четкого набора объединяемых систем, то нет ничего страшного в том, чтобы разделить функции обеспечения безопасности и администрирования сервисов.
© Галактика, 2006
© Издание 12NEWS (ИП Маринин А.Л.), 2006
