В последнее время понятие технологии SOA воспринимается не просто в понимании «сервисы». Появление Интернета и XML открыло шлюзы для использования обмена данными. Отрасль программного обеспечения поднялась вслед за общим форматом обмена данными (XML) и протоколами передачи данных Интернета.
SOA в реальности
Цели SOA Достичь хорошей видимости и гибкости процесса Подъем использования технологии SOA по всему миру, определенно, всецело оправдан. Компании всегда вкладывают большие средства в технологии, чтобы оставаться конкурентоспособными, SOA дает им возможность прорыва. Кроме того, компании совершенствуют бизнес-процессы, чтобы выжать до последней капли конкурентные преимущества. Появление управления бизнес-процессами (BPM) обещает постоянное совершенствование процессов и невиданное взаимодействие между бизнесом и ИТ. SOA – это зонтик, под которым компании прилагают усилия, чтобы добиться полной прозрачности в данных и процессах, постоянно совершенствуются и эффективно проводят детальный контроль. Разрушить разъединенность подразделений Вторая цель SOA – разрушить разъединенность приложений, подразделений и бизнес-партнеров, порожденную множеством лет развития программного обеспечений, которое должно было обеспечить развивающиеся требования бизнеса и совершенствование технологий. Подразделения, распоряжаясь своим ИТ-бюджетом, создают приложения для покрытия своих сиюминутных нужд, не изучая уже существующие проекты, функциональность которых может перекрываться. В результате, множество приложений оставляют ИТ наедине в борьбе с согласованием дублирующейся информации, кусочков бизнес-процессов, разбросанных по сотням приложений. SOA обещает разрушить эту разъединенность и позволить организациям повысить прозрачность данных и процессов. Управлять более качественными данными Компании хотят не только лучше управлять данными, но также и управлять лучшими данными. Важно быть уверенным в том, что полученные и распространенные по компании и бизнес-партнерам данные чисты, надежны, безопасны, хорошо управляемы и быстры. Одна из целей SOA – обеспечить платформу обработки смешанных данных единым набором компонент для доступа к данным, повышения качества, преобразования, управления и кэширования среди множества других сервисов, ориентированных на работу с данными. Повторно использовать сервисы Сопутствующая цель SOA – это эффективно управлять и повторно использовать сервисы и данные компании. Сервисы, разработанные одной группой в компании, могут быть повторно использованы другой группой в организации или за ее пределами, если они размещены и описаны в стандартном формате в доступной директории. Когда данные и сервисы принадлежат владельцу и доступны пользователям, операционные расходы на поддержку и управление данными уменьшаются. Повторное использование - один из наибольших стимулов SOA. Привести в соответствие цели компании Другая цель SOA – это привести в соответствие бизнес и ИТ в вопросах целей компании, чтобы лучше способствовать разработке гибких и донастраиваемых бизнес-процессов. Исторически, сферы интересов бизнеса и ИТ лежали в абсолютно независимых областях улучшения результатов работы компании. Бизнес стремится модернизировать бизнес-процессы для получения конкурентных преимуществ, а ИТ пытается приспособить технологии для внедрения этих процессов. Традиционный подход подразумевает, что бизнес определяет изменения в бизнес-процессе и затем «перекидывает мяч через сетку» специалистам ИТ для внедрения. Ни одна из групп не знала функций другой группы. BPM – это грань SOA, которая убирает деление бизнес/-/ИТ за счет постоянного процесса совершенствования с помощью моделирования, симуляции, запуска и наблюдения в терминах, которые общие для ИТ и бизнеса, и понимаемы и теми, и другими.

Таким образом, всплеск широко распространенных и открытых стандартов выявил перспективы SOA: поддержка гибкого конфигурирования бизнес-процессов, сокращение управленческих расходов, возможность динамически развертывать сервисы и обеспечение плавной интеграции приложений, отделов и партнеров по бизнесу. К сожалению, к большому разочарованию компаний и технологов, эти завышенные ожидания от 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 сконцентрировано на уровне сервисов и часто расширяется до реестра для размещения и поиска сервисов. Такой подход к 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.

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


Комментарии на публикацию SOA в реальности

В последнее время понятие технологии SOA воспринимается не просто в понимании «сервисы». Появление Интернета и XML открыло шлюзы для использования обмена данными. Отрасль программного обеспечения поднялась вслед за общим форматом обмена данными (XML) и протоколами передачи данных Интернета.
20.08.07 Alex.V: хорошая статья
Было бы реально интересно ссылки на хорошие примеры компаний которые вводили или ошибки внедрений других компаний.