Таким образом, всплеск широко распространенных и открытых стандартов выявил перспективы SOA: поддержка гибкого конфигурирования бизнес-процессов, сокращение управленческих расходов, возможность динамически развертывать сервисы и обеспечение плавной интеграции приложений, отделов и партнеров по бизнесу. К сожалению, к большому разочарованию компаний и технологов, эти завышенные ожидания от SOA не сбылись. Не потому что перспективы сами по себе неверны, а потому что большая часть внедрений SOA – пока, скорее, экспериментальны. Хорошие новости состоят в том, что из экспериментов с SOA можно извлечь ценные уроки, а уроки могут помочь превратить эксперимент в настоящее внедрение, которое раскроет весь потенциал SOA.
Когда понятны цели SOA, возможно обсудить пару примеров, которые подчеркивают необходимость хорошего внедрения SOA. Некоторые отрасли сталкиваются с требованиями законодательства или иных правил, например, Sarbanes-Oxley и XBRL (Расширяемый язык описания деловой отчетности) в отрасли финансовых услуг или «pedigree» в цепочке поставок лекарств. Удовлетворение этим стандартам требует от организации собирать данные отдельных подразделений по всему многообразию ИТ-систем и иногда требует интеграции со сторонними web-сервисами. Для обеспечения обмена данными эти данные зачастую должны быть очищены и преобразованы к стандартным форматам. Другой пример,- управление цепочками поставок с технологией RFID (Радиочастотной идентификацией). RFID дает возможность мониторить в режиме реального времени всю цепочку поставок, что ведет к повышению эффективности. Однако большинство приложений ИТ для этой сферы довольно слабые и не могут использовать подробные данные в режиме реального времени, которые предоставляет RFID устройства. Как известно, SOA значительно упрощает интеграцию и развитие проверенных временем решений, не оказывая сильного влияния на среду деятельности. Поэтому SOA тут дает неоспоримые преимущества для решений RFID за счет быстроты, гибкости и повторного использования. Предприятия, занимающиеся RFID решениями, могут повышать свою скорость реакции и уменьшать стоимость затрат, используя SOA решения в качестве технологической базы. Подходы, полностью или частично основанные на SOA, ведут к интеграции клиентов, и это стоит дорого. Они более тесно связывают системы, что обостряет проблему обслуживания. Большинство ИТ-отделов сейчас только «пробуют водичку» в SOA. Некоторые развертывают сервисы в скромных масштабах для внутреннего пользования. Многие создают оболочки из сервисов поверх приложений, чтобы достичь повторного использования и уменьшения операционных затрат. Так или иначе, внедрения SOA сконцентрированы на уровне сервисов. [Перепечатка материалов 12NEWS.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]
Следующий раздел посвящен обзору необходимых компонент SOA на предприятии Уровень сервисов и реестр Большинство внедрений SOA сконцентрировано на уровне сервисов и часто расширяется до реестра для размещения и поиска сервисов. Такой подход к SOA легко понять. Как упоминалось ранее, идея показа сервисов не нова. Большинство архитекторов и конструкторов программного обеспечения обладают многолетним опытом в построении сервисов и чувствуют себя уверенно в применении знаний для показа сервисов с использованием более новых технологий Web или XML. Как только внедрены сервисы, для их размещения и поиска можно использовать реестровые продукты, основанные на UDDI (Универсальное Описание, Поиск и Взаимодействие). С такой архитектурой видимость сервиса на предприятиях уже гораздо лучше, чем это было возможно до того, как появились стандарты WSDL (Язык Описания Web-сервисов) и UDDI. К сожалению, из-за отдачи от инвестиций большинство внедрений быстро обрывается. До тех пор, пока не становится ясным, что уровня сервисов с реестром недостаточно для оценки модели возврата инвестиций SOA. О том, что остается за полем зрения Когда обычное внедрение SOA, основанное на уровне сервисов и реестра, начинает обретать успех, ИТ-отдел и бизнес-подразделения стараются вложить в него все больше сервисов. Объем размещенных и используемых Web-сервисов сильно растет. И сразу вылезают критические моменты, на которые раньше не обращали внимания. Первая особенность – это необходимость единого управления информацией. Пользователи сервисов внезапно видят сотни, если ни тысячи сервисов, и необходим единый вид данных и сервисов, чтобы они были понятны. Вторая особенность – это необходимость кэширования данных. К огромному количеству данных, полученных в результате хорошего внедрения SOA, нельзя добраться быстро и надежно без кэширования. Третья особенность выходит из болезненного осознания, что данные и сервисы нуждаются в беспрецедентном уровне управления, чтобы быть уверенными в их достоверности. Управление SOA - это процесс определения и усиления политики и стандартов компании. Политики зависят от требований бизнеса к обязанностям управления и зависимостей, уверенности в длительности бизнес-операций и уменьшении затрат. Они также помогают ИТ определением надзора за распространением сервисов внутри предприятия, учитывая корпоративные стандарты и стимулирование совместной работы. Обычная реакция компаний на эти проблемы - это спонтанный, поверхностный подход. Однако возврат инвестиций в SOA достигается только, когда компании используют систематический и хорошо продуманный подход к удовлетворению данных требований. Хранилище SOA Мысленно войдите в хранилище SOA. Хранилище может предоставить намного более богатый набор сервисов, так как оно не только дает доступ к метаданным о сервисах, но и к реальным данным SOA. Поэтому метаданные плюс поиск сервисов, основанный на данных, которые дает хранилище, в сумме получается более мощным средством, чем сервисы, основанные на метаданных из реестра. Хранилище также может обеспечить едиными политикой управления и преобразованиями, объединения, абстрагирования и кэширования продуктов SOA. Бизнес-процессы и сервисы сложных данных могут быть внедрены и управляться через хранилище SOA, чтобы быть уверенными, что они централизованы, прозрачны, и, следовательно, легко управляемы. В связи с вышеперечисленными причинами хранилище SOA – это корневой компонент правильно спроектированной SOA. Поток операций и управление бизнес-процессами Критичная цель для SOA, которую мы упоминали ранее, – это достижение прозрачности и гибкости. Достижению этой цели лучше всего отвечает уровень сервисов, используя поток операций или системы управления бизнес-процессами. Уровень сервис – это быстрорастущий сегмент SOA. Поставщики на этом рынке присутствуют от компаний, занимающихся только BPM и потоком операций, до компаний, работающих над EAI (интеграция приложений предприятия) и серверами приложений. Продукты варьируются по цене и степени зрелости, но нет сомнений, что в течение ближайших лет мы увидим множество отличных рентабельных решений для внедрений SOA. Законченный продукт с потоком операций или управлением бизнес-процессами должен быть легок в обращении, как для пользователей, так и для ИТ. Он должен предлагать моделирование, симуляцию, запуск, мониторинг и отладку процессов без программирования. В идеале продукт должен хорошо интегрироваться с хранилищем SOA так, чтобы потоки операций и бизнес-процессы можно было внедрять в качестве метаданных для централизованного управления. Он также должен поддерживать разработку, внедрение и потребление обработки повторно используемых сложных данных.
Схема ниже показывает правильно внедренную SOA.
Правильно-разработанная SOA должна использовать хранилище метаданных на XML и механизмы взаимодействия данных как основу. Полнофункциональное хранилище SOA - это корневой компонент хорошо разработанной SOA. Оно должно не только содержать все данные и метаданные, относящиеся к деятельности организации, но также предоставлять полный набор функций для эффективного управления этим продуктом. Хорошее хранилище SOA имеет встроенное администрирование данных и управление сервисами. Оно обладает полным словарем и возможностями семантического согласования. Оно позволяет организовывать данные и сервисы в ясную систематику, а также предоставляет управление жизненным циклом и версиями сервисов. Оно дает полный набор сервисов для обработки данных для управления качеством, подтверждения, преобразования, объединения и кэширования. Эти сервисы также автоматически доступны продуктам, относящимся к бизнес-процессам и потокам операций, настроенным сервисам по обработке сложных данных и сторонним сервисам при их внедрении в хранилище SOA. Другой важный компонент - это платформа BPM/потока операций. Уровень приложений может искать и использовать сервисы непосредственно из реестра сервисов/уровня хранилища или для большей гибкости может пройти через платформу потока операций/управления бизнес-процессами. В то время как платформа BPM/потока операций дает один набор сервисов для приложений, уровень внешних сервисов может одновременно отмечать сервисы для поиска и использования клиентами. Важность хранилища SOA не принижается большинством поставщиков реестров. На сегодня многие реестры SOA обладают некоторыми встроенными функциями хранилищ. Однако для успеха необходимо богатство набора функций хранилища и его внедрение. На самом деле, одна из причин, по которой хранилища предали забвению, состоит в том, что немногие внедрения справились с подробной функциональностью и требованиями к производительности.
При успешном внедрении SOA в компании может возникнуть множество проблем. Критичной ошибкой большинства компаний является разрыв между целями компании и текущими вложениями в нужные компоненты и технологии для достижения этих целей. Много усилий прикладывается к сервисам, но корневые компоненты архитектуры: реестр и хранилище SOA, не разработаны достаточно хорошо, чтобы работать успешно. Более того, компании склонны забывать об эффективном управлении данными и сервисами, до тех пор, пока не становится слишком поздно. Большая часть потока данных на предприятии и между компаниями использует XML. Весь потенциал SOA может быть реализован, если внедрение построено вокруг инфраструктуры, которая лучше всего подходит для управления такими данными. XML объединенный с XQuery в качестве основы для полномасштабной обработки данных, дает солидное основание для гибкого, наращиваемого реестра и хранилища SOA для предприятия.
Ash Parikh и Murty Gurajada, Аналитики JavaWorld
Перевод и адаптация: Алексей Маринин 12NEWS©
© Издание 12NEWS (ИП Маринин А.Л.), 2007