|
| |||
|
директор и главный разработчик SOA, East Region, IBM Адаптация устаревших систем к SOA Поиск новых бизнес-ценностей в устаревших приложениях
Уровень сложности: средний Сервис-ориентированная архитектура (Service-Oriented Architecture - SOA) вместе с другими сервис-ориентированными походами к разработке и управлению информационными инфраструктурами побуждает многие организации пересмотреть традиционные подходы к использованию старых инвестиций в информационную технологию. В данной статье обсуждаются бизнес- и IT-преимущества применения SOA для преобразования старых инвестиций, а также ключевые архитектурные шаблоны, позволяющие получить выгоду от использования устаревших мэйнфреймов. Определение понятия "устаревший" Понятие "устаревший" относится к существующим информационным активам, развернутым в прошлом. Эти активы могут быть установлены где угодно и когда угодно, (и вчера, и двадцать лет назад), и во многих случаях старые инвестиции выполняют критически важные бизнес-процессы. Устаревшее программное обеспечение и приложения часто рассматриваются высокорентабельными предприятиями в качестве "дойной коровы" и, следовательно, отвечают за значительную долю прибыли компании. Эта прибыль обычно намного превышает расходы на обслуживание устаревших активов, а разница иногда используется компаниями для финансирования других стратегических инициатив. Кроме того, устаревшее программное обеспечение и приложения могут появиться на предприятии как результат слияния или приобретения. Во многих случаях люди, обеспечивавшие разработку и сопровождение приложений, больше не отвечают за их жизненный цикл. Устаревшая инфраструктура не обязательно ограничивается приложениями и сервисами для мэйнфреймов. Кроме того, устаревшие приложения могут часто представлять значительную бизнес-ценность для компании. Например, по оценкам в настоящее время используется более 200 миллиардов строк кода на языке COBOL, и ежедневно обрабатывается более 30 миллиардов COBOL-транзакций. Рисунок 1. Существующая устаревшая среда
Устаревшие системы обычно созданы по следующим (одному или нескольким) образцам:
Возрождение устаревших систем - это процесс предоставления возможности использовать имеющееся программное обеспечение и информационные активы в новых бизнес-процессах. Понимание необходимости преобразований Устаревшие системы обычно состоят из бесценных активов со встроенной бизнес-логикой, которая потребовала многих лет кодирования, разработки, улучшений и изменений. Однако зачастую они не документированы, сильносвязаны, относительно закрыты и не гибки. В большинстве случаев они были разработаны независимо, без цельной архитектуры, что привело к наложению и избыточности функциональности и данных. Основными проблемами устаревших активов обычно являются:
Поскольку большинство компаний сделали значительные инвестиции в свою инфраструктуру, руководство обычно не приветствует замену устаревших систем, независимо от уровня очевидности недостатков инфраструктуры. Переписывание или значительное изменение больших частей старой среды не является практичным и реально осуществимым в разумный промежуток времени. Использование SOA-подхода к устаревшим системам Главной проблемой в вышеупомянутых болевых точках является поиск и определение полезной устаревшей функциональности и задач, которые могут быть выражены как сервисы для использования совместно работающими приложениями, пытающимися потребить эти сервисы. В архитектурах прошлого устаревшие системы обычно рассматривались как черные ящики. Для доступа к этим системам были написаны стандартные интерфейсы прикладного программирования (API) и сами интерфейсы. Задача понять бизнес-процессы, лежащие в основе устаревших систем, обычно не ставилась. При подобном подходе нефункциональные требования (nonfunctional requirements - NFR), такие как производительность, защищенность, управляемость и простота обслуживания часто не учитывались в архитектурном дизайне. Чаще всего приложения и данные, выполняющиеся в воображаемом черном ящике, были тесно связаны. Такое тесное связывание делало практически невозможным изменение и воспроизведение бизнес-процессов. В SOA-среде бизнес-задачи решаются путем выполнения последовательности "сервисов", которые иногда участвуют в бизнес-процессе. Сервисы имеют четко определенные способы общения с другими сервисами. Реализация сервиса не имеет значения для пользователя до тех пор, пока сервис реагирует ожидаемым способом и предлагает требуемое качество. Такой подход означает, что сервис должен быть защищенным, надежным и быстрым, и это делает SOA идеальной архитектурой для использования в информационной среде, в которой развернуты программное и аппаратное обеспечение от нескольких производителей, или там, где существующие информационные активы смешаны с новыми приложениями, технологиями интеграции или источниками данных. Использование SOA для возрождения устаревшей системы может дать много бизнес- и IT-преимуществ. Самым главным с точки зрения бизнеса является то, что эта архитектура создает новую бизнес-ценность из существующих активов и систем обычно в новых бизнес-процессах и композитных приложениях (например, приложения-порталы). SOA помогает обеспечить доступ в режиме реального времени к тому, что раньше было пакетными транзакциями, тем самым повышая скорость и точность принятия бизнес-решений. Повторное использование бизнес-данных и приложений посредством SOA способствует более качественному обслуживанию пользователей и, тем самым, удержанию клиентов. SOA позволяет пользоваться преимуществами превосходного качества сервисов в процессе перенастройки критических процессов и данных. Более того, SOA помогает расширить и защитить инвестиции в устаревшие системы и квалификацию разработчиков, в то же время способствуя достижению большей совместимости с другими системами на предприятии, а также с системами клиентов, партнеров и поставщиков. Есть возможность взять самое лучшее от старого и нового, воспользоваться преимуществами технического прогресса и в то же время не растерять имеющиеся активы. Если вы поступите подобным образом, то встанете на свой собственный путь формирования более гибкого бизнеса, максимально отвечающего потребностям ваших клиентов, путь совершенствования вашей деятельности. Такая быстрая адаптация как раз и составляет смысл "бизнеса по требованию", а SOA может сделать вашу устаревшую инфраструктуру способной по-прежнему работать на вас, но новым, лучшим способом. Оценка влияния SOA на адаптацию и преобразование устаревших систем Большинство компаний представляют SOA как целостную взаимосвязь между бизнесом и IT-структурой. Широко распространено мнение, что SOA охватывает инструментальные средства и методологии для проектирования бизнес-деятельности, а использование этой информации в конечном итоге помогает улучшить бизнес-деятельность. SOA охватывает также инфраструктуру управления и промежуточного программного обеспечения для размещения и управления этой реализацией. И в конечном счете SOA ускоряет процесс время-деньги. Существует мнение, что устаревшие приложения лучше подходят для использования в качестве частей SOA-среды, чем многие современные распределенные приложения. Когда много лет тому назад разработчики писали приложения для мэйнфреймов, они делали это с точки зрения бизнес-функции. Добавление клиента, заказ продукта, удаление пользователя и "выдача номера рейса, связанного с данным маршрутом" обычно были затребованными действиями. Таким образом, многие устаревшие приложения в действительности лучше приспособлены к интеграции бизнес-деятельности и IT-структуры, которую предлагает SOA. SOA ускоряет процесс время-деньги в устаревших приложениях путем:
Определение трех этапов SOA-преобразования устаревших систем Подходы к адаптации устаревших приложений могут быть разделены на три основные категории. Повышение удобства работы пользователей
Адаптация, улучшающая взаимодействия
Инновация, обеспечивающая новые возможности
Шаблоны преобразования устаревших приложений: CICS Традиционные (старые) приложения, работающие в CICS, редко имеют четкое разделение задач. Предоставлялся интерфейс 3270, потому что бизнес-логика и логика представления были тесно связаны в одной программе. Это очень затрудняет преобразование и адаптацию таких приложений к парадигме SOA. На рисунке 2 изображено традиционное CICS-приложение, в котором логика представления (P) и бизнес-логика (B) обращаются к модели данных (D). Рисунок 2. Традиционный дизайн CICS-приложения
Передовая методика проектирования новых CICS-приложений - разделять ключевые элементы приложения. К таким элементам относятся логика представления, логика интеграции, бизнес-логика и логика данных. Эта концепция предоставляет возможность повторно использовать каждый элемент в подпрограммах или сервисах, которые могут быть отвязаны от оригинального приложения. Например, сейчас имеется возможность заключения бизнес-логики в Web-сервисы. На рисунке 3 изображен дизайн, который является хорошим кандидатом для преобразования и адаптации к SOA. Рисунок 3. Хороший дизайн CICS-приложения Провайдер и запросчик Web-сервиса в CICS Web-сервисы описывают стандартизированный способ интеграции Web-приложений, используя открытые стандарты XML, SOAP, Web Services Description Language (WSDL) и Universal, Description, Discovery and Integration (UDDI) в стеке Internet-протоколов. XML используется для разметки данных, SOAP используется для передачи данных, WSDL используется для описания доступных сервисов, а UDDI используется для перечисления доступных сервисов. Используемые первоначально как средство общения компаний между собой и с клиентами, Web-сервисы позволяют организациям обмениваться данными без глубоких знаний информационных систем друг друга через межсетевые экраны. CICS-приложение, как показано на рисунке 4, теперь может быть провайдером или запросчиком Web-сервисов, поддерживающим следующие стандарты:
Доступ Java Connector Architecture к CICS Архитектура JCA (Java™ Connector Architecture) является J2EE-стандартом для подключения к гетерогенным корпоративным информационным системам, таким как устаревшие CICS (см. рисунок 5). CICS Transaction Gateway предоставляет JCA-коннектор в качестве адаптера ресурсов. JCA-адаптеры мало или совсем ничего не требуют от устаревшей системы; они получают доступ к устаревшей системе посредством родных API, сокетов, через доступ к данным и многие другие технологии, не требующие изменения какой-либо существующей базы кода. Такой подход дает возможность использовать уже вложенные в развертывание системы инвестиции, а не инвестировать дополнительные ресурсы в обновление системы для поддержки интеграции.
Доступ Enterprise JavaBeans к CICS EJB-компоненты (Enterprise JavaBeans) позволяют поддерживать распределенные бизнес-приложения, в которых компоненты могут размещаться на различных платформах в различных местах. Java-клиент может вызвать удаленный объект, используя RMI поверх IIOP, после получения ссылки на него, как показано на рисунке 6. CICS поддерживает EJB-компоненты изначально. Клиент системы электронной коммерции взаимодействует с работающим внутри CICS EJB-контейнером, используя RMI поверх IIOP. Контейнер CICS использует JCA или адаптер сообщений для доступа к бизнес-логике, тоже выполняющейся в разделе CICS или отдельном разделе.
Доступ WebSphere MQ к CICS WebSphere MQ поддерживает простой обмен информацией между гетерогенными платформами, в то же время интегрируя существующие бизнес-приложения в процесс. WebSphere MQ обеспечивает гарантированную доставку сообщений и доставку с подтверждением, а также предоставляет как Java Message Service (JMS) API, так и встроенные MQ API для использования клиентами на широком разнообразии платформ. Программа мониторинга триггеров WebSphere MQ выполняется в CICS. Когда прибывает сообщение, она запускает новую программу адаптера в новой транзакции. Адаптер сообщений использует встроенные MQ API для приема сообщения, преобразования (при необходимости) и вызова программы бизнес-логики CICS (B), как показано на рисунке 7.
Доступ WebSphere Message Broker к CICS WebSphere Message Broker (Message Broker) позволяет подключаться к широкому диапазону приложений, используя различные шаблоны взаимодействия, протоколы и форматы сообщений. Сообщения, проходящие через Message Broker, могут перенаправляться и преобразовываться в различные форматы по пути к своим адресатам. Message Broker может принимать сообщения из разнообразных источников в различных форматах и при необходимости направлять и преобразовывать их, то есть сообщения могут передаваться адресатам для использования приложениями в форматах и протоколах, которые приложения ожидают. Такой многоэтапный процесс и является смыслом посредничества при передаче сообщений - сквозные соединения между всеми частями корпоративной системы. Всегда есть возможность выполнять CICS-транзакции с использованием MQ-сообщений, сгенерированных либо брокером, либо непосредственно (если в программе CICS-транзакций разрешены MQ), а также с использованием моста CICS DPL или 3270. Однако данный подход имеет недостатки с точки зрения брокера.
CICS request node (точка запроса) позволяет синхронизировать CICS-программу с потоком сообщений, что упрощает структуру потока, уменьшает количество транзакций и поддерживает рабочий контекст, пока запрос обрабатывается в CICS. Message Broker V6, использующий CICS node (см. рисунок 8), значительно упрощает работу и повышает производительность до трех раз (подробная информация приведена в Support Pac IA12). CICS node извлекает COMMAREA из части node-defined входного приложения и использует интерфейс EXCI для выполнения соответствующей программы транзакции. Полученный COMMAREA добавляется обратно в дерево сообщения по завершению транзакции. CICS-программа транзакций может функционировать внутри координируемой RRS единицы работы, либо фиксироваться немедленно в соответствии с атрибутом узла. Чтобы выжить, отдел информационных технологий должен подумать о новых способах доказать свою необходимость для бизнес-деятельности предприятия; это может быть либо создание новых бизнес-моделей, либо преобразования существующих. В данной статье мы исследовали несколько подходов и стилей преобразования устаревших систем и рассмотрели способы адаптации существующих систем к SOA-средам. Выбор правильного шаблона для решения конкретной проблемы является ключевым и в конечном итоге определяет уровень успеха в достижении поставленных бизнес-целей. Не существует быстрого решения в деле преобразования устаревших систем. Путь к становлению динамичного и гибкого предприятия требует терпения. Однако и в процессе пути можно получить выгоды. Это означает, что ваша компания не должна ждать завершения преобразования. К таким выгодам относятся:
|
|
Источник: сайт представительства корпорации IBM в России, раздел « developerWorks Россия », 23.05.2008 
|
|
